How to Choose a Software Development Agency: A Buyer's Checklist

Most advice on how to choose a software development agency is written to make one agency look inevitable. This page is written to be useful even if you never talk to us: it is the list of questions, artefacts and checks we would use if we were the ones buying, and most of it points at evidence a vendor either has or does not have.

One warning before the checklist. There is no ranking of agencies that is worth anything to you, because the thing you are choosing is not a company, it is a specific team with specific availability in a specific quarter. Everything below is built to test that, not the logo.

Before you shortlist anyone

Most bad vendor decisions were made before the first call, by starting the search with a description too vague to compare answers against. Three things are worth writing down first.

• What has to be true at launch. Not a feature list, the outcome. If you cannot say what would make the first release a success, every proposal will look reasonable.
• What you already run. Your CRM, your billing, your data, your identity provider. This is the single most common source of late surprises, and vendors cannot estimate what you have not told them about.
• Who decides. One person with the authority to settle scope questions in a day. Vendors cannot fix an internal decision bottleneck, and the good ones will ask about it on the first call.

With those three written down, a proposal becomes checkable. Without them, you are comparing writing styles.

Where to look, and what a directory profile actually proves

Directories, referrals and portfolios are how the shortlist gets built, and each proves less than it looks.

A directory profile proves that someone filled in a form. Reviews are the useful part, but only when you read them properly: how many there are, whether they are marked verified, and whether the projects described resemble yours. Clutch, for example, verifies reviews using reviewer-provided information and online research, checking proof of identity and work history, and publishes reviews it cannot verify as Not Verified (Clutch, How Does Clutch Verify Reviews?). So the label carries information. The count carries more.

Here is ours, since it would be dishonest to give you a test we would not sit: Kultrix was founded in 2023 and has two reviews on Clutch, both five stars (our Clutch profile). Two is a small sample. It tells you those two projects went well; it does not tell you what happens across fifty. A vendor with forty reviews has genuinely told you something we have not, and if review volume is what you need in order to sign, that is a legitimate reason to pick someone else.

What we would trust more than any profile: a reference call with a client whose project failed or nearly did, and who still recommends them. Every agency can produce a happy reference. Ask for the one that went sideways.

The questions to ask on the first call

These are ordered so that the answers get harder to fake as you go down the list.

• Who exactly will be on this project, and what else are they on? You want names, roles and current allocation. The gap between the people who sell and the people who build is the oldest failure in this industry.
• What weekly output per person does your plan assume? The single most revealing question in the list. We plan about 18 focused hours per person per week, because the rest of the week is code review, handover, releases and clarifying what was meant. Anyone planning on 40 has promised a date they cannot hold. Anyone who has never thought about the number does not have a plan, they have a wish.
• What is your estimate made of? A total is not an estimate. You want a base plus modules, each with a low and a high, so you can see which parts they understood.
• Where do QA and project management sit in that number? If they are missing, they did not disappear, they moved to your calendar. Someone still writes test cases and chases answers.
• What have you assumed about our existing systems? Ask them to name the assumption out loud. Then check it against what you wrote down before you shortlisted.
• What would make this project go over, and what would you do about it on the day you noticed? The answer you want describes a mechanism, not an attitude.
• What do you need from us, weekly, for this plan to hold? A vendor who has delivered before knows exactly what they need from the client side and will tell you without being pushed.
• What happens if we stop after the first release? Access to the repository, the deployment, the accounts and the design files should be a boring question with a boring answer.

What to ask them to show

Answers are cheap. Artefacts are not. Every item here exists on a real project and takes a vendor minutes to produce if they have it.

• An estimate from a past project, broken down by module. Redacted is fine. You are checking the shape, not the client.
• The same project's actual hours. The gap between estimate and outcome is the only honest measure of how good their estimates are. A vendor who cannot produce the actuals does not measure themselves.
• Repository access on a live project, or a screen share of one. Commit history, branch discipline, review comments. Ten minutes here tells you more than the whole portfolio.
• A release. Ask how a change reaches production and how long that takes. If the answer involves a person copying files somewhere, the timeline they gave you has a hidden cost in it.
• A test report or a list of what is covered. Not a promise about quality, an artefact.
• Two references you pick, not two they pick. From the list of past clients, choose. Watch what happens when you do.

How to compare two proposals that are not comparable

This is the part buyers ask us about most, because the usual situation is two documents with different structures, different assumptions and totals far apart. The fix is to convert both into the same shape.

