How to Choose a Software Development Studio Without Getting Burned

The most common way founders get burned is not fraud. It is a studio that is genuinely busy, genuinely well-intentioned, and structurally unable to ship. Six months in you have Figma files, a component library, a staging URL that nobody outside the team has ever used, and an invoice history that looks like a mortgage.

The second most common way is a cheap build that works in the demo and falls apart the week you get real customers. No tenancy model, no migration story, secrets in the repo, one Postgres box someone set up by hand, and a codebase nobody who is still on the project has read. Rebuilding that costs more than building it properly did.

We have been on both sides of this. We have inherited codebases where the previous team's deployment process was a person with SSH access, and we have migrated over a hundred tenant databases off a platform we then decommissioned. What follows is what we would check if we were the buyer, in the order we would check it.

Judge production operation, not portfolio screenshots

Screenshots prove someone designed a screen. They prove nothing about whether the thing survived contact with users. The distinction that matters is whether a studio has operated software after launch — on call, with real tenants, with data that cannot be lost.

Ask questions that only an operator can answer:

• "Walk me through your last production incident." You want a specific failure, a detection path, a fix, and what changed afterward. A studio that has never had an incident has never had traffic.
• "How do you deploy, and how do you roll back?" If rollback involves a human editing a server, they have not run anything serious.
• "How do database migrations work when you have hundreds of tenants?" The answer should include ordering, backward compatibility, and what happens when tenant 84 fails halfway through.
• "Who was on call for the last thing you shipped, and are they on this project?" Sales engineers and delivery engineers are frequently different people.
• "Show me something you decommissioned." Shutting a platform down cleanly is harder than launching one, and almost nobody claims it because almost nobody has done it.

Our own answers come from products we still run. Retailer OS has an offline-capable point of sale that reconciles when the network returns, which is a category of bug you only learn by shipping it to a store with bad Wi-Fi. BuildAEC runs vision-model takeoff over raw construction plans with per-line confidence scores, which forced us to design human review into the product rather than bolt it on. Both are written up in our portfolio with the architecture, not just the marketing.

Demand a scope artifact before you sign anything

The single strongest predictor of a bad engagement is a proposal that prices a vision. "Build the platform described in your deck — $180,000, six months" is not a scope. It is an option on your budget.

What you want instead is a written artifact that names the first shippable slice, the users who will touch it, and the things explicitly excluded. We treat exclusions as the most valuable part of the document, because that is where disagreements surface early instead of in month four. If a studio will not write down what they are not building, they have not thought about it.

A usable scope artifact contains, at minimum:

1. The one workflow that goes end to end first, named as a user action — not a feature area.
2. The data model for that workflow, at least as entity names and relationships.
3. Auth, tenancy and roles decided, not deferred. Retrofitting tenancy is a rewrite.
4. Named integrations with their auth mode and rate limits, because third-party APIs set your real timeline.
5. An explicit exclusion list, including the features you agreed to want later.
6. A definition of done that involves a real user, not a demo.

If you are still shaping the first slice, do that work before you shop for vendors. We wrote up the method we use in scoping an MVP that ships in weeks, and the related question of whether to build at all is covered in build versus buy. Arriving with a scope makes every proposal you receive comparable, which is the whole point.

The four-week test

Here is a decision rule we would apply as a buyer, and one we are happy to be held to ourselves.

If a studio cannot put something a real user can log into in front of you within four weeks, do not sign a six-month contract with them.

Not a prototype. Not a clickable design. Deployed, authenticated, with a database behind it, doing one narrow thing correctly. It can be ugly. It can handle exactly one workflow. It has to be real.

This test works because it exercises every capability that actually predicts delivery: environment setup, CI, auth, data modeling, deploy, and the studio's willingness to cut scope to hit a date. A team that fails it in four weeks will fail it in twenty-four, just more expensively.

Structure the commercial relationship to match. Buy a small paid discovery-and-first-slice engagement, priced separately, with the larger build as an option you exercise afterward. Both sides get information that no amount of reference-calling produces. If the studio resists splitting the engagement, ask why the risk should be entirely yours.

When this rule does not apply

