Hiring a dev studio is one of the most consequential decisions a founder makes. Get it right and you ship a real product in weeks. Get it wrong and you burn through your runway, miss your window, and end up with a codebase that has to be thrown away — which is exactly the situation a lot of founders write to me about.
The difference is almost always detectable before you sign. Here’s what to look for.
Red flags
No verifiable recent work. Every credible studio can point at real products. “Everything is under NDA” for every single project is not a compliance posture, it’s an absence of work. At minimum they should be able to describe an architecture in detail and connect you to a client who will vouch for them.
They won’t let you talk to the engineers. You don’t need to be technical to ask who will actually write your code, and to meet them. If the people in the sales meeting are not the people on the project, you’re buying a re-sold contract and the margin is coming out of your build.
They won’t show you code. A good studio will walk you through a codebase, explain why it’s structured the way it is, or accept a third-party code review as a condition of the contract. Defensiveness here is informative.
100% payment upfront. Milestone-based payment tied to delivered work is the norm. Full payment before a line of code exists removes every incentive that keeps a project moving and leaves you with no recourse.
Vague timelines. “We’ll have something in a few months” is not a timeline. You should get a week-by-week or sprint-by-sprint breakdown with named deliverables. A team that can’t plan the work can’t execute the work.
They say yes to everything. A good studio pushes back — on scope, on timeline, on features that will cost you more than they return. Universal agreement means they’re either not listening or not experienced enough to know what they’re agreeing to. The most valuable thing a senior team tells you is which of your ideas to drop.
No questions about your business. If a studio quotes without asking who your users are, how you make money, and what happens after launch, they’re pricing a spec, not building a product.
Green flags
Weekly demos of working software. Not mockups, not slide decks, not status percentages — running code you can click. This is the single strongest predictor that a team knows how to ship, and it makes drift visible within a week rather than a quarter.
Fixed quotes with an explicit scope document. A well-defined project has a well-defined price, and the scope document should state exclusions as clearly as inclusions. Changes cost extra, and that’s fair — what matters is that the process for handling them is written down before you need it.
Full IP transfer, in writing. When the project ends, you own the codebase, the repositories, the cloud project, the domain, and the store listings. Everything runs in accounts with your name on them, not theirs.
A named point of contact and a communication rhythm. Slack, email, weekly calls — the format doesn’t matter, the consistency does. You should never have to chase a status update.
They tell you what not to build. A studio that trims your scope is protecting your budget at the expense of its own invoice. That is the clearest signal of alignment you will get during a sales process.
Questions to ask before signing
- Who actually writes the code? Will it be the people in this meeting, or a subcontracted team you haven’t met?
- Can I see something you shipped in the last six months? Not three years ago. Recent work reflects the current team.
- Can I speak to that client directly? Curated testimonials are marketing. A live reference call is evidence.
- Who owns the code, the repos, the cloud accounts, and the app store listings? The answer should be “you,” without qualification.
- What happens after launch? What does support cost, and can I bring in my own developers later without friction?
- What’s your process when scope changes? Because it will. You want a written change-order process, not goodwill.
- What would you cut from this scope? The most revealing question on this list. A senior team always has an answer.
- What’s the riskiest part of this project? Anyone who says “nothing” hasn’t thought about it.
Contract terms worth the argument
Most founders negotiate price and ignore the terms that actually determine their outcome:
- IP assignment on payment, covering all code, designs, and assets.
- Milestone-linked payments tied to accepted deliverables rather than to calendar dates.
- Infrastructure in your accounts from day one — not migrated at the end, which is when migrations mysteriously become expensive.
- A defined handoff package: documentation, architecture notes, credentials, and a walkthrough.
- An exit clause. You should be able to end the engagement at a milestone boundary and leave with everything built to that point.
Trust your gut, but verify first
After the research, the references, and the portfolio reviews — pay attention to how the sales process feels. If communication is slow, vague, or evasive while they’re trying to win your business, it will be worse once they have it.
But run the checks anyway. Instinct is a good tiebreaker between two credible studios and a bad substitute for a reference call.
Looking for a studio that clears every green flag on this list? Request a technical triage — I’ll show you my work, my process, and my code. See what I’ve built for clients, how hiring a senior developer works with me, and what an MVP actually costs.