1. Strip out the rate. Rates are not a property of your project; they depend on who does the work and where they sit. Reduce both proposals to hours and the comparison becomes about understanding rather than geography.
2. Separate the base from the modules. Every project carries work that belongs to no feature: architecture, the screen skeleton, environments, build pipeline, release setup. For a mobile app that base is 320 to 520 hours before a single feature is added; for a web app it is 280 to 460 hours. A quote that looks unusually cheap has usually left the base out.
3. Line the modules up against each other. Accounts and roles run 60 to 110 hours, payments and subscriptions 90 to 170 hours, compliance work such as GDPR, PCI or HIPAA 80 to 200 hours, moving records off an existing system 70 to 170 hours. If one proposal is far under on a module, ask what version of it they costed.
4. Check the weekly hours assumption behind the timeline. Divide their hours by their team size and their weeks. If the answer comes out near 40 hours per person per week, the date is decoration.
5. Check what is missing rather than what differs. Exclusions move more money than line items. Support after launch, hosting, third-party licences and app store fees are real costs that simply start when the build stops.

Two more things belong in the comparison, and they are the ones most often confused with each other.

First, the glue between modules. Add a base and a list of modules and the total is always too low, because shared state, permissions that cross features, end to end testing of paths that touch several modules and the release cycle belong to no module in particular. We measured the gap against a delivery we had accounted for hour by hour: adding isolated modules gave a ceiling of 2,330 hours where the real project was 3,086. Our model closes that with a multiplier of 1.25.

Second, and separately, connecting the product to systems you already run. That is not glue and no multiplier covers it. It is its own module, third-party integrations at 70 to 180 hours, chosen per project because plenty of builds need none. If a vendor tells you a blanket uplift covers your ERP or your existing billing, ask which line that work sits in. The question usually ends the conversation about the uplift.

A longer version of the comparison, question by question, is in how to read a development estimate.

Answers that should make you slow down

• A single number with no range. Before anything is designed, precision is a claim about the future that nobody can support. A range with an explanation of what moves it is the honest form.
• A fixed price offered before discovery. Not dishonest by itself, but it is priced. Either the buffer is inside the number, or the change requests will find you later.
• No QA line and no management line. See above. That work still happens, and it is now yours.
• A timeline that shortens when you push on it, with no scope change. Compressing the same scope does not make the work smaller, it makes it larger: more people in parallel, more coordination, more rework. In our model compression multiplies the hours by 1.2. A vendor who shaves weeks without changing anything is agreeing with you rather than planning.
• Team size as the answer to every schedule question. Above roughly six people the coordination eats the gain faster than the extra hands add. Past that point more budget stops buying an earlier date.
• A portfolio without named clients, and no reference who will take a call. One of the two is normal, under an NDA. Both together is a pattern.
• Vagueness about who owns the code. Covered below; there is a specific legal reason this one matters more than it sounds.
• They never say no. A vendor who accepts every scope change without a conversation about consequences is one who has stopped planning and started billing.

Small team or large agency

We are small, so treat this section as interested and read both columns.

What a small team genuinely gives you. The people who sold the work are the people who do it. Decisions take hours rather than a change board. There is no account layer between you and the person writing the code, which removes the most common place for requirements to get distorted. Overhead is lower, so more of the budget lands on the build.

What a small team genuinely costs you. Key-person risk is real: one person leaving is a much larger fraction of a team of five than of a team of fifty. Depth of bench is thinner, so a specialist skill you need for three weeks may not be available at all. There is less process infrastructure, which matters if your own compliance function expects certified processes and audited suppliers. And the track record is shorter, which is the reason a review count means something.

The honest rule: the size that fits depends on your risk, not on ours. A regulated enterprise programme with a supplier-audit requirement should probably not be handing the whole thing to a team of six. A first product that needs to be in front of users this quarter usually should not be buying an account management layer.

The contract clauses that decide who owns what

Two of these are commonly assumed and rarely true by default.

Intellectual property. Paying for software does not, on its own, make you the owner of the copyright in the United States. A work made for hire covers work by an employee, or a commissioned work in one of nine listed categories: contribution to a collective work, part of a motion picture or other audiovisual work, translation, supplementary work, compilation, instructional text, test, answer material for a test, or atlas (17 U.S. Code section 101). Software is not on that list. So a commissioned app built by an outside contractor cannot be a work made for hire, and the transfer has to happen through a written assignment of copyright. If the contract says "work for hire" and stops there, ask for an assignment clause as well.

Personal data. If the vendor will touch your users' personal data under the GDPR, they are a processor and you need a written agreement. The European Data Protection Board is explicit: processing by a processor must be governed by a contract or other legal act, and that act must be in writing, including in electronic form, so that "non-written agreements (regardless of how thorough or effective they are) cannot be considered sufficient" (EDPB Guidelines 07/2020, paragraphs 100 to 101). Ask for their data processing agreement during selection, not after signature. A vendor who has one ready has been through this before.

