How to hire someone to build your app (without getting burned).

Most wasted app-build budgets share the same cause: the team hired before they had scope, or hired the wrong shape of team for the stage they were at. Neither problem is expensive to fix before you start.

Before you hire: write one page of scope

One page. No more. It should answer: what does a user do on day 1 (not a feature list, a behavior), what is the one database object at the center of the product, and what does 'shipped' mean. Any team you hire will write scope anyway — you will pay for it. Write it yourself first so you know if the team's version matches your idea.

The five questions to ask every team you talk to

1. 1Who specifically will work on our product? (If the answer is 'a team' without names, that is a staffing agency, not a product team.)
2. 2Who is accountable if the first version doesn't ship? (If no one answers this question directly, they are quoting time and materials, not an outcome.)
3. 3Where does the code live from day 1? (Your GitHub org. Any other answer is a leverage risk.)
4. 4What is the testing and deployment pipeline? (CI, staging, production. If this is 'we'll set it up later,' the product will never be production-quality.)
5. 5What happens after launch? (Retained engagement, handoff, or abandon. Know this before you sign.)

Pricing models and what they mean

Fixed-price project

Best for well-scoped MVPs and migrations. You pay a fixed number for a defined outcome. The risk to the vendor is scope creep; the risk to you is an underscoped contract. Good for Yo! Launch and FullCode-style engagements.

Time and materials

Best for ongoing product work where the roadmap is evolving. You pay for time. The risk is an open-ended spend and misaligned incentives. Good for retained squad engagements with a sprint cadence.

Equity + cash hybrid

Common for pre-revenue startups. The risk is that equity pricing is almost always optimistic, and teams with equity stakes are less accountable on delivery timelines. We do not offer this model.

Red flags that predict a failed engagement

• No written scope before a project starts.
• The estimate is hours or story points, not a fixed outcome price.
• No staging environment in the plan.
• IP assignment is 'at project completion' instead of 'from commit one.'
• Communication is a Slack channel, not a weekly call with a named PM.