How to choose a software development company without buying a slide deck
Most failed software projects were not doomed by a framework. They were doomed by a vague brief, an unnamed team, and a vendor who could not describe how software would get into production. This article is the filter we wish every buyer used—including when they evaluate us.
Insist on the work, not the logo wall
Ask who will do the work, in what time zone, and what else they are assigned to. A senior architect on the pitch who vanishes after week two is a pattern. Ask for the roles on your project in writing. If the company cannot name a technical owner, they are selling a marketplace, not a team.
Demand a first release you can recognise
“Phase 1: discovery, Phase 2: everything” is not a plan. A first release should name users, workflows and reports. If the vendor cannot describe the smallest useful product, they will bill you to find it in public.
Look at environments, not just mockups
Where does staging live? Who holds production credentials? How are secrets stored? How do you roll back? Companies that only talk UI will improvise operations at 11 p.m. on launch day.
IP, data and subcontractors
You should own the code you pay to have written, unless you are licensing a product. Ask whether subcontractors will see your data. Ask where backups live. Vague answers here become expensive later.
Price that can survive contact with reality
Fixed price is only honest when the scope is honest. Time and materials is only honest when you get a backlog and a burn view. Hybrid models exist. What should not exist is a number with no change-control story.
How Hirvex uses this in delivery
We publish this because it is the standard we expect buyers to apply to us as well. If you are making this decision now, send the constraint and the outcome you need. We will answer as engineers: whether to build, buy, or combine—and what a first release could contain.
Questions we are asked
Should we only hire a local company?
Local can help with workshops and regulated access. Distributed teams work when overlap, language and ownership are explicit. Geography is a factor, not a moral category.
Is a huge team safer?
A huge unnamed bench is often less safe than a small team that will still be there in six months. Ask about retention of the people on your work.