How to Hire a Software House: What to Evaluate

The Attractive Portfolio Hides a Lot

Every software house has success case studies on their website. The projects shown are the best ones, photographed from the best angle, with carefully selected testimonials. What you don't see are projects delivered six months late, clients who lost access to their own code, or maintenance contracts that turned into permanent hostage situations.

Hiring a software house is one of the most important decisions a technology manager can make. The impact extends for years — in maintenance cost, in the ability to evolve the product, in the quality of code that will remain in your repository. This guide covers what to evaluate beyond the pretty portfolio images.

Process: How They Work Day to Day

A software house's working methodology determines their ability to deliver predictably. Ask directly:

What is the requirements gathering process? A serious company will want to understand your business before presenting any proposal. If you receive a detailed proposal at the first meeting, without in-depth interviews or questionnaires, be suspicious — the requirements were made up.

How are sprints and deliveries organized? Agile methodologies like Scrum or Kanban work well when properly applied. The problem is when "we're agile" just means "we don't document anything." Ask which ceremonies are conducted, how often the client participates, and how demands are prioritized.

Who is the technical point of contact? You need someone with technical authority to answer architecture questions and make decisions. If the answer is "anyone on the team," the burden will fall on you every time a difficult decision arises.

What is the code review process? Professional teams have pull requests, peer code reviews, and documented quality standards. If there's no formal code review, the code will be inconsistent and hard to maintain.

Communication: Frequency, Channel, and Team Access

Poor communication is the number one cause of projects that fail despite competent technical teams. Set clear expectations before signing any contract.

What is the frequency of progress reports? Weekly is the minimum reasonable for active projects. More frequent for critical ones. Reports that only arrive when you ask are a red flag.

What is the official communication channel? Email, Slack, Teams — the channel matters less than consistency. The problem arises when the project is managed via personal WhatsApp, where messages get lost and there's no organized history.

Do you have direct access to developers? Many software houses create a management layer that blocks direct access to the technical team. This can protect the team from interruptions, but it can also mask technical problems. Define when and how you can escalate technical questions directly.

What happens when a developer leaves the team? Turnover in software houses is high. If the entire project lives in one developer's head, you're at permanent risk. Ask how knowledge is documented and transferred.

Contract: Code Ownership and Critical Clauses

The contract is where friendly conversations become legal commitments. Read carefully and, if necessary, consult a specialized attorney before signing.

Who owns the produced code? This is the most important clause. The code must belong to the client — not the software house. Contracts that keep intellectual property with the vendor create permanent dependency. If you ever want to switch vendors, you'll have to pay again for what was already developed.

Is the code delivered in the client's repository? Insist on a Git repository in your own organization's account (GitHub, GitLab, or Bitbucket) from the first commit. Don't accept "we deliver at project end" — end of project can mean never, if the relationship deteriorates.

What are the SLA clauses for maintenance? If the system goes down at 2am, in how many hours do you get support? Vague contracts like "we'll respond as quickly as possible" aren't adequate for critical systems.

How is scope change handled? Every project has scope changes. Well-drafted contracts describe the impact assessment process and approval of additional costs. Beware of vendors who accept any change without discussion — the cost will appear somewhere.

Red Flags: 7 Signals That Something Will Go Wrong

Based on common patterns in failing projects, watch for these signals:

1. Proposal sent the same day as the first meeting. Serious projects take time to estimate correctly. Speed here is a signal that scope was ignored.

2. No questions about business rules. If the software house didn't ask hard questions about how your business works, they won't be able to build a system that meets your real needs.

3. Price significantly below competitors. Software development has a cost. A very low price means cheaper team, less experience, fewer dedicated hours, or worse, code reused from previous projects without adequate adaptation.

4. No references from previous clients. Ask for direct contact with two or three previous clients. If the company can't or won't provide this, it's a negative signal.

5. Untested code or no testing documentation. Ask what the project's test coverage is and if there's a staging environment separate from production.

6. Poorly defined delivery process. "We deliver when it's ready" is not a methodology. Delivery milestones, acceptance criteria, and review processes should be documented.

7. Resistance to code audits. A company confident in the quality of their work won't object to an independent technical review before signing the contract.

Evaluation Checklist

Use this checklist when evaluating software house proposals:

• Documented requirements gathering process
• Agile methodology with defined ceremonies
• Git repository in the client's account from the first commit
• Contract with intellectual property assigned to the client
• Defined maintenance and support SLA
• Change request process with cost approval
• Previous client references available
• Staging environment separate from production
• Formal code review in the development process
• Technical documentation included in scope

Conclusion

Hiring a software house involves much more than evaluating portfolio and comparing prices. The work process, communication structure, contractual clauses about code ownership, and red flags in the commercial process are equally important.

SystemForge was built on documentation and transparent processes. We work with client repositories from the first commit, agile methodology with documented ceremonies, and contracts that guarantee 100% intellectual property to the client. If you want to understand how this works in practice, talk to our team.