Every custom software vendor shows logos, screenshots, and testimonials.
The problem is that a portfolio with ten logos can mean ten products delivered end to end through full product development, or ten times someone put two developers on someone else's project for three months.
The difference between those scenarios decides whether your project works, and you can detect it before signing anything.
How to read a portfolio for real depth
The first thing worth looking at is the repositories.
Ask for access to a repo from a comparable project and check three concrete things: folder structure tells you whether there was real architecture or code that grew without a plan; commit history shows whether the team worked with real CI/CD (look for workflow configs) or deployed by hand; dependency versions reveal whether they kept the project updated or abandoned it after launch.
A partner with real product experience will have infrastructure diagrams they can show without violating NDAs. Ask them to explain how they scaled a backend on AWS or Firebase for a case with real load.
If the answer is vague, if they cannot talk about auto-scaling groups, cloud functions, or how they handled concurrency, you are looking at a generalist that subcontracts infrastructure.
Stack depth gets verified by asking about technical decisions, not listed technologies. Anyone can put "Flutter, React, AWS" on their site.
The question that separates teams with real experience is "why did you choose native Kotlin for that module instead of solving it in Flutter?" A team with real cross-platform experience knows when Flutter solves 90% of the problem and when you need a specialized engineer for a platform channel to Swift or Kotlin. That trade-off conversation tells you more than any slide deck.
Engagement models and delivery risk
Finding a technically solid team is half the problem. The other half is how you structure the relationship, because the contract model directly determines who absorbs the risk when something goes wrong.
Fixed-price looks safe for the buyer, but hides a trap. The vendor needs to protect their margin, so they inflate the estimate or cut scope when complications appear.
In projects with technical uncertainty (third-party API integrations, AI features, regulatory compliance), fixed-price generates constant friction over what is in and out of scope.
It works well only when scope is completely defined, which rarely happens before building.
Time and materials gives the team flexibility but transfers all the risk to the client. Without a strong internal product owner who can prioritize and control weekly burn rate, T&M becomes a blank check.
It is viable when you already know the team and have velocity data from prior sprints.
The path that best balances risk for both sides combines paid discovery, a closed build, and later expansion. You start with a discovery sprint, scoped to weeks rather than months, defining journeys, wireframes, technical risks, and architecture.
That deliverable gives you a scope precise enough to quote a build with fixed milestones. Only after validating delivery do you expand the team or the product.
At Somnio we follow that path on every project through product discovery, with the exact quote depending on scope, integrations, and regulatory requirements.
The decision between custom software and an off-the-shelf solution comes down to one question: does your business process fit a generic product, or does the software need to fit your process?
When the answer points to the second scenario, the cost of customizing a SaaS ends up exceeding the cost of building something proprietary, especially in fintech and healthtech, where regulatory requirements make every integration unique.
Signals to trust or walk away
Technical due diligence centers on questions that cannot be answered with marketing. Before committing, ask for concrete answers to these.
- What is your engineer retention rate over the last 12 months? High turnover kills projects because domain knowledge gets lost with every change.
A stable team that has worked together on 170+ applications, part of the track record recognized in Clutch's ranking of fastest-growing companies, carries a much lower context cost than a vendor that assembles ad-hoc teams per deal. - Can you show me the CI/CD pipeline of a real project? Not the conceptual diagram, the actual stages and automated tests.
A team that has automated testing, linting, and deployment configured on every project delivers with fewer bugs and more predictability. "We configure it per project" means it is not standardized. - What happens when a technically complex feature shows up mid-sprint? This reveals the decision-making process. A mature partner has a clear protocol for evaluating timeline impact and communicating options. An immature vendor says "we'll handle it" without explaining how.
- How many projects does each developer work on at once? If the answer is more than two, your project will compete for attention.
Trust signals are verifiable. Check their reviews on Clutch and ask for direct contact with at least two past clients, ideally in your industry.
Look for evidence of real technical community participation, like conference talks, open source contributions, or in-depth technical content.
A team that presents at conferences like Fluttercon has an incentive to stay technically sharp because their reputation is on the line.
- Vendors promising aggressive timelines without having done discovery.
- Teams that cannot explain why they chose one technology over another for a specific case.
- Prices significantly below market with no justification are a warning sign, since a discovery sprint that costs half of what is expected probably delivers half of what you need for good architecture decisions.
The final question before signing is about code ownership, intellectual property, and infrastructure accounts. That gets defined in the contract before the first line of code, and any ambiguity in the answer is reason enough to keep looking.
Frequently asked questions
How big does a project need to be to justify a discovery sprint?
Any project where scope carries technical or business uncertainty benefits from discovery, regardless of size. A short, scoped discovery sprint reduces the risk of incorrect estimates that generate friction during the build, especially with third-party integrations or regulatory requirements involved.
Can I evaluate technical quality if I am not technical myself?
You can ask them to explain past technical decisions in business language, like what problem an architecture choice solved or how it affected maintenance cost. If the team cannot translate technical decisions into business consequences, that itself is a warning sign.
Is staff augmentation right for projects with no internal technical team?
Staff augmentation works best when you already have an internal team with clear technical direction, since integrated developers need context and leadership to be productive from the start. Starting from zero, a dedicated squad model with product and architecture included reduces delivery risk.
Does conference participation guarantee good delivery quality?
It does not guarantee anything on its own, but it signals the team has an incentive to stay current and exposes their standards to the community. Combined with standardized CI/CD, talent retention, and verifiable references, it meaningfully reinforces trust.
When does it make sense to choose SaaS over custom development?
When your business process can adapt to the generic product's standard flow without compromising efficiency or compliance. The tipping point comes when customizations on top of a SaaS accumulate a cost higher than building a proprietary solution, something common in fintech and healthtech.
At Somnio Software, we work closely with companies to design and build high-quality digital products using modern technologies and development best practices.
If you're looking for a trusted partner to bring structure, expertise, and innovation to your next software project, we'd love to connect. Contact us to learn how we can help turn your product vision into reality.
