Choosing a development partner is a high-stakes decision made with very little information. Every deck looks good, quotes are hard to compare line for line, and the real differences only surface halfway through the project. Here are the questions that actually predict how it will go.
First, decide what you are buying
“Hire someone to build a system” covers three different needs. Mixing them up is how quotes end up incomparable:
| What you need | Who fits | Usual pricing |
|---|---|---|
| Work out whether and how to build it | Consultant, fractional CTO | Project fee or monthly |
| Build what is already decided | Development team | Fixed price or milestones |
| Keep a live system running | Maintenance team | Monthly, by service level |
Buying only the middle one is where projects fail: work starts before the requirements are clear, and nobody owns the system after launch.
Five questions that predict the outcome
1. Do they push back?
A vendor who builds exactly what you ask and never questions it is a risk. Good partners challenge your assumptions before writing code and tell you which features to drop. If nobody disagrees with you in the first meeting, that is not good service, it is a supplier who does not intend to own the outcome.
2. Who owns the code and the data?
You should own the full codebase, database, and cloud accounts, and be able to take over at any time. Ask directly: what do I hold the day this contract ends? If the answer is fuzzy, or the code only lives in their repository, be careful.
3. Who is responsible after launch?
Ask about maintenance scope, response times, and cost. Most vendors’ responsibility ends on delivery day, which is exactly when the real cost begins. A quote with no maintenance option is not a complete quote.
4. How do they handle being wrong?
Every project goes wrong somewhere. A partner worth hiring will tell you what they have broken and how they fixed it. “We have never had a failure” means either not enough experience or not enough honesty.
5. Who will actually do the work?
Are the people in the pitch the people writing the code? How much gets subcontracted? The answer determines your communication cost for the whole project.
Reading the quote
Three common structures, each with a fit:
- Fixed price: safest when scope is clear, but changes go through a change process. Good for well-defined projects.
- Time and materials: suits discovery work and changing requirements, but ask for timesheet detail and a cap.
- Monthly team: suits long-running products under continuous change. Confirm what headcount and what work the fee covers.
Compare quotes against the same scope. One that includes testing, documentation, and three months of warranty is not comparable to one that covers development only. Asking each vendor to list what is not included tells you more than the total does.
Five things the contract must state
- IP ownership: code, design files, and data, including how any pre-existing components of theirs are licensed to you.
- Acceptance criteria: what counts as done, who decides, and how long they have to respond.
- Payment schedule: tied to milestones, never fully up front.
- Maintenance and warranty: how long, what it covers, and what it costs afterwards.
- Exit terms: what gets handed over on termination, including source, documentation, and account transfers.
Warning signs
- A quote with a total and no line items.
- A timeline far shorter than comparable projects, with no explanation of how.
- No verifiable work and no willingness to provide a reference.
- Technical answers to business questions: you ask how much labour this saves, they answer with their architecture.
- Maintenance not discussed, or deferred to “later”.
- Full payment up front, or refusal to push code to your repository.
A checklist you can use as-is
After talking to each candidate, tick what applies:
- Can name what they think the biggest risk in this project is
- Suggested at least one thing you should not build
- Code, data, and accounts belong to you
- The people pitching will work on the build
- Quote includes testing, documentation, and warranty, itemised
- Maintenance is offered, with the cost stated up front
- Can explain how they approached a comparable project, even if the client is confidential
- Willing to start with a small paid pilot
Fewer than six ticks and the price does not matter. Replacing a vendor mid-project usually costs two to three times the original quote.
If you are already stuck with one
Vendor gone quiet, developer left, documentation missing: none of that is fatal. Start with an audit of the system: can the code be taken over, does the architecture have a fatal flaw, is the data intact. Then decide whether to maintain, improve, or rebuild. Most systems do not need a rewrite. They need someone who actually takes responsibility for them.