How to choose a software house: 10 essential criteria in 2026

Hiring the wrong software house can be very expensive: months of delay, rework, burned money and a system no one uses. In over 20 years developing projects for companies of all sizes, we have seen the same mistakes repeat themselves in almost every failure.

In this guide, we list the 10 criteria that separate a good software house from an expensive trap. Use it as a checklist on your next hiring, and if the company you are evaluating fails on more than 3 of them, consider looking elsewhere.

Why the wrong choice costs so much

A poorly hired software project rarely fails all at once. It rots in slow motion: deadlines are pushed, scope changes without explanation, bugs accumulate, and when you notice, you have already invested a whole budget in something that needs to be redone from scratch. The worst part is that many only discover the size of the problem when the competitor launches first.

The invisible costs are usually bigger than the original budget:

• Your managers' time: endless meetings trying to figure out what is happening in the project
• Opportunity cost: while your system is delayed, the competitor launches and captures market share
• Technical debt: bad code becomes a nightmare for maintenance and evolution
• Internal trust erosion: teams give up on technology after a bad experience, and this blocks future projects

"We have rebuilt expensive systems that other companies charged for and delivered not working. The client lost the money, but the worst was losing 18 months of market."
Alexandre Rosa, Reiko founder

The 10 essential criteria

Before signing any contract, validate the software house with this checklist. These are the points that most often we have seen separate who delivers from who only promises.

1. Portfolio with real and measurable cases

It is not enough to see a list of logos in the footer. Ask: what problem did each project solve? How much did it save or generate in revenue? How long did it take from contract to delivery? A serious software house speaks in concrete metrics, not vague adjectives like "innovative" or "robust". Ask for at least 3 detailed cases in your industry.

2. Modern and justified technology stack

Ask why they chose React over Vue, Node over PHP, AWS over Azure. The answer must make sense for your case, not just for theirs. Beware of companies that only know one stack: they will force you to use it even when it is not the best option.

3. Discovery process before quoting

Whoever quotes price by WhatsApp message is not selling software, they are selling lottery. A serious software house does discovery: understands your business, maps processes, prototypes screens, validates hypotheses, and only then quotes with precision. This work takes 1 to 3 weeks and is usually charged separately: whoever offers it for free may be embedding the cost in the contract.

4. In-house team, not outsourced freelancers

Ask exactly who will work on your project. Are they full-time employees? Exclusive contractors? Remote freelancers picked from platforms? The difference is huge in quality, commitment, continuity and future support capability. Software houses that outsource to freelancers without you knowing are one of the biggest sources of project problems.

Technical signs that separate wheat from chaff

Beyond commercial criteria, there are five technical signs that distinguish mature from beginner software houses:

• Code versioning (Git): all code must be in GitHub, GitLab or similar, with commit history reviewable by you
• Automated tests: serious systems have minimum 60% coverage in critical code, especially in business rules
• CI/CD (automated deployment): no manual "uploading" to production via FTP: that is 2000s practice
• Technical documentation: clear README, drawn architecture, decisions recorded in ADRs or similar
• Monitoring and observability: when there is a problem in production, the software house must know before you complain

What NOT to hire

Some patterns guarantee headache. Run if the software house fits any of these:

• Has less than 3 years of active business, especially for critical projects
• Refuses to deliver source code at the end of the contract (yes, this still happens)
• Does not accept contracts with SLA clauses, late penalty and intellectual property
• Promises everything, gives huge discount just to close and has team too small for the scope

Remember: cheap is expensive, especially in software. A poorly made system costs 3 to 5 times more to redo than to do right the first time. And the lost time you do not recover.

How to evaluate the proposal

Instead of chasing a loose number, look at how the proposal was built. Three points separate a serious proposal from a guess:

• Breakdown per stage: discovery, design, development, QA and infrastructure quoted separately, with deliverables and hours per stage instead of one single number with no explanation
• What is included and what is not: data migration, training, technical documentation, staging environment and every integration named one by one, with what stays out written down
• Warranty and what comes after: post-launch warranty period, what counts as a fix (at no cost) and what counts as an evolution (quoted separately), plus the maintenance model and the monthly running cost

A proposal that arrives as one round number, with no breakdown and no deliverables, is asking for blind trust. Whoever charges far below the competitors is saving on quality, team or both. Whoever charges far above needs to explain exactly why: usually it comes with management layers and overhead that do not add value to you.

How to conduct the selection process

If you are serious about hiring, follow this 5-step process. Taking 2 extra weeks here saves 12 months later:

1. Define the problem, not the solution: write 1 page describing what your company needs to solve, without saying "how". Let the software house propose the best technical path
2. Select 3 to 5 candidates: one referral is not enough. Compare proposals to understand the market and calibrate expectations
3. Have a technical call with the team that will work on the project: do not only talk to sales. Ask to talk to the real tech lead and developers
4. Ask for references and call them: 3 previous clients minimum. Ask if they would hire again and what they would change
5. Start with paid pilot scope: before closing a large project, hire a paid discovery sprint. You evaluate much better than in commercial meetings

Conclusion

Hiring a software house is one of the most expensive decisions your company will make in the next few years. The total cost of the wrong choice, adding rework and lost opportunity, easily exceeds three times the original budget.

Use this checklist in your next evaluations. If you want a second opinion on a quote you have already received, or if you are looking for someone who delivers custom web systems with predictability, talk to our team. Initial analysis is free.

Frequently asked questions about choosing a software house

How much is reasonable to charge for a software house?

The important thing isn't the absolute number, it's how the number breaks down. A serious software house shows a budget separated by stage (discovery, design, development, QA, infra) and says what is included in each one. Compare proposals by breakdown and deliverables, not by the total: a price much below the competitors almost always means cutting QA, design or team seniority, and that turns into rework later. The figure for your case comes in the proposal, once the scope is clear.

Can I pick the cheapest software house and have it work out?

Technically possible, but probability is low and the cost of error is high. Most software houses that charge half the market do one of these: (a) use freelancers without you knowing, (b) cut QA and design stages, (c) deliver the contract minimum and charge extra for everything that was "out of scope". The practical result is waste: you pay a lot to receive something that doesn't meet needs, then pay again for another company to redo it. Worth paying the price of whoever actually delivers.

How to know if the portfolio is real and not makeup?

Ask for contact of 2 to 3 recent clients and call them. Ask: was the deadline met? Bugs in production? How was project communication? Does the software house still provide support today? Real client responds with details; made-up case has 1 generic sentence and the "client's" phone number rings someone from the company itself. Also observe if portfolio projects are live and working: broken links or "site under maintenance" are classic red flags.

Is it better to hire a local software house or can it be from another state?

For custom projects with need for immersion (ERP, marketplace, complex SaaS), local or at least same time zone helps a lot in the first 2 to 3 months: in-person meetings accelerate alignment. For medium well-documented projects, remote Brazil (any state) works well as long as there is discipline of weekly video meetings and demos every sprint. Off-shore (India, Vietnam, Argentina) only makes sense for large projects with a dedicated bilingual PM on your side, otherwise hidden cost (time zone, language, legal) exceeds savings.

How does the contract protect source code and intellectual property?

Explicit clause of total assignment of copyright of delivered code to the contractor, code deposit in a repository you access (private GitHub/GitLab of your company, not of the software house), delivery of technical documentation and production environment under your cloud credentials (AWS/Google Cloud in your company's account, not the supplier's). Without this you're hostage: in case of conflict the supplier can hold deploy or hinder transition to another company.