Choosing a software house is closer to hiring a team than to buying a product. The application you receive depends on the people who build it, how they work, and what happens after launch, and most of that is not visible in a portfolio or a price. A structured selection process takes a few weeks, but it is far cheaper than discovering halfway through a project that the partner cannot deliver.
Software House, Freelancer, or In-House Team
| Option | Strengths | Watch out for |
|---|---|---|
| Software house | A complete team with design, development, testing, and project management, available quickly | Quality varies widely between companies, and continuity depends on the contract |
| Freelancer | Lower cost and flexible for small, well-defined work | One person is a single point of failure for availability and knowledge |
| In-house team | Full control and knowledge stays inside the company | Hiring takes months, and a small team lacks some specialist skills |
Many companies combine these. A software house builds the first version and transfers knowledge, while the company gradually builds an internal team, or a dedicated team from the software house works as an extension of the internal one.
Check Relevant Experience
A large portfolio matters less than a relevant one. Look for projects with similar complexity, integrations, or industry: an application with approval workflows, ERP integration, and many user roles is very different from a company profile website. Ask for a walkthrough of one or two projects that resemble yours, including what went wrong and how it was handled. A team that can explain its trade-offs clearly has usually made them deliberately.
Meet the People Who Will Do the Work
The people in the sales meeting are often not the people who will build the application. Ask who will lead the project and the technical work, how experienced they are, and how many other projects they handle at the same time. Ask what happens if a key person leaves during the project. A partner that introduces the actual team before signing has nothing to hide.
Ask About the Engineering Process
- How are requirements captured and confirmed before development starts?
- Is every change reviewed by another developer before it is merged?
- What automated tests are written, and who tests the application before each release?
- Is there a staging environment where you can try new features before they reach users?
- How is the application deployed, and can a bad release be rolled back quickly?
- What documentation will you receive at the end of the project?
Concrete answers with examples are a good sign. Vague answers such as "we always test thoroughly" without describing how usually mean the process depends on individual habits.
Make Sure You Own the Source Code
The contract should state that the source code and related intellectual property belong to your company once the agreed payments are made. In practice, ask for the repository to be created under your organisation's account, or for access from the first week, so you can see progress and are never locked out of your own application. The same applies to servers, domains, and third-party accounts: they should be registered in your company's name.
A simple check: ask whether you can have read access to the repository from the first sprint. A partner that hesitates is telling you something about how the end of the project might go.
Read the Contract for Scope, Changes, and Warranty
- Scope: a written list of features and what is explicitly excluded, so both sides have the same picture.
- Change requests: how new or changed requirements are estimated, approved, and billed.
- Payment milestones tied to working deliverables you can test, not only to dates.
- Warranty: how long after launch bugs are fixed at no extra cost, and what counts as a bug.
- Termination: what you receive, including code and documentation, if the project stops early.
Agree on Communication and Support
Regular, predictable communication prevents most project surprises. Agree on a weekly progress update, a demo of working features every one or two weeks, and a single point of contact on each side. For applications the business depends on, also discuss support after the warranty: response times for incidents, monitoring, security updates, and how ongoing improvements are handled. Being able to meet in person when needed, for example with a partner in the same city, also helps during requirements and acceptance testing.
Warning Signs
- A price far below other quotes, with no explanation of what is excluded.
- A fixed quote from a short brief, without questions about users, integrations, or data.
- Promises that every feature can be delivered quickly, with no discussion of trade-offs.
- No access to the code or the working application until the final payment.
- No mention of testing, code review, or a staging environment.
- One person who handles sales, design, development, and support alone.
A Practical Selection Process
- 1Write a brief covering the business problem, users, required integrations, expected scale, budget range, and target timeline.
- 2Shortlist three software houses with relevant experience, and send each the same brief.
- 3Hold a session with each one to discuss the brief, meet the proposed team, and ask about their process.
- 4Compare the proposals by scope, assumptions, process, code ownership, warranty, and support, then by price.
- 5Start with a short paid discovery phase or a small first milestone before committing to the full project.
Key takeaways
- Choose a software house the way you would hire a team: experience, people, and process matter more than the portfolio size or the lowest price.
- Meet the people who will actually build the application, and ask how they review, test, deploy, and document their work.
- Make sure the source code, repository, servers, and accounts belong to your company, with access from the start.
- Read the contract for scope, change requests, deliverable-based milestones, warranty, and termination.
- Start with a small paid phase before committing to the full project.