Some work genuinely cannot show a login in four weeks. Hardware integration where the device does not arrive for six weeks. A migration off a legacy system where the first month is reading someone else's schema and building a reconciliation report. Regulated environments where the audit and access review has to land before any code touches real data. Deep model work where the first month is data collection and evaluation harnesses.

In those cases, replace the deliverable but keep the deadline. Four weeks to a reconciliation report that names every row that will not migrate. Four weeks to an evaluation set with a measured baseline. The point is a falsifiable artifact on a short clock, not the login screen specifically.

Contract terms that matter more than the rate

Founders negotiate the hourly rate and sign the rest. The rest is where you get trapped. These are the clauses we would not sign a build contract without.

• IP assignment on payment, not on completion. "Completion" is a word the studio defines. If the engagement ends early, you need to own what you paid for.
• Your repo, your cloud accounts, day one. Code lands in an organization you control. Infrastructure runs in your AWS, Cloudflare or Supabase account, billed to your card. A studio that insists on hosting your production data in its own account has a leverage clause disguised as convenience.
• Infrastructure as code, or it is not delivered. Hand-built infrastructure is undocumented infrastructure. Require Terraform, Pulumi, or equivalent, and require it to be able to build a fresh environment.
• A named exit deliverable. A runbook covering deploy, rollback, secrets rotation, backup restore and on-call escalation. Write it into the contract as a milestone or you will get a Notion page written the week they leave.
• No exclusivity on your own product. You can hire another engineer, or another studio, without penalty.
• Change control with a price. Every scope change gets written down with a cost and a schedule impact, signed by both sides. This protects the studio too, which is why good ones ask for it.
• Termination for convenience with a short notice period. Thirty days is reasonable. A twelve-month lock on a build you cannot evaluate is not.

Two more that get skipped. Get the AI clause explicit: what tools are used, whether your code or data ever goes into a third-party training set, and who pays for model spend. And get the subprocessor list, because "our team" sometimes means a marketplace contractor you have never spoken to.

Reading a proposal for the parts that are missing

Proposals are easy to read for what is in them. The signal is in the omissions. Scan for these six and ask about every one that is absent:

• Tenancy. Shared schema or database per tenant, and why. If this is not decided, the cost estimate is fiction.
• Data migration. Where existing data comes from, in what shape, and how bad rows are handled. Almost always underestimated.
• Auth and roles. SSO, invitations, role changes mid-session, and what support staff can see.
• Billing. Plans, mid-cycle changes, proration, dunning, and what happens on downgrade. Billing is a subsystem, not a Stripe integration.
• Observability. Logs, traces, error tracking and alerting, named as tools with owners.
• Cost of running it. A monthly infrastructure estimate. If a studio has never had to care what a build costs to operate, it will show.

A proposal that addresses all six will look more expensive than one that does not, and it is not. The cheap proposal has the same work in it, just unpriced and scheduled for the month after you thought you were done. Our view on where the money actually goes is in what a custom SaaS platform costs to build.

Match the studio to the shape of the problem

Generalists are fine for a CRUD app on a known stack. They are a poor bet when the hard part is unusual — offline sync, per-tenant database fleets, hardware a browser cannot reach, retrieval over messy documents, marketplace sync where four APIs disagree about what a product is.

For those, ask a narrow technical question and listen for whether the answer contains a failure mode. Ask how they would handle two offline terminals selling the last unit of stock. A studio that has shipped offline says something about conflict resolution and an oversell policy the business has to choose. A studio that has not says "we sync on reconnect."

Same test for AI features. Ask what happens when the model is wrong. If the answer is a better prompt, keep looking. If it is confidence thresholds routing low-scoring output to human review, an evaluation set, and a cap on spend per tenant, they have run this in production. That is how takeoff works in BuildAEC, and it is a design decision, not a model choice.

Finally, weigh what happens after launch. Software you own is software you operate. Ask who fixes the 2am page in month seven, what the support arrangement costs, and how a handover to your own hires would work. A studio that has an answer ready has done it before. Ours is written down in how we work, and if you want to test any of the above against a real scope, tell us what you are building.