← Back to Insights

Industry

From Agency to Product Studio: Why Paying for Output Builds Graveyards

December 4, 2025 Updated June 12, 2026 8 min read

Somewhere in your industry right now there’s a 400-million-rupiah system nobody logs into.

It was delivered on time. It matched the spec. The invoices were paid, the handover deck was polished, and the agency that built it lists it as a success story.

It’s also dead. The intended users took one look and went back to WhatsApp and spreadsheets.

Every agency veteran knows this graveyard. The uncomfortable part isn’t that these projects fail — it’s that by agency standards, they didn’t. Everything the contract measured was achieved. The only thing that wasn’t measured was whether the product would work.

TL;DR — the whole guide in five lines:

  • Agencies are paid for output — delivery against spec — so whether anyone adopts the software is nobody’s deliverable.
  • Studios are paid for evidence: the first deliverable is a tested answer to “does this deserve a build?”
  • “Don’t build this” is the tell — a studio can afford to say it; an agency saying it cancels its own revenue.
  • The production budget should unlock on user signal, not a signature on a spec.
  • Four demands work on any vendor: user signal before full budget, weekly evidence, a written kill point, and pricing shaped like decisions.

Split scene: a cluttered agency floor buried in specs and tickets on one side, a focused studio gathered around a glowing prototype on the other — the output model versus the evidence model


The Traditional Agency Model — Paid for Output

Strip the software agency model to its skeleton: client writes a brief, agency estimates, team builds to spec, software is handed over. Payment is tied to output — working software that matches what was specified.

The model made sense when it emerged. Development was expensive, specialized, and scarce; companies needed software and didn’t have developers. An agency filled the gap with exactly what was missing: execution capacity, priced by the hour or by the project.

Notice what’s absent from that exchange. Whether anyone adopts the software is not in the contract. The brief is the truth, the spec is the law, and delivery is the finish line.

In the contractDecides whether the product lives
Working software, built to spec
On-time, on-budget delivery
Real users adopting the product

That single omission shapes every incentive downstream.

Agency delivery model flow: brief, estimate, build, demo, change request, and delayed learning


What’s Broken About the Agency Model

When a vendor is paid for output, four things follow — predictably, structurally, every time:

  • More scope means more revenue. Nobody in the value chain is motivated to cut a feature — even though 80% of features end up rarely or never used.
  • “Don’t build this” means no project. The most valuable advice a vendor can give is the one the business model can’t afford. So it’s never given.
  • Requirements are treated as facts. But a requirements document is a stack of assumptions written in confident language. The agency’s job is to make those assumptions concrete — not to test them.
  • Success is declared at delivery. Which is the one moment guaranteed to arrive before any user feedback exists.

None of this is malice. Agencies are full of skilled, well-intentioned people. But people work toward how they’re paid, and if a vendor is paid for output, you get output. Sometimes that output is the wrong product, beautifully built.

We watched this from the inside. We spent over a decade in this model before starting Synetica, and what pushed us out wasn’t the bad projects — it was the good ones that died anyway: clients committing 400 million rupiah and up, teams building carefully to spec, and not one real user touching the product before launch. The model didn’t fail those clients by accident. It failed them by design, because finding the truth early was never the deliverable.

That’s how graveyards fill up: one professionally executed, fully specified, never-validated project at a time.


The Product Studio Model — Paid to Find the Truth

The product studio model inverts one thing: the first deliverable isn’t software. It’s evidence.

Where the truth arrives: the output model is a straight line — brief, spec, six-month build, delivery — that meets users at launch; the evidence model is a two-week loop that meets them at day 14

That sounds abstract, so here’s what it changes in practice.

The first engagement is small and falsifiable. Instead of a six-month build quoted off a slide deck, the engagement starts with a two-week Blueprint: map the assumptions the product depends on, prototype the riskiest slice, and put it in front of real users before any production code exists. The output is a decision, not a deliverable to file away.

“No-go” counts as a success. This is the structural difference, not a cultural one. When the paid deliverable is the truth — does this deserve a build? — the studio can afford to say “don’t build this.” An agency saying that cancels its own revenue. A studio saying it has just done its job.

The production budget is unlocked by user signal, not a signature. The 200–300 million build starts only after real users have validated the core slice. The biggest commitment in the project rests on evidence instead of confidence.

The build itself runs on weekly evidence. Releases ship weekly or bi-weekly, against the validated map, with usage data feeding each decision. The full mechanics are in our Blueprint methodology breakdown.

The economics follow directly. Validation costs a fraction of production — and every bad idea it kills saves the entire build budget. A 50-million-rupiah Blueprint that stops a doomed 300-million build isn’t a cost. It’s the highest-ROI line item in the project.

Validate it in 2 weeks. A Blueprint session turns your idea into a tested prototype in front of real users — see how Blueprint & Prototype works.


