Guide

Choosing a development partner: what to compare and what to ask.

You will probably live with the people who build your software for years. Price matters, but it is rarely the most important factor. This guide gives you a way to compare suppliers — including us — on the things that decide whether a project goes well.

Key takeaways

Judge suppliers on how they think and communicate, not only on a portfolio.
Ask for evidence you can check, and treat unverifiable claims with caution.
Insist that you own your code, data and accounts from day one.
A good supplier will talk you out of things and tell you what they do not do.
Start with a small, paid first phase to see the working relationship before committing to a large one.

What to compare

Understanding of your business. Do they ask about your customers, your process and your constraints before talking about technology?
Relevant experience. Not necessarily your industry, but similar problems: bookings, payments, integrations, bilingual content.
Team and continuity. Who will actually do the work? Will they still be there in a year?
Process. How do they plan, show progress and handle change? Can you see working software regularly?
Communication. Language, time zone, response speed, and whether they explain things plainly.
After launch. Who fixes problems, at what cost and how quickly?

Questions worth asking

What would you build first, and what would you leave out? Why?
What are the biggest risks in my project, and how would you reduce them?
Who exactly will work on it, and how many hours a week?
Can I speak to a past client, and see something that is live today?
How do you handle a change of mind halfway through?
What do I own at the end — code, designs, data, domain, hosting accounts?
What happens if we part ways? Could another team take over?
What does support cost after launch, and what does it include?
How do you test, and how do you handle security and personal data?
What do you not do?

Evidence worth seeing

Live products you can open and try, rather than screenshots only.
Past clients willing to talk — and a reasonable answer when they cannot, such as confidentiality.
A clear written proposal listing what is included, excluded and assumed.
Sample documentation or a handover pack from another project.

Be wary of long lists of famous logos, awards you cannot check and guarantees that sound too good. If a claim matters to your decision, ask how you can verify it.

Points to settle in the contract

Ownership: code, designs and data assigned to you on payment, with any third-party or open-source components identified.
Accounts: domain, hosting, app store and analytics accounts in your name, not the supplier's.
Scope and change: what is in, and how changes are priced and approved.
Payment: tied to delivered milestones, not only to dates.
Handover: source code, documentation and credentials delivered in a usable state.
Confidentiality and data protection: who may see your data, and where it is stored.
Exit: how either side can end the work.

Have a lawyer review any substantial contract. This guide is not legal advice.

Warning signs

A firm price with almost no questions asked.
Pressure to sign quickly, or a discount that expires tonight.
Vagueness about who does the work.
Reluctance to put the scope and exclusions in writing.
Hosting or accounts set up in the supplier's name "for convenience".
No interest in how your business actually works.
Yes to everything — no suggestion of what to cut.

A sensible way to start

Rather than commit to the whole build, buy a short first phase: a scoping workshop, a prototype or the first small release. You see how the team works, you receive something useful whatever happens next, and the bigger decision is made with real evidence. A supplier confident in their work will not object.

Keep reading

Frequently asked questions

Should I choose a local company or an overseas one?

Either can work. Local teams are easier for meetings and for local rules and payment practices; overseas teams can cost less. What matters is communication quality, clear scope and ownership terms.

Freelancer, studio or large agency?

Freelancers suit small, well-defined work; studios offer a team without heavy overhead; large agencies suit complex programmes with many stakeholders. Match the supplier's size to the project and your own capacity to manage it.

How many quotes should I get?

Two or three well-matched ones is usually enough. More quotes mean more time spent comparing different assumptions.

Comparing suppliers?

Include us if you like (read about Aixo Lab first). Send a short brief and we will reply with questions and a proposed first phase.

Request a project quote