A founder came to us after their previous development team went silent. The product was not finished, and they could no longer get answers.
When we talked it through, the code was not the first thing they raised. It was this: nobody took ownership. Tickets and messages passed from one person to the next, each answering a small part of the question, none of them responsible for the whole. The work slipped, the updates thinned out, and a relationship that started with optimism turned into frustration.
I hear versions of that story often. Almost none of it would have shown up in a portfolio.
What most guides tell you to check
Search for how to choose a development partner and you will find the same list: look at their portfolio, check the tech stack, compare prices, read the reviews, think about time zones.
None of that is wrong. A team that has never built anything like your product is a risk, and price matters. But those checks tell you what a team can build. They do not tell you what it will be like to work with them when something goes wrong, and on a first product, something always does.
The things that decide how it goes show up much earlier, in the first conversations, if you know where to look.
Five tests you can run before you sign
1. Do they ask about your business before your features?
Bring your feature list and watch what happens. A team that starts estimating straight away is selling you hours. A team that asks who it is for, what success looks like and what you could launch without is trying to understand the problem. Most software goes wrong in the first few decisions, and you want someone who cares about those.
2. Does the estimate come as a range, with its assumptions written down?
A single, confident number for a product that does not exist yet is a guess dressed up as certainty. A good estimate is a range, with the assumptions behind it spelled out: what is included, what is not, and what would make it bigger. That is not hedging. It shows they have thought about where the risk is.
3. Ask how they handled a missed deadline
Every team has missed one. You are not listening for perfection, you are listening for honesty: when did they tell the client, what did they offer, and what did they change afterwards. If the answer is that it never happens, that tells you something too.
4. Who will you actually talk to every week?
This is the one founders feel most strongly about, and the story above is why. Many teams put their most senior person in the first few meetings, then hand you to someone else once the contract is signed. The trust you built with one person quietly moves to people you have never met.
Ask directly: who is my point of contact after we sign, and will that change? Ask to meet them before you commit.
5. What happens when something breaks after launch?
Launch is not the end. Ask what happens if the live product goes down on a weekend, or at night in your time zone. You want a clear answer about who responds and how quickly, not a promise that nothing will ever break.
Red flags
- A fixed price before they have asked you any real questions.
- No named person who is accountable for your project.
- Yes to everything, including the parts you were unsure about.
- Updates you have to ask for.
- Answers that pass from person to person, with nobody owning the whole.
The short version
Choose the team you would trust with bad news. Capability matters, but you can check it. What you cannot easily check, and what decides most first products, is whether someone will own the problem, tell you the truth early and keep you informed without being chased.
That last part is the promise I make on every project. If you are weighing up partners for your first product, here is how I work with founders, and I am always happy to talk it through.