How to hire a software development company: 10 questions
The 10 questions that separate a real software partner from a risky one, plus the red flags that should end the conversation early.
The fastest way to judge a software development company is to ask three things: who exactly will build my product, what do I own at the end, and how do you price. Weak answers to those three kill more projects than bad code ever does. Below are the ten questions we'd ask before hiring anyone, including us, plus the red flags that should end a conversation early.
Before you talk to anyone
Ten minutes of preparation changes the quality of every call that follows.
Write down the problem in one sentence, the way you'd tell a friend ("quotes take us three days and we lose deals waiting"). Decide what success looks like as a number. Set a budget range you'd be comfortable saying out loud. And pick one person on your side who makes decisions, because projects with a committee at the wheel drift.
You don't need a spec document. Any good partner will help you write one. You need clarity about the problem, because vendors can only be as precise as the brief you give them.
The ten questions
1. Who will actually work on my project?
The people in the sales call are not always the people who write your code. Ask for the actual team: how senior, how many, and whether they've built something like yours. If the answer is vague, the team is whoever happens to be free.
2. What do I own when it's done?
The only acceptable answer is everything: source code, design files, accounts, infrastructure, all in your name. Anything less is a leash. We put ownership in writing because we've met too many founders held hostage by a previous vendor's repository.
3. How do you price, and what happens when scope changes?
Fixed price, hourly, or retainer all have their place, but whichever it is, changes must be priced in writing before the work happens. The dangerous phrase is "we'll sort that out later". Later is where budgets go to die.
4. Can I see something you've shipped that's still alive?
Screenshots are easy. Products that real users still touch every day are the proof. Ask for live links and click them yourself, the way you can open our work and use what we've built.
5. How often will I see working software?
The right answer is every week or two, something clickable, not a slide deck about progress. Long silences are where projects rot. If their process is "we'll show you in month three", walk.
6. What happens when we disagree mid-project?
Disagreements are normal. What you're testing is whether they have a process: who decides, how changes are recorded, what happens to timeline and price. A partner with no answer here becomes an adversary later.
7. What's included after launch?
Bugs surface in the first weeks of real use, always. Ask what's covered and for how long. We include 30 days of support on every build, and we tell clients upfront what a retainer costs after that, so nothing about month two is a surprise.
8. Which technologies will you use, and why these?
You're testing the "why". A team that picks the stack that fits your product and your hiring market is thinking about your five-year cost. A team that answers with whatever's fashionable is thinking about their CV. The reasoning should arrive in plain language too, which brings us to the next question.
9. Will the plan be written in language my team understands?
The scope, the milestones, and the trade-offs should read like English, whatever your technical background. Jargon in the paperwork means confusion in the project. If they can't explain it simply before you've paid, it won't improve after.
10. What don't you do?
Every honest company has an answer. Ours: we don't do token-cheap staff augmentation, we don't take projects we can't staff with senior people, and we don't promise dates before scoping. A vendor claiming to do everything for everyone is telling you they have no standards to protect.
Red flags that end the conversation
A few signals are reliable enough to act on immediately. A precise price quoted before anyone understood your workflow. No live products, only decks and mockups. Ownership answers that involve "our proprietary platform". Guarantees of specific outcomes nobody can guarantee. Pressure to sign this week for a discount. And any hint that questions annoy them, because if questions annoy them now, wait until you're a paying customer with a bug.
None of these mean bad people. They mean a process that will hurt you. Trust the signal.
Questions we hear a lot
Should I hire an agency or a freelancer? A strong freelancer is great for a small, well-defined task. For a product with design, engineering, and testing, a team removes the single point of failure. The middle path that rarely works is stitching together three freelancers yourself and becoming the unpaid project manager.
Will they sign an NDA before I share my idea? Any serious company will, and we do, before the first real conversation if you ask. Treat reluctance as an answer.
How long should hiring take? Two to three weeks from first call to signed scope is normal and healthy. A same-day contract is a red flag dressed as convenience.
Do I need technical knowledge to manage this well? No. You need the ten questions above and a partner who answers them in plain language. Translating tech into business terms is their job, and if they can't, that's your answer too.
Print the ten questions and ask them exactly as written. If you'd like to hear our answers to all ten, start a conversation and ask away. The scoping call is free, and the answers stay yours either way.