You can't assess code. That's fine — you don't need to. Everything that predicts whether a software project goes well is visible without technical knowledge, and it's mostly about how someone answers questions, not what they've built.
The eleven questions
- Who will actually write this? If the person selling isn't the person building, ask to speak to the builder before you sign. A confident yes is a good sign in itself.
- Can you explain back to me what my problem is? The strongest signal in the entire process. Someone who restates your process more clearly than you described it has understood it. Someone who moves straight to features and technologies hasn't.
- Is the price fixed, and what would change it? A fixed price with named exclusions is honest. A day rate with an estimate transfers all the risk of a wrong estimate to you.
- What's not included? Ask directly. Migration, testing, training and hosting setup are the usual omissions.
- Who owns the code, the data, the domain and the accounts at the end? The answer must be you, for all four. Get it in writing.
- What happens if you're unavailable in two years? A good answer covers standard tools, written documentation, and code in a repository you own. A bad answer is reassurance.
- When will I first see it working? Weeks, not at the end. Anyone proposing to disappear for three months and return with a finished system is taking a risk on your behalf.
- What will it cost to run, annually? Hosting plus maintenance. Should be a number, not a shrug.
- How do changes work after launch, and what do they cost? Per item is usually better value than a retainer you may not use.
- Can I speak to a client you built something like this for? Not a logo — a person. Ask them what went wrong and how it was handled, because something always goes wrong.
- What would you tell me not to build? The most useful question here. Anyone willing to remove scope is thinking about your outcome. Anyone who agrees with every idea is thinking about the invoice.
Four answers to walk away from. "We'll register the domain for you" without confirming it's in your name. "We'll sort the contract later." A monthly fee that can't be itemised, where cancelling means losing the software. And an estimate given on the first call without any questions about your process — that's a number invented to win the conversation, and it will change.
How to compare three quotes that look nothing alike
This is the hard part, because the quotes won't be comparable as written. Normalise them yourself on one page:
- List every deliverable each quote includes in your own words, in one column each. Gaps become obvious immediately.
- Note which are fixed and which are estimates. Compare fixed to fixed only.
- Add three years of running costs to each. This regularly reverses the ranking.
- Add the cost of the things a quote omits — migration, training, content — because you'll pay for them regardless.
- Note who you'd be speaking to weekly. Worth real money if it's the builder.
- Note the ownership answer. A cheap quote where someone else owns the result isn't cheap.
If the cheapest quote is dramatically below the others, the usual explanation isn't efficiency — it's a smaller understanding of the job. Ask that developer to describe the awkward part of your process. If they can't, they've quoted the easy half.
Freelancer, studio or agency?
| Strength | Risk | |
|---|---|---|
| Solo freelancer | Cheapest, direct contact, fast decisions | Availability; illness or a bigger client stalls you |
| Small founder-led studio | Builder contact with some continuity | Limited capacity for very large programmes |
| Agency | Capacity, process, cover for absence | Cost of coordination; you rarely meet the builder |
| Offshore team | Lowest headline rate | Specification burden lands entirely on you |
For most UK small businesses, the question is really the first three. Offshore works, but only when you already know precisely what you want and can write it down unambiguously. If you could do that, you'd probably be halfway to building it.
Things that don't predict much
- A beautiful portfolio. Designers make the portfolio; someone else may have built the work.
- Technology names. The stack matters far less than whether the thing is maintainable and owned by you.
- Team size. Bigger is not safer; it's more expensive and slower to change direction.
- Awards. Frequently paid entry.
- How quickly they can start. Immediate availability is neutral information at best.
Protect yourself in the paperwork
- A written scope listing what's included, in plain English you could hand to someone else.
- Staged payments tied to things you can see, not to dates.
- Explicit IP assignment to you on final payment.
- Accounts in your name — domain, hosting, code repository — from day one.
- A named revision allowance and the price of extra rounds.
- A defined fix period after launch, distinguishing bugs from new requests.
None of this is adversarial and a good developer will have most of it already. If asking for it causes friction, that's the useful result of asking.
For what things should cost before you compare anything, see our guides to bespoke software costs and UK website costs. If you're in Norfolk, this checklist for choosing a Norwich web designer covers the local specifics.
Happy to be one of your three quotes.
You'll speak to the person who builds it, from the first call to handover — and you'll get a fixed, itemised price before any work starts.