How to choose a software development company: a 12-point checklist

Choose a software development company on evidence, not adjectives. Twelve checks do most of the work: something real running in production, unambiguous IP transfer, a demo cadence you can hold them to, direct access to the engineers, and straight answers on cost, maintenance, and what happens when you leave. Every check below is verifiable before you sign.

We're a software development company, so read this knowing where it comes from: product engineering is our largest practice, and we have watched closely what buyers regret. The pattern is consistent — projects rarely fail on technology. They fail on ownership, visibility, and incentives, which is exactly what this checklist interrogates.

Use it literally. Put the twelve items in a column, your shortlist across the top, and demand evidence — not assurances — for each cell.

Can they show you something running?

The first three checks separate firms that ship from firms that present.

• 1. Production proof. Ask what they've built that is live right now, and ask to use it — not watch a video of it. We point at DigiSign, the signage SaaS we build and operate; ask every firm you evaluate for their equivalent, and be wary if the answer is a slide.
• 2. A reference you choose. Ask for two client references, then pick which one to call. A firm that controls which client you meet is curating; a firm that lets you choose is confident.
• 3. The team you'll actually get. The people in the sales meeting are rarely the people in the repository. Ask who, by name and role, would work on your project, and whether they were on the case studies you were just shown.

Who owns what when it ends?

Every engagement ends eventually — well or badly. These three checks decide which.

• 4. IP transfer, in writing. The contract should say plainly that code, designs, and documentation become yours — at latest on final payment. Our answer to 'who owns the code?' is one word: you. Any hedge here prices in a future hostage negotiation.
• 5. Access from day one. Your own admin rights to the repository, cloud account, and domain registrar, from week one. If the vendor owns the accounts, you own a subscription to your own system.
• 6. A named exit. Ask what handover looks like if you part ways: documentation, credentials, environment setup, transition support. A firm with a good answer has done it; a firm that's offended by the question is the risk.

How will you see progress?

By the time a failing project looks failed, the budget is gone. Visibility is the early-warning system, so buy it deliberately.

• 7. Working-software cadence. Demos of running software on a fixed rhythm — fortnightly is the standard we hold ourselves to — not status decks. The question is simple: how often do I see it work, and is that date in the contract?
• 8. Direct engineer access. If every question routes through an account manager, answers arrive slow and filtered. You should be able to talk to the people writing the code, in your working hours — for international buyers, check the timezone overlap in hours, not adjectives.
• 9. A written estimate with visible assumptions. The estimate should arrive after a discovery, state what moves the price, and survive being shown to another engineer. An estimate produced in a first meeting is a marketing number.

Will it survive contact with reality?

Software's real life starts at launch. The last three checks test whether the firm has ever lived with its own decisions.

• 10. A running-cost answer. Ask what the system will cost per month to operate — hosting, monitoring, support — before you sign. Firms that operate software answer in numbers; firms that only build answer in reassurances. It's why we run our own SaaS: operating DigiSign is what keeps our estimates honest.
• 11. Security as practice, not paragraph. Ask how they handle credentials, backups, access control, and data protection — including DPDP and GDPR obligations if your users are in India or Europe. Listen for specifics and named tools, not certifications alone.
• 12. A mainstream, staffable stack. The technology should be one other firms could take over — React, Laravel, Flutter, AWS, and their peers — chosen for your problem, not for the vendor's convenience. An exotic stack is a subtle form of lock-in that check 4 won't save you from.

Which red flags end the conversation early?

A few answers save you the remaining eleven checks. A price quoted confidently in the first meeting, before anyone has asked what your systems look like. Reluctance to put IP transfer in plain words. No product or system they operate themselves — builders who have never carried a pager for their own code price running costs from imagination. A portfolio of screenshots with no live URLs. And pressure to sign quickly, which in software procurement means exactly what it means everywhere else. None of these guarantees a bad project; each one, historically, correlates.

What's the one-page version?

Production proof you can touch. A reference you choose. The actual team, named. IP yours in writing. Access from day one. A defined exit. Fortnightly working demos. Engineers you can talk to. A written, assumption-visible estimate. A running-cost number. Security in specifics. A stack others could inherit.

Score your shortlist honestly against those twelve, and the decision usually makes itself — the field thins faster than you'd expect. And any firm worth hiring will happily be examined this way; being on the receiving end of these questions is, itself, the thirteenth check.