How to Spot the Difference

Plenty of agencies now call themselves product studios — same hourly model, new label. The name tells you nothing. The structure tells you everything:

Product studio versus agency comparison: output focus on one side, user-signal focus on the other

What to checkAgency (output model)Product studio (evidence model)
Starts withYour requirements, taken as factYour assumptions, treated as testable
First deliverableAn estimateEvidence from real users
Success isDelivery against specA correct go/no-go decision
”Don’t build this”Cancels their revenueIs them doing their job
PricingHours, open-endedFixed phases ending in decisions
Pays for being wrongYou, after launchCaught at week two, while cheap

Three fast tells from a single sales conversation:

  1. Ask for a quote off your slide deck. If they give one for a six-month build, they’re an agency — whatever the website says.
  2. Read their case studies. Features and technologies only? Output thinking. Adoption, revenue, decisions changed? Evidence thinking.
  3. Ask for a kill story. A real studio can name a project it stopped or redirected mid-stream. An agency in studio clothing has only launches.

When Each Model Works

To be fair to the output model: it isn’t always wrong. If you’re porting a compliance system, rebuilding a tool your team already uses daily, or wiring a well-understood integration, the demand question is already answered. There’s no assumption to test — you need hands, not hypotheses, and an execution-focused vendor is the cheaper, faster fit.

The test is one question: is there a real chance the intended users won’t adopt this? If the honest answer is yes — new product, new workflow, new market — then demand risk exists, and paying for output before testing demand means you’re carrying that risk alone, at full price. If the answer is genuinely no, buy execution with a clear conscience.

Most teams answer “no” too quickly. That’s how the graveyard grows.


What to Demand from Any Vendor

You don’t need to hire a studio to benefit from this shift. You need to raise the bar on whoever you hire — agency, studio, or internal team. Four demands:

1. User signal before full budget

Refuse to commit the production budget until real users have touched something — a prototype, a pilot, a narrow slice. If a vendor is willing to quote a six-month build from a slide deck alone, you’ve learned what model they’re really running.

2. Week-by-week evidence, not month-by-month demos

The question to ask isn’t “what will be built by month three?” It’s “what will we have learned by week two?” A demo proves progress on output. It proves nothing about demand. Insist on a cadence where each week produces evidence — user sessions, usage data, validated or killed assumptions — not just screens.

3. A defined kill point

Before the project starts, agree in writing on what evidence would stop it. If users can’t complete the core flow, if the pilot shows no repeat usage, if nobody will pre-commit — what happens? If no conceivable evidence could stop the project, you’re not validating. You’re decorating a decision that’s already been made.

4. Pricing shaped like decisions, not hours

Fixed-price phases that each end in a go/no-go beat open-ended hourly billing, because the vendor’s payday stops depending on the project continuing. Pricing structure reveals incentives faster than any sales deck.

If you want the full interrogation list for a discovery call, we’ve published the questions we ask founders — they work just as well pointed at a vendor.


FAQ

What is a product studio?

A vendor whose first paid deliverable is evidence, not software. A studio starts by testing the assumptions your product depends on — with real users, before production code — and treats “don’t build this” as a legitimate, successful outcome. Execution still happens; it just happens after the truth is in.

Product studio vs software agency — what’s the difference?

What gets paid for. An agency is paid for output: working software that matches the spec, with adoption left out of the contract. A studio is paid to find out whether the product deserves to exist, then to build it against validated evidence. Same engineers, opposite incentives.

Is a product studio more expensive than an agency?

Per hour of code, often yes. Per outcome, usually no. Validation looks like an extra line item until it kills one bad build — a 50-million Blueprint that stops a doomed 300-million project just returned six times its cost. The most expensive vendor is the one who builds the wrong thing flawlessly.

How do I know a “product studio” isn’t just a rebranded agency?

Check the structure, not the name: will they quote a long build from a deck alone? Is billing open-ended hourly? Can they name a project they stopped? No kill stories, no kill points, hourly pricing — that’s an agency, whatever the logo says.


The Shift Is a Repricing of Risk

“Agency to product studio” sounds like rebranding, and for plenty of firms it is. The test is never the name. It’s who pays for being wrong.

In the output model, the client pays for being wrong, at the most expensive possible moment: after launch, budget spent. In the evidence model, being wrong costs two weeks and a Blueprint fee — and gets caught while it’s still cheap to change course.

Software vendors will keep building whatever they’re paid to build. The fix is on the buying side: pay for the truth first, and the output takes care of itself.

If you’d rather see what that looks like than read about it, the two-week Blueprint is where every engagement of ours starts — including the ones that end, correctly, at day 14.


Sources

Two weeks to a real answer

Need help putting this into practice?

Book a Blueprint session and we'll turn the ideas in this article into a tested prototype in front of real users—2 weeks, from $3,000.