What to ask (and what to avoid) when hiring a software shop

The choice that shapes the project

Hiring a software shop is like hiring an architect: the expensive part isn't the construction, it's the mistake of picking the wrong person to lead it. Good partners deliver a bit less than promised but with quality — bad ones promise the world and deliver a zoo.

Since you're not going to become a software expert to make this call, it helps to have a small mental checklist. The questions below separate serious partners from people who'll string you along.

Questions that pay off

1. Who, exactly, will be on the project? Vague answers are a red flag. You want names, short bios, and how much of each person's time will be dedicated. Companies that sell with a senior team and deliver with interns are more common than you'd think.

2. How does day-to-day communication work? Frequency, channel, owner. Good answer: there's a short weekly status meeting, a direct channel with the person building, and concise reports of what was delivered.

3. Can I see similar projects? Real cases, with client name, context, and results — not pretty screenshots without context. If they have no case resembling your sector or problem, not necessarily bad, but ask how they plan to bridge the gap.

4. Who owns the code? Correct answer: you. Everything built should live in your repository, with your team having access. If they lock the code with them, you're hostage.

5. How do you charge for scope changes? In software, scope always changes. Good partners have a clear process — estimate, align, execute. Bad ones either refuse to change or charge each change as a new project.

6. What happens when something breaks in production? You want to hear about warranty, SLA, incident process. If the answer is we'll figure it out, no details — you'll suffer at 3 AM.

7. How does handover work if the partnership ends? Good sign: documented transition plan, clean code, updated docs. Bad sign: nobody thought about it.

Red flags in the proposal

Things that should make you skeptical:

• Fixed price on fuzzy scope. When nobody really understands what'll be built, fixed price means someone will lose. Usually you (in quality) or them (will quit halfway).
• Cronograma too short. If you hear we'll deliver in two weeks for something that feels big, you're being sold.
• Trendy tech as selling point. Are they using tech X because it's trending? Careful. Good tech choice depends on your problem, not the Twitter bubble.
• No discovery. A firm that proposes without interviewing you deeply is guessing. Serious discovery takes days, not hours.

What to look at beyond the proposal

• Reputation. Find former clients and ask without the partner present. Powerful question: would you hire them again?
• Team stability. High turnover inside the shop means your project will change hands. Ask how long people have been there.
• Ability to say no. Good partners refuse bad asks. If everything you suggest gets a yeah, sure, let's do it, you don't have a tech partner — you have an expensive typist.
• Documentation that surplus. Ask to see a sample of documentation they deliver. Good docs mean your team can operate without depending on them forever.

The billing model matters

The three most common models:

• Fixed price per project. Good when scope is very clear. Bad when it isn't — and it rarely is.
• Allocated squad (monthly per team). Good for ongoing projects with shifting priorities. Good also when you're building a product, not just a project.
• Hourly. Good for ad-hoc fixes and small improvements. Bad for big projects, because it aligns the firm's incentive with prolonging.

There's no right model in the abstract — there's a right model for your case. A good partner recommends what makes sense, not what gives them more margin.

How to start on the right foot

Even with the right shop, the first week defines a lot. Good starts usually have:

• A short, well-written one-page project vision document.
• Clear list of who decides what (you decide product, they decide how to build).
• Definition of done for each delivery — not done when it works, done when it works, is documented, and was validated.
• Short weekly meeting and written report of what moved.

Conclusion

Hiring well is half the road. The other half is keeping the relationship healthy — clear communication, scope discussed, expectations aligned. Software is built with people, and good partners work as an extension of your team, not as a distant vendor.

If you're about to hire and want a second, unbiased opinion on the proposal on your desk, I'll read it with you — no fee, no hidden agenda. Send the criteria and the points bothering you.