How to hire an app developer when you cannot judge the code

You have an idea, a budget, and no way to judge whether the person across the table is any good. Everyone shows you a portfolio. Everyone says they are senior. The websites look the same.

This is how to evaluate technical people when you cannot evaluate their technical work.

First decide what you are actually buying#

Three different things get sold under the same words:

A freelancer — one person, cheapest, fine for a well-defined piece of work. Risk: they get ill, get a job, or disappear, and there is no continuity.

An agency or team — several people with overlapping skills. More expensive, survives one person leaving, and brings design and QA. Risk: you may not get the people you met.

An employee — most expensive, best for long-term ownership. Only sensible if you have ongoing work and can evaluate candidates technically, or have someone who can.

Most first-time founders should hire a small team rather than a freelancer, not because freelancers are worse, but because the failure mode is milder.

The questions that actually reveal something#

Skip “what’s your process”. Everyone has an answer prepared. Ask these instead:

“What would you remove from this scope if it were your money?”#

The single most useful question you can ask. A good team names two or three things immediately and explains why. A team that cannot find anything to cut is optimising for invoice size.

“What are you least confident about in this estimate?”#

Honest engineers have an answer, usually a specific integration or an unclear requirement. “Nothing, it’s straightforward” means they have not thought about it, or are telling you what you want to hear.

“Tell me about a project that went badly and what you did.”#

You are listening for specifics and ownership. “The client kept changing requirements” is a complaint. “We under-estimated the payment integration and absorbed two weeks” is a story from someone who has actually shipped things.

“Who exactly will write the code, and can I speak with them?”#

If the people who show up to the sales call are not the people who do the work, you want to know that now. Ask for names. Ask for those names in the contract.

“What happens if we stop working together in month two?”#

The right answer is boring: your code is in your repository, your accounts are yours, another team can pick it up. Any hesitation here is a warning about lock-in.

Warning signs that are worth walking away over#

• They quote before understanding. A number in the first call, with no questions about roles, backend or integrations, is a sales tactic.
• They agree to everything. Every real project has trade-offs. A team that says yes to every request and every deadline is either inexperienced or planning to renegotiate later.
• They own your accounts. Your app store listing, your cloud account, your domain, your repository — all yours, from day one. Anything else is leverage over you.
• No written scope. “We’ll figure it out as we go” sounds flexible and becomes a dispute.
• They will not do a paid trial. Any confident team will take two weeks of real work as an audition. Refusal means they need the long contract to make the numbers work.
• Portfolio without specifics. “We built an app for a major retailer” with no name, no metrics and no detail may mean NDA — or may mean it was a small piece of someone else’s project.

How to check work you cannot read#

You do not need to read code to check some things:

Ask for a deployed environment from week one. A URL you can open, updated weekly. This is the single best protection you have. Problems become visible in week two rather than month three.

Ask who owns the repository and look at it. You cannot judge the code, but you can see whether commits happen steadily or in one enormous dump before each invoice.

Pay someone independent for a few hours of code review at the midpoint. A senior engineer will tell you in an afternoon whether the foundation is sound. Cheap insurance against an expensive rewrite.

Watch how they handle you changing your mind. You will change your mind — that is normal. A good team tells you the cost and lets you decide. A bad one either silently absorbs it and resents you, or treats every change as a contract dispute.

About price#

Rates vary by roughly ten times across markets for genuinely comparable work. That is real, and it is why offshore exists.

But within any market, the cheapest option is rarely cheapest overall. Work you rewrite costs more than work that cost more. The question is not “what is the rate” but “how many weeks will this actually take, and how much of it will survive”.

A useful heuristic: be suspicious of anything under half the going rate for a market. That gap is not efficiency. It is seniority, or it is scope you have not discovered yet.

The short version#

1. Ask what they would cut. Listen for a real answer.
2. Get named people, in writing.
3. Insist on a deployed environment from week one.
4. Own your repository, cloud accounts and app store listing from day one.
5. Start with a paid two-week trial before any long commitment.
6. Have an independent engineer review the code at the midpoint.

None of this requires you to be technical. It requires you to insist on visibility — which is the thing that separates projects that go wrong quietly from projects that go wrong early enough to fix.