Access from day one. Repository, cloud accounts, domain, app store entries and design files should be in your organisation from the first commit, with the vendor invited into them. Migrating this at the end is where exits go wrong, and it costs nothing to arrange at the start.

How to verify what you were told

Four checks, each cheap.

• Call the reference with a specific question. Not "were you happy". Ask: what did the estimate say, what did it actually take, and what did they do when it started slipping.
• Match the proposed team to public profiles. If four named engineers are proposed, they usually exist somewhere. Check tenure. A team assembled last month for your project is a different risk from a team that has shipped together.
• Re-ask one question a week later, in writing. Consistency between the sales call and the written answer is a decent proxy for whether the plan is real.
• Buy a small piece first. This is the strongest check available. A paid discovery or a design phase, in our model design work on its own runs 120 to 280 hours, gives you a real working relationship, a real artefact and an exit that costs a fraction of the build. You learn more in three weeks of paid work than in three months of proposals.

If you want to know which parts of a project tend to surface late, so you can ask about them before signing rather than after, that is in what actually goes wrong in app projects.

Bring your own number to the conversation

The best position to negotiate from is having done the arithmetic yourself. Our cost calculator takes your product type and the modules you actually need and returns the hours, a realistic timeline and a team size, using the same model the numbers on this page come from. It takes about a minute, it does not require a call, and it works just as well for checking somebody else's proposal as ours.

For the background on where those ranges come from, and how hours turn into weeks, see how much an app costs and how long it takes. All of it is calibrated against one project we delivered and accounted for hour by hour: 3,086 hours over 31 weeks with a team of five to six.

Questions people ask

How do I choose a software development agency without technical expertise?

Test the process rather than the technology. Ask what weekly output per person the plan assumes, ask to see a past estimate next to that project's actual hours, ask where QA and project management sit in the number, and ask what happens if you stop after the first release. None of those require you to read code, and all of them separate a team that plans from a team that hopes.

How many agencies should I get proposals from?

Three is usually enough, and more than five stops adding information. What matters more than the count is giving all of them the same brief, including what you already run internally. Different briefs produce different numbers, and then you are comparing your own inconsistency rather than their work.

Should I pick the cheapest proposal?

Only after you know why it is cheapest. In practice the gap is almost always missing scope rather than better pricing: no QA line, no project management, no base work for architecture and release setup, or an assumption that your existing systems are documented. Strip the rates out, compare the hours module by module, and the cheap proposal usually turns out to be a different project.

What are the warning signs that an agency will not work out?

A single number with no range, a fixed price offered before any discovery, a timeline that shortens under pressure without any scope change, no QA or management line in the estimate, no reference willing to take a call, and vagueness about who owns the code. Any one of them is a question to ask. Three of them together is an answer.

Is a small agency riskier than a large one?

It is a different risk, in both directions. A small team gives you the people who sold the work actually doing it, faster decisions and less overhead. It also gives you key-person risk, a thinner bench of specialist skills, less process infrastructure for supplier audits and a shorter track record. We are small ourselves, founded in 2023 with two reviews on Clutch, so we would say the trade is worth it for most first products and not worth it for a regulated enterprise programme.

How do I compare two estimates that use completely different formats?

Convert both to hours and rebuild them in the same shape: base, then modules, then the timeline assumption. A mobile base is 320 to 520 hours and a web base 280 to 460 hours before features; accounts and roles are 60 to 110 hours and payments 90 to 170 hours on top. Then divide each vendor's hours by their team and their weeks to see what weekly output per person they assumed. That single division explains most of the difference between two very different totals.

Does the estimate cover connecting to the systems we already run?

Only if it is a named line. Connecting to systems you already run is a module of its own, third-party integrations at 70 to 180 hours, with data migration from an existing system at 70 to 170 hours when records have to move. It is not covered by a general uplift: the 1.25 multiplier in our model pays for glue between modules, meaning shared state, permissions that cross features, end to end testing and the release cycle. Different work, different line.

Who owns the code we paid for?

Whoever the contract says, and the default is not what most buyers assume. Under United States copyright law a work made for hire covers employees, or commissioned work in nine listed categories that do not include software, so a commissioned app needs a written assignment of copyright rather than a work-for-hire label alone. Ask for an assignment clause, and ask for repositories and cloud accounts to sit in your organisation from the first commit.

What should we ask for before signing?

An estimate broken into base and modules with a low and a high on each, the assumption about weekly hours per person written down, an assignment of intellectual property, a data processing agreement if the vendor will touch personal data under the GDPR, and access to repositories and accounts from day one. All five are ordinary requests. How quickly a vendor produces them is itself a data point.