How to Choose the Right Software House

Where should you start when choosing a software house?

Start with your own requirements, not a list of vendors. Write down the business problem the software must solve, the core features, your budget constraints and target timeline. A short brief lets you compare proposals against the same criteria and quickly filter out vendors who do not understand your goal or lack relevant experience.

A useful brief is not a fifty-page specification. Describe your users, the key processes, the systems you need to integrate with, and split features into must-haves and nice-to-haves. Add who on your side will make decisions and how much time they can realistically give the project each week.

It is also worth asking whether you need an external team at all. If the product is your core business and you plan years of continuous development, building an in-house team may make sense. Our comparison of outsourcing vs an in-house team sets out the cost and risk trade-offs.

Finally, shortlist three to five companies. More proposals rarely lead to a better decision; they mostly make the process longer and a fair comparison harder.

What criteria should you use to evaluate a software house?

Focus on relevant project experience, depth in the required tech stack, communication quality, process maturity (discovery, testing, deployment), team stability and transparent pricing. Price matters, but judge it only against these factors. The cheapest proposal frequently becomes the most expensive one once rework, delays and maintenance costs are added up over the following years.

Build a simple weighted scorecard before proposals arrive. For example: domain and technical experience 30%, process and quality 25%, communication 20%, price 15%, contract terms 10%. Adjust the weights to your project, but fix them upfront so you are not bending the criteria towards whichever vendor gave the best pitch.

Notice whether the company asks about business outcomes or only about screens. A partner who asks about your revenue model, users and risks usually proposes a more sensible scope. If your processes are unusual and off-the-shelf tools cannot handle them, check that the vendor has real experience in custom software development rather than just configuring templates.

Ask who exactly will work on your project and whether you can meet them before signing. The people in the sales meeting are not always the people writing the code.

How do you verify a software house's portfolio and references?

Ask for two or three projects closest to yours in scale, industry or technology, and clarify the vendor's exact role in each. Speak directly with former clients, look at live products and, where possible, commission a short paid discovery phase so you can see how the team actually works before committing to a full build.

A portfolio of polished screenshots says little on its own. Ask what the team actually delivered: the whole product or just the frontend, how long the engagement lasted, what went wrong and how it was handled. A trustworthy company will also talk openly about projects that did not go to plan.

When you call a reference, ask about deadlines, how scope changes were handled, documentation quality and whether they would hire the vendor again. Review platforms and LinkedIn help, but a conversation surfaces far more nuance. You can see how we describe projects, with business context, in our case studies.

The strongest test is a paid workshop or discovery phase lasting from a few days to two weeks. You get a tangible output, such as a feature map and initial architecture, and you see first-hand how the team communicates and keeps its commitments.

What red flags should you watch out for?

Be cautious of vendors who quote without asking questions, promise a fixed deadline for a vague scope, price far below the market, have no testing or change management process, avoid discussing code ownership, or cannot name the people who will actually deliver the work. Any one of these significantly raises your project risk.

A quote produced in a day from a short email usually means risk has been hidden rather than estimated. Missing pieces come back later as change requests, extra invoices or lower quality. A serious proposal lists assumptions, exclusions and the open questions that still need answers.

Another warning sign is having no access to the repository or a staging environment during development. You should see progress regularly, ideally every one or two weeks, not only at the end of a milestone. High staff turnover, or one person handling analysis, coding, testing and client contact at once, is also a concern.

If a previous project failed, look back at which of these signs were visible early. That makes the best checklist for your next selection.

Fixed price or time and materials: which engagement model is better?

Fixed price works when the scope is well defined and unlikely to change, such as a small, self-contained module. Time and materials suits products built iteratively, where requirements evolve as you learn. Often the best option is a mix: a fixed price for discovery, then development billed by the hour with an agreed budget cap.

Under fixed price, the vendor carries the estimation risk and adds a buffer to cover it. Every scope change needs renegotiation, which slows delivery and invites disputes about what the contract really covered. The upside is a predictable cost, provided the requirements genuinely stay stable.

Time and materials gives you flexibility: you can reprioritise after every sprint and pay only for work actually done. In return it needs more involvement from you, regular reviews and transparent time reporting. For long-term work, a dedicated development team that acts as an extension of your own IT department is often the most efficient set-up.

Whatever the model, agree a budget limit per phase, the demo cadence and how work is accepted. That protects both sides from surprises.

How much does it cost to work with a software house in Poland?

Cost depends on scope, technology and pricing model. Polish software houses typically charge less than Western European firms for comparable quality. At Midapt the hourly rate is EUR 33, and a mid-sized system usually falls within EUR 14,000 - 47,000. A reliable final figure is only possible after a proper requirements analysis.

When comparing proposals, check what the price includes. Does it cover UX/UI design, testing, infrastructure setup, production deployment and a warranty period? Gaps between quotes often come not from higher rates but from one vendor including work the other left out. QA usually accounts for 15-20% of the budget and is not the place to cut corners.

Plan for costs after launch, too. Maintenance, dependency updates, monitoring and small fixes typically run at 15-25% of the build cost per year. For more on rates, team structure and the market, see our page on software houses in Poland, and for indicative ranges by project type, visit our pricing page.

What should a contract with a software house include?

The contract should cover full transfer of intellectual property rights to the code, repository access, acceptance criteria, a change request procedure, warranty and bug response times, confidentiality, personal data processing terms and exit conditions, including handover of documentation, credentials and infrastructure access when the engagement ends for any reason.

IP transfer rules differ between jurisdictions. Under Polish law, for example, copyright transfer must be in writing and list the specific fields of use, so a vague clause saying the code belongs to the client may not be enough. Have a lawyer familiar with software contracts review the agreement, and ask how open-source libraries and the vendor's reusable components are licensed.

If the system processes personal data of people in the EU, you will need a data processing agreement that complies with GDPR. Also agree what happens at the end of the engagement: who takes over servers, cloud accounts and domains, and when the vendor hands over complete documentation.

A good contract does not assume bad faith. It simply settles situations that, sooner or later, arise in every project.