How to hire a software development agency: a founder's checklist

A good share of the founders who contact us have already paid someone else to build the first version. The code is late, nobody on their side can read it, and the agency’s answer to every question is a change request. This post is the checklist we wish they’d had at the start. It applies to us too; use it on us.

Decide what you’re actually buying

There are three different things an agency can sell you, and the proposal should say which one it is.

• A fixed-scope project. You get a defined product for a defined price on a defined timeline. This works when the scope can be written down before work starts. It fails when the scope is “we’ll figure it out as we go”, because every discovery becomes a change request.
• Embedded engineers. You get senior people working inside your team, paid monthly, directed by you. This works when you already have a product and a backlog. It fails when nobody on your side can direct the work.
• A retainer for an existing product. Bug fixes, small features, infrastructure, on call. This is what most “maintenance” contracts are, and it should be priced per month, not per ticket.

If the proposal mixes these without saying so, you’ll be arguing about which rules apply by week three.

Questions to ask before the proposal

Ask these on the first call. The answers tell you more than the pitch deck.

1. Who will write the code? Not who will manage the account: who will open the editor. Ask for their name and ask to speak to them. If the senior person on the call won’t be on the project, you’re buying a different team than the one you met.
2. Show me something you built that’s still running. Then open it. A case study is a story; a product with real users is evidence. Ask what broke in production and what they changed afterwards.
3. Where will the code live? The correct answer is “in a repository you own, from the first commit”. Anything else means you don’t own your product until the final invoice clears, and sometimes not then.
4. How do you handle a scope change? You want to hear a process, not “we’re flexible”. A good answer: changes are written down, estimated, and you approve them before they’re built.
5. What happens at handover? Documentation, a walkthrough, access to every account, and a period where they’re still reachable. If the answer is vague, plan to be stuck with them.

What a good proposal contains

A proposal is a working document, not a brochure. We’d expect to see all of this on paper before any money moves.

• Scope as a list of things the software does, in plain language, with explicit “not included” items. The not-included list is where most disputes would have been avoided.
• Assumptions. Which third-party services you’ll pay for, what you’ll provide (designs, content, API keys), and what happens if an assumption is wrong.
• A timeline with milestones you can inspect. Not “phase 1, phase 2” but “by week 3 you can log in and create a project; by week 6 payments work in test mode”. Each milestone should be something you can click.
• The team by name, with how much of their time you’re getting.
• Ownership and licensing. You own the code and the intellectual property. The agency keeps the right to reuse generic tooling they brought with them, and that’s reasonable, but it should be written down.
• The price, and what changes it. Fixed price with change control, or a monthly rate with a minimum commitment. Either is fine; “estimate, billed hourly” is neither.

Red flags we see in other people’s proposals

• A timeline shorter than the discovery call. If they quoted four weeks without asking what your product does, they’re quoting a template.
• No mention of tests, deployment or monitoring. The code will run on a laptop. Getting it to run for your customers is a separate, unpriced project.
• A stack chosen for the agency, not for you. A custom framework or an unusual language means only they can maintain it. Ask how easy it will be to hire for in two years.
• “We’ll use AI to build it faster.” Everyone does now. The question is who reviews what the AI wrote, and whether the person reviewing it could have written it.
• The lowest price by a wide margin. It’s usually the same price in the end, paid as change requests, or paid to the next agency who rebuilds it.

How we work, for comparison

We publish our engagement models and starting rates on the pricing section of our homepage, because a founder shouldn’t need three calls to learn whether we’re in budget. The code lives in your repository from day one. Milestones are things you can click, and every one ships with the evidence: deployed environment, test results, a short recording. The engineer you speak to on the discovery call is the engineer who builds the product.

The checklist

Copy this into your notes and tick it off before you sign.

• I know which engagement model I’m buying and the proposal says the same.
• I’ve spoken to the person who will write the code.
• I’ve opened a product they built that real users use today.
• The code will live in a repository I own from the first commit.
• The scope lists what’s included and what isn’t.
• Each milestone is something I can click, with a date.
• Deployment, tests and monitoring are in the scope, not “later”.
• Scope changes follow a written process I approve.
• Handover is defined: docs, walkthrough, accounts, support period.
• I understand what changes the price.

If you’d like a second opinion on a proposal you’ve already received, send it over. We’ll tell you what we’d ask, even if you don’t hire us.