How to choose a software house: a checklist

Choosing a software house is a high-stakes decision you make with limited information, and the cost of getting it wrong is rarely visible until months in. The good news: the signals that predict a good partnership are knowable in advance if you know what to look for. Here is the checklist we would use.

Look at how they scope, not just what they quote

The best sign is a team that pushes back on your scope before quoting a price. A partner who asks what to leave out of version one — and helps you decide — is one who will keep your project focused and affordable. A partner who quotes whatever you describe, no questions asked, is one who will happily build an expensive, unfocused product.

Check whether design and development are connected

A common failure is a beautiful design that the build quietly waters down because design and engineering are separate teams, or separate companies. Ask how design decisions carry into the build. Teams where design and development stay in the same room ship products that match what you approved — nothing lost in handoff.

Ask about the codebase you will inherit

You are not just buying a launch; you are buying everything you build after it. Ask whether the code will be tested, documented, and structured so a future team can extend it. A shippable product on a throwaday foundation is a debt you pay later, with interest.

The questions worth asking

• Will the same team stay from first call to launch, or will it change hands?
• How will I see progress — do I get working builds regularly?
• How do you decide what belongs in version one?
• Who owns the code and how is it documented?
• Can I talk to a client you shipped for?

Red flags

• No pushback on scope — they build whatever you say.
• Design and development handed between separate vendors.
• Vague answers about testing, ownership, or documentation.
• A rotating cast of people with no continuity.

A small senior team that owns the whole process — scope, design, build, and launch — avoids most of these failure modes by construction. That is the model we chose deliberately, because it is the one we would want if we were the client.