Choosing who builds your software is one of the highest-impact decisions a small business makes, and one of the hardest to judge from the outside. You are rarely a software expert, and the people pitching to you are. Here is how to level the field.
Start with your problem, not their pitch
Before you speak to anyone, write down the problem in a sentence or two, who it affects, and what better would look like. A good development partner will care about those answers more than about technology. If your first call is mostly them describing their stack, notice that.
Questions worth asking
How do you start a project? You want to hear about understanding the problem first: conversations with the people who do the work, a look at current systems, and some form of discovery before anyone commits to a big number. (We describe ours in what happens in a discovery phase.)
Who will I actually talk to? Ideally the people doing the work, not only a salesperson who then disappears.
How do you handle changes? Requirements always shift once people see real software. A good answer explains how changes are discussed, priced and recorded.
How do you test? Look for specifics: testing on real devices, checking accessibility and security, and involving your team before launch.
What happens after launch? Software needs updates, fixes and improvement. Ask what support looks like and how it is priced.
Who owns what? Ownership of the code, licences, and what you receive at handover should be clear in writing before work starts.
How do you approach security and personal data? You are not looking for jargon, but for clear, confident answers.
What would you tell me not to build? A good partner will happily talk you out of unnecessary features.
Signs of a good partner
- They ask more questions than they answer in the first meeting.
- They explain things in plain language and are comfortable saying "I don't know yet".
- They talk about trade-offs rather than promising everything.
- Proposals set out assumptions, stages and what is not included.
- They are honest when something is not a good fit.
Signs to walk away
Our list of red flags in a software proposal covers these in more detail, but the big ones are: a fixed price with a vague scope, no questions about your users, no plan for support, and pressure to sign quickly.
Size matters less than fit
A freelancer can be excellent for a small, well-defined job but is a single point of failure. A large agency brings process and capacity but may put junior staff on small projects. A small studio often sits in the middle: direct access to the people building, with enough structure to run a real project. None is automatically better. Ask who will be on your project, and what happens if they are unavailable.
Compare proposals like for like
Give every company the same written brief (here is how to write a software brief) and ask them to list their assumptions. Differences in price usually trace back to differences in assumptions, and that is where the real conversation is.
Consider a paid first step
If you are unsure, a short, paid discovery phase is a low-risk way to test a working relationship. You get something useful either way: a clearer plan, and a feel for how the team works.
When you are ready to talk, start a conversation. A short description of the problem is plenty.