The ten checks, quickly
- Relevant experience, backed by references you can phone
- The real team, not just the sales team
- Proper discovery before any price
- A technology choice they can explain
- Clear ownership of code and accounts
- Regular, honest communication
- Testing that isn't an afterthought
- Security you can verify
- Pricing that doesn't hide things
- Support after launch, and a way out
What should I do before I talk to any software company?
Write one page. What are you solving, who'll use it, what can you roughly spend, when do you need it, and who gets the final say on your side? That last one matters more than people expect. Plenty of projects stall because feedback comes from five people who don't agree.
It's self-defense too. A fuzzy brief gets a fuzzy quote, and then you're comparing three numbers that don't even cover the same work.
Has the company built software like mine?
Ask to see two or three projects that look like yours. Then ring the clients yourself, because a wall of logos on a website doesn't prove a thing.
Once you've got someone on the line, forget the pleasantries. What went wrong? How did the company react? Did the money hold up, and would they sign again? Nobody's project runs smooth, so what you're really testing is how the team acts when it gets bumpy.
Worth a quick look at Clutch, GoodFirms and G2 as well. The three-star reviews are where people tend to be honest. See whether the company answers criticism or just stays quiet.
Who's actually going to build this thing?
Get real names, roles and years of experience, and meet them before anything's signed. Whoever impressed you in the sales meeting probably won't be writing your code.
Find out how long they've been with the company. Whether they're all yours, or half-working on other clients' stuff. How often people get moved off a project. When a team keeps changing, you end up re-explaining your business every couple of months, and that gets old quickly.
How should they scope and price my project?
Properly, which means a discovery phase before anybody says a price. Talk through your users, the systems you already run, and the messy edge cases nobody wants to bring up. You should walk away with paper: a scope, a ranked feature list, a rough architecture, and an estimate with reasoning behind it.
Be suspicious of a confident fixed price after one call. In software the costly errors are building the wrong thing or lowballing the hard bit, and discovery stops both. Does it cost something? Sure. Usually it's cheap compared to the alternative. And if what you get back is just a number, you haven't learned much.
Is their technology choice right for my business?
You can judge this without being an engineer. Ask why they chose this stack. What happens if your users triple? Could another team take it over later?
Two opposite problems to watch for. Some firms push fashionable tools you don't need. Others only know one stack and bend your project around it. A good answer tends to be boring and specific, and it admits when something's a judgment call.
Who owns the source code?
Usually you own custom code once you've paid for it. Don't take that on trust, though. Get it in writing, along with repository access and the cloud accounts.
Details matter here. What about third-party libraries and licenses? Components the vendor reuses across clients? Who holds the repository during the project, and who owns the hosting? You want access from day one, not a big handover at the end. And ask about exit terms, awkward as that feels. If things end badly, can you leave with the code, the documentation and the credentials? Have a lawyer read the contract. This isn't legal advice.
How should a software company communicate during the project?
A single named contact, and something working you can click through every week or two. A status email saying "on track" doesn't count.
More projects die from poor communication than from bad code. Time zones aren't the real issue, speed of reply is, although a few overlapping hours do help. Watch how fast they answer you right now, while you're still a prospect. It almost never gets quicker after the contract's signed.
How do they test what they build?
You're hoping to hear code review, automated tests, a staging site where you can poke around before launch, a bug tracker people actually use, and written documentation.
If the whole answer is "our developers test their own work," push on it. Which kinds of testing: functional, performance, security, compatibility? And what lands in your hands at the end of each sprint? Testing works as a habit across the project. Bolted on at the end, it's mostly theatre.
How do I know my data is safe with them?
Ask how they guard your data and your code. If a certificate gets mentioned, ask to see the actual thing. Get an NDA signed early.
You'll also want to know who can access what, how passwords and keys are handled, what happens to your data when the project wraps up, and whether any of the work quietly goes to subcontractors. Working in healthcare, finance or payments? Ask about the exact rules that apply and request audit reports. A line in a sales deck isn't proof.
How does pricing really work, and what hidden costs should I watch for?
Start with the model, then check what the quote leaves out. Fixed price gives you certainty and makes changes painful. Time and materials gives you flexibility and needs close tracking. A dedicated team suits ongoing product work if you've got your own technical lead.
Then go looking for the omissions. How are change requests priced? Is testing included? Project management? Who pays for hosting and licenses? What does maintenance cost once you're live? And a quote far below the rest isn't a bargain. Usually it's a question you haven't asked yet.
What happens after launch, and can I walk away?
Look for written support terms, a warranty window for defects, documentation that makes sense, and a clean way to hand everything to someone else.
Software doesn't stop needing attention at launch. Bugs, security patches, small changes, they keep coming. So ask how fast they respond and what support costs, then ask the awkward one: could a different team take this over from the documentation and code alone? How they answer shows whether they respect your independence. Good partners aren't afraid of being replaceable.
What questions should I ask in the first meeting?
If you've only got time for a handful, these do the most work:
- Can I speak to a client whose project hit trouble, not only the happy ones?
- Who's on my team, and when do I get to meet them?
- What do I get out of discovery, and what does it cost?
- Who owns the code, the repository and the cloud accounts?
- Say scope changes halfway through. Then what?
- How do you test, and what will I be able to see after each sprint?
- Who can touch my data, and how's it protected?
- What does support cost after launch, and what does it cover?
- If we part ways, how do I leave with everything?
What are the red flags when hiring a software development company?
- Dodgy answers about code ownership or subcontracting
- A confident fixed price after almost no discovery
- A quote far below every other bid
- Reluctance to put you in touch with past clients
- Pressure to sign fast because "the price is only valid this week"
- Promises in the sales call that never made it into the proposal
- A portfolio of mockups with little that's actually live
- A different team at kickoff than the one in the pitch
One or two? Maybe a bad day. Three or four, and you're looking at a pattern.
Can I try them out before I commit?
For a bigger project, start small. Pay for a discovery phase or a few-week pilot first. You get to watch how they communicate, how they react when something surprises them, and whether their estimates hold up outside a pitch deck. It costs a sliver of what you'd lose finding out halfway through. It also gives you something real to compare two finalists on, which no slideshow ever will.
How do I compare the proposals I get?
Work out what matters most to you before the proposals land. Maybe it's experience, maybe team quality, maybe price or communication. Then score every company against that list instead of leaning on gut feeling or the lowest figure.
Make sure each proposal covers the same scope, otherwise you're weighing apples against oranges. And take references seriously. A lukewarm comment from a past client says more than any polished pitch.
Want a second opinion on your shortlist?
Comparing proposals is easier when someone else reads the fine print with you. If you'd like to talk through your requirements, you can read about CodeQlik's software development services or reach out through the contact page.
Loading comments...