[Table of contents]Show table of contents
We’ve evaluated ~200 vendors for our own products. We’ve been evaluated ~150 times ourselves. After 10 years: I’ve coded for teams and bought from teams. The gap between good-on-paper and good-in-reality is enormous.
This framework is not an academic list. It fell out of specific projects where something went wrong, or went better than anyone expected. Every criterion has a reason to exist and a way to verify it. See the full menu in our services overview, and real deployments in case studies.
Software house scorecard — 10 criteria
These ten criteria come from failures, not theory. Criterion 3 (team composition) — a junior-only team blew up a 280k PLN project on us. Criterion 6 (rescue) — every mature shop has projects behind it that it had to resuscitate. If a vendor has no such stories, they’re selling you the polished version only.
How to evaluate a vendor’s portfolio?
A vendor shows 5 case studies, all successes — red light. They show one failure and explain how they fixed it — now you listen. That’s the only metric that works.
Ask for 3-5 case studies from your industry or of comparable complexity. Not slide decks, only specifics with metrics. How long did the project take? What was the budget? What went wrong? Add a second test: ask for a reference from a client on a project that had problems. Refusal is disqualification.
2. Delivery process — repeatability over creativity
Ask: what does your typical Sprint look like? Who plays Product Owner? How do you report progress? How do you handle change requests? A mature software house describes its process in 5 minutes because it’s repeatable. A bad one says “we adapt to the client” — which usually means no process at all.
Check whether they have a defined Definition of Done, code review, and CI/CD pipeline from day one. That’s hygiene, not a luxury. In 2026, missing automated testing and deployment signals a company stuck in 2015.
3. Team — meet the people, not the slides
During sales you talk to a salesperson and a senior architect. But who will actually write your code? Insist on meeting the team assigned to your project. Check the senior-to-junior ratio. A junior-only team with one senior mentor is a recipe for disaster above 500 man-hours — we tested it on our own skin, and it cost us a quarter of a million.
Ask about turnover. Above 25% annually means your team will change mid-project. Every developer swap costs 2-4 weeks of lost productivity, and contextual knowledge leaks out with them.
4. Communication — frequency and tools
Seemingly small things generate 80% of frustration in IT projects. Minimum standard: a daily async status, a weekly call with a demo, response time under 4 business hours.
We sent a vendor a technical question on Friday at 4 PM. The answer came on Tuesday. That delta killed the deal. One communication test is worth more than ten promises in a proposal.
5. Approach to failure — a maturity test
Ask point-blank: tell me about a project that didn’t work out. What went wrong? What did you change in your process after that failure? A company that claims it never had a failed project is lying or hasn’t built enough yet. Look for partners who talk about failures openly — that signals a learning culture, not a marketing one.
6. Rescue capability
Does the company have experience taking over projects from other teams? A rescue mission demands fast audit, stabilization, and refactoring. Those competencies also show up in your project when unforeseen problems appear — and they will.
At Do More Soft, rescue missions are around 30% of our projects. Each one taught us more about software engineering than ten greenfield builds. That knowledge translates directly into the quality of new deployments.
7. Pricing transparency
Honest pricing means explaining how the number was calculated. How many hours per module? What risk buffer? What’s in scope, what isn’t? Firms that quote a single figure without a breakdown either price by feel or are hiding costs on purpose. For serious projects, start with a formal audit and consulting engagement — it structures the pricing and removes surprises.
8. Technology fit
It’s not about React vs Vue. It’s about whether the stack fits your context: existing infrastructure, your team’s competencies, long-term plans. A firm that pushes its favorite technology without analyzing your needs is solving its problem, not yours.
Ask: why would you choose technology X for my project? An answer of “because that’s what we’re best at” is game over. The right answer includes an analysis of your requirements, constraints, and growth plans.
9. Cultural fit
A software house’s organizational culture affects every aspect of the partnership. A “yes-man” culture will never tell you your idea is bad. An engineering culture will — and propose something better. Look for partners who can say “no” and explain why. That’s the value you’re paying for.
10. Contract — a safeguard, not a formality
IP, NDA, warranties, termination terms, code escrow, post-deployment SLA. These must be clear before signing. Don’t leave them for the lawyer at the end. A good contract protects both sides and defines expectations. Pay special attention to the exit clause — what happens if the partnership doesn’t work out? Will you get the source code, documentation, and a knowledge transfer?
What questions to ask a software house before signing?
A vendor told us they had a Definition of Done. They showed a list in Jira. Nobody had read it in 3 months. That’s cargo cult. Ask questions that verify practice, not declarations: when did you last update the DoD? Show me a commit with a code review where a senior rejected a junior’s PR. Show me a production incident and the post-mortem.
The framework in practice
Rate each criterion 1-5. Total below 35 — keep looking. A single criterion scored 1 is a deal-breaker regardless of the total. The most common mistakes: picking the cheapest offer (you pay twice when the rescue comes), picking the biggest firm (your project is irrelevant to them), picking based on the pitch deck (slides don’t write code).
This framework is a diagnostic tool. Spot the red flags early — you save months. Ignore them because the proposal looked pretty — you got what you deserved.
Want the scorecard in PDF/Excel? Sign up for the checklist below — we send an editable template with 10 criteria and side-by-side fields for three vendors. If you want us to score ourselves against it — just say so. Score us a 1 on any criterion, and we’ll tell you exactly how we’ll fix it, or recommend a competitor who’s better than us on that one.
FAQ
What are the 10 criteria for choosing a software house? Portfolio (case studies including failures), delivery process (repeatability), team (senior/junior mix, turnover), communication (response time), approach to failure, rescue capability, pricing transparency, technology fit, cultural fit, contract (exit clause).
How to evaluate a vendor’s portfolio? 5 successes without a single failure is a red flag. Demand a reference from a problem project. Check the metrics: time, budget, scope creep, team retention.
What are the red flags when choosing a development partner? No process (“we adapt to the client”), junior-only team, turnover above 25% annually, single-number pricing without a breakdown, yes-man culture, refusal to share a difficult client’s contact, no exit clause in the contract.