What matters most when choosing?
Technical skill is the baseline, not the differentiator. What separates good partners from risky ones is clarity: clear scope, clear communication and clear ownership. Weigh those as heavily as price.
Which questions should you ask?
About process
- How will you learn about our business before you quote?
- How do we see progress, and how often?
- How do you handle changes to the scope?
- Can we start with a small first phase?
About ownership and risk
- Who owns the code, designs and data?
- Will we get all accounts, passwords and documentation at handover?
- Where will it be hosted, and in whose name?
About cost
- Can you give an itemised estimate by feature or milestone?
- What is included and what is not?
- How is payment split across the project?
About quality and after launch
- How do you test the software?
- What happens if a bug appears after launch, and for how long are fixes included?
- Who maintains it afterwards, and what does that cost?
What red flags should you watch for?
- A firm price with no discovery or questions.
- Promises that sound too good, such as everything in half the time.
- No clear answer on who owns the code.
- Refusing to share a plan, milestones or examples of similar work.
- Pressure to sign quickly.
How do you compare quotes fairly?
| Look at | Why it matters |
|---|---|
| Scope covered | Two quotes may cover different things under the same name. |
| Breakdown | An itemised quote shows where the effort goes. |
| Assumptions | These reveal what could change the price. |
| Testing and launch | Often missing in cheaper quotes. |
| After-launch terms | Fixes, hosting and maintenance affect total cost. |
| Payment schedule | Staged payments tied to milestones protect you. |
Should you start with a pilot?
Yes, where you can. A small, well-defined first phase, such as one workflow or one module, tells you how the team communicates, how they handle surprises and what the software feels like. It is a cheaper way to learn than committing to everything.
What should you prepare before talking to companies?
- A one-page brief: who uses it, the main tasks and the problem you want solved.
- Systems it must connect to.
- A deadline and a rough budget range.
- One person from your side who will make decisions quickly.
How do you run a fair selection process?
- Shortlist three companies. More than that is hard to compare.
- Give each the same one-page brief.
- Hold a first call with the same questions for each.
- Ask for a staged plan and an itemised estimate.
- Speak to a reference, and ask what went wrong as well as what went well.
- Consider a small, paid pilot before the full project.
What does a good first call feel like?
Expect more questions from them than answers. They should want to understand your users, your current process and what success looks like. They should be willing to say what they would leave out, and honest about what they do not do. If the call is mostly a sales presentation, treat that as information.
What should you ask a reference?
- Did the project run to the agreed scope and timeline?
- How were problems and changes handled?
- Was communication clear and regular?
- Would you hire them again?
When is hiring in-house the better choice?
If software is the core of your business and you will build for years, an in-house team can make sense. For a defined project, or when you need several skills for a limited time, a partner is usually more efficient.
Related: Custom software and integrations · SMEs and Enterprise · All articles