Hiring a developer when you cannot evaluate development is genuinely difficult, and the standard advice — "find a technical co-founder" — is not useful to someone who needs a product built this quarter. What follows assumes you are going to hire, and concentrates on the decisions that are hard to reverse.
Decide what you are testing before you build
The most expensive mistake is not choosing the wrong developer. It is commissioning the wrong product: a complete platform when what you needed was proof that anyone wants the core thing.
Write down the single riskiest assumption in your business. Not the features — the assumption. "People will pay to have this scheduled for them." Then ask what is the smallest thing that would test it. Frequently the answer involves much less software than you imagined, and occasionally none.
Worth noting: A first version that does one thing well and is used by ten real people is worth more than a feature-complete platform used by nobody. It is also roughly a fifth of the cost.
What to insist on owning, from day one
This is the part that founders regret most often, and it costs nothing to get right at the start.
- The domain, registered to you personally or to your company
- The code repository, in your account, with the developer added as a collaborator
- The hosting and database accounts, in your name, with billing on your card
- The app store developer accounts, registered to your company
- Any third-party service accounts: payments, email, analytics
Require code to be pushed to your repository at least weekly rather than delivered at the end. If the engagement ends abruptly, the difference between having last week's code and having nothing is the difference between a setback and starting over.
Choosing between the options in front of you
One full-stack freelancer
The right default for a first version. One person, one context, no coordination overhead. The limitation is capacity and the risk is dependency on a single individual — mitigated almost entirely by owning the repository and requiring a readable README.
An agency
More expensive, more process, more continuity if someone leaves. Worth it when the budget is substantial and internal capacity to manage a freelancer is zero. Ask specifically who will do the work, because the people in the pitch are frequently not the people on the project.
A no-code build first
Frequently the correct answer and consistently under-considered. If your product is forms, records, payments, and notifications, a no-code tool may validate the business at a tenth of the cost. You will rebuild it later — and rebuilding something with paying customers is a good problem, not a failure.
How to evaluate a developer without technical knowledge
You cannot assess their code. You can assess several things that correlate strongly with it.
- Ask them to explain a past project in plain language. Genuine understanding survives simplification; bluffing does not.
- Ask what they would leave out of your plan. Anyone who agrees with every feature is not thinking about your budget.
- Ask what happens when they are unavailable for two weeks. The answer reveals whether documentation exists.
- Ask how you will see progress. "A staging link updated as I go" is the right answer; "at the end" is not.
- Buy a small paid piece first and observe the process rather than the output.
The three things to require in writing
- All intellectual property transfers to you on payment, including source files
- Code lives in your repository and is pushed at least weekly
- Handover includes a document explaining how to run, deploy, and modify the system
That third item is the one that gets dropped and the one that determines whether your next developer takes three days to become productive or three weeks. Make it a milestone with money attached, not a favour requested at the end.
Budget realistically
A focused first version with one core workflow, authentication, and a basic admin area typically runs $6,000–20,000 with a competent freelancer. Quotes far below that are usually describing something smaller than you think you asked for — which is worth resolving before starting, not after.
Reserve something for after launch. The first weeks of real usage always produce bugs and small changes, and a founder with no remaining budget at that moment is in a genuinely bad position. A rough guide is to hold back 20–30% of the total for the month after launch.
What to do while it is being built
Look at it every week, even when unfinished, even when you do not know what you are looking at. Click through it. Try to do the thing a customer would do. You do not need technical knowledge to notice that a flow does not make sense — and noticing it in week three rather than week ten is the entire value of your involvement.
Write down every question you cannot answer about your own product. Where is the data stored? What happens if the developer disappears? How do we take payment? Those questions have answers, they are all answerable in plain language, and a developer who cannot or will not give them is telling you something important.