First, confirm that custom is the right route
Custom software is the most flexible option and the one that asks the most of you. A good partner will tell you when you do not need it. Check your situation against the table before you invite proposals.
| Your situation | Usually the better route | Why |
|---|---|---|
| A standard process, such as accounting or payroll | An existing product | The problem is solved, and the vendor carries the maintenance |
| A product fits most of the way, with gaps at the edges | Configure the product and integrate around it | You pay only for the difference |
| Several good systems that do not talk to each other | Integration between them | The data is the problem, not the screens |
| A process that is your advantage and that no product matches | Custom software | Bending your process to a product would cost you what makes you different |
| A product you intend to sell | Custom software | You need to own it and control where it goes |
Our comparison of custom and off-the-shelf software covers this decision in more depth.
Understand the engagement models and what each asks of you
| Model | How it works | Fits when | Main risk |
|---|---|---|---|
| Fixed scope and price | A defined set of features for an agreed sum | The scope is small, clear and unlikely to change | Every change becomes a negotiation, and the cheapest reading of the scope wins |
| Time and materials | You pay for the work done, to priorities you set | The scope will evolve as you learn | Cost is open unless you control the scope actively |
| Discovery, then build | A short paid phase defines the scope, followed by a priced build | The problem is clear and the solution is not | Skipping the decision point between the two phases |
| Dedicated team | A stable team works on your product over a longer period | You have a roadmap and ongoing work | You need someone on your side to direct the team |
No model removes risk. It only decides who carries which part. Fixed price moves the risk of the estimate to the partner and the risk of change to you. Ask each company why they propose the model they do.
Eight things to evaluate
| Criterion | What good looks like | Warning sign |
|---|---|---|
| Understanding of your process | They ask to see how the work is done today and who does it | They talk about technology in the first conversation |
| Discovery | A defined phase with outputs you keep, such as flows, a data model and a priced plan | An estimate based on a one-page description |
| Delivery rhythm | Working software shown every week or two, in an environment you can open | Long silences followed by a large delivery |
| Engineering practice | Code review, automated tests and a repeatable release process they can show you | Testing described as something done at the end |
| Security and data | Clear answers on access, backups, encryption and where data is stored | Security treated as an add-on |
| Team continuity | Named people, and a plan for when one of them leaves | Staff that change between the sales call and the first week |
| Ownership and exit | Ownership, licensing and access are written into the agreement before work starts | Ownership and access are not mentioned in the proposal |
| Communication | One accountable contact and written summaries of decisions | Decisions that live only in calls and chat |
Begin with a small paid start
The safest way to choose a partner is to work with them on something small before you commit to something large. A proposal shows how a company sells. A short piece of real work shows how it thinks, communicates and delivers.
- 01
Agree a discovery phase with fixed outputs
Process maps, a first version of the screens, a data model, the risks, and a plan with a price for the first release.
- 02
Judge the outputs, not the meetings
Could another team build from these documents? Did they find something you had not seen?
- 03
Keep the right to stop
The agreement says what you receive if you stop after a phase and how you may use it.
- 04
Then commit to the first release
With the scope and the price informed by what the discovery found.
A product discovery workshop is our version of this first phase.
Questions for the technical conversation
You do not need to be an engineer to ask these. You are listening for concrete answers and for a willingness to show, not only tell.
- 01
How would you decide the architecture for our system?
A strong answer coversFrom your requirements and constraints, with the alternatives they considered and the reasons, not a preferred stack applied to everything
- 02
Can you show us your test and release process on a real project?
A strong answer coversA pipeline that runs tests on every change, and a release that does not depend on one person
- 03
How will our existing data be moved?
A strong answer coversA mapping, trial migrations, reconciliation of totals and a rehearsed cut-over
- 04
What happens if an engineer leaves the project?
A strong answer coversShared knowledge of the code, documentation, and a handover period
- 05
Where will the system run, and who has access?
A strong answer coversA named hosting setup, an agreed owner for each account, and access limited by role and recorded
- 06
How do we see progress between meetings?
A strong answer coversA test environment you can open at any time, and a board showing what is in progress
Read the proposals for what they reveal
Two proposals for an order management system
A distributor wants to replace spreadsheets and email with a system for orders, stock and deliveries. Both companies and all details are invented.
- Proposal AA fixed price for a list of forty features, delivered at the end. No discovery. Hosting on the company's servers. Source code released on final payment.
- Proposal BA priced discovery phase first. Then a first release covering order entry and stock, with deliveries to follow. Reviews every two weeks. Code and cloud accounts in the distributor's name from the start.
- What A revealsThe scope was taken at face value, and the forty features will be read in the cheapest way. The distributor sees nothing until the end and owns nothing until then.
- What B revealsThe company expects to learn something in discovery and has built in a point at which the distributor can stop. The total is less certain today and the risk is much lower.
A looks safer because it has one number. B is safer because problems surface early, while they are still cheap to fix.
A contract checklist
Before you sign
0 of 10 checkedHave a lawyer review the contract. This list covers the points that most often cause trouble later. It is not legal advice.
What to do next
Describe the process you want to improve on one page, including who does what today and where it breaks. A fuller structure is in our software requirements document template. Then speak to three or four partners and ask each for a discovery phase, not a fixed price.
Our custom software development page explains how we work and what you receive. If you already have software and doubt its quality, a technical code audit gives you an independent view. Or tell us about your process and we will say whether we think custom is the right route.
Common questions
Is fixed price or time and materials better for custom software?
Fixed price suits small, well-defined work. Time and materials suits work where you expect to learn and change direction. Many projects do best with a priced discovery phase followed by fixed-price releases, each small enough to define properly. Be wary of a fixed price for a large project described in a few pages.
Does my software partner need to be close to me?
Closeness matters less than overlap in working hours and a reliable rhythm of reviews. What you need is regular contact with the people doing the work and a single accountable lead. If you are weighing an outside team against hiring, see our comparison of in-house teams and studios.
How can I judge code quality if I am not technical?
Ask to see the process around the code, such as reviews, automated tests and releases, and ask for references from clients whose systems have been live for some time. For an existing system or a large investment, an independent code audit by a team that will not be doing the build is worth its cost.
What happens if the partner goes out of business or we fall out?
If the code is in your repository, the system runs in your cloud accounts and the documentation exists, another team can continue. This is why ownership from the first day matters more than any promise. Check these three things during the project, not at the end.
How large should the company be?
Large enough to cover design, engineering and testing without depending on one person, and small enough that your project matters to them. Ask who exactly will work on it and how much of their time you will have. A named senior team is worth more than a large headcount.