The 2-Week Blueprint: Know What to Build Before You Pay to Build It

The Blueprint method helps you decide what deserves a production budget. In an illustrative scenario, a company can spend IDR 400 million over eight months and still receive software that does not fit its users’ workflow.

I use Blueprint & Prototype to bring assumptions into user sessions before scope is locked. The evidence is completed tasks, recorded friction, and buyer commitment; agreement in a meeting is not enough.

This guide covers the two-week outputs, decision gate, and path to an eight-week production build. Budget examples are planning scenarios, and the test can still recommend adjusting, waiting, or stopping.

TL;DR — the whole guide in five lines:

• Feature usage differs from product success: Pendo measured rarely used features, not a product failure rate.
• Validate first, build second: collect workflow evidence before locking production scope.
• Two weeks, two phases — week 1 produces a decision-ready blueprint, week 2 puts a working prototype slice in front of real users.
• Day 10 ends in one of four calls — build, adjust, wait, or stop — backed by recorded user sessions, not opinions.
• IDR 49jt buys the decision; the IDR 200jt+ production budget moves only after user signal.

The expensive part of software isn’t building it. It’s building the wrong thing.

---

What Is the Blueprint Method?

The Blueprint method is a two-week validation sprint that turns a raw product idea into a decision-ready plan and a tested prototype — before any production budget is committed. Week one produces the blueprint: requirements, designs, architecture, and estimation, all mapped to evidence from real user interviews.

Week two builds a working slice of the product and puts it in front of real users, ending in one of four clear calls: build, adjust, wait, or stop.

In short: it’s due diligence for software. You spend roughly 15–25% of a build budget to find out whether the other 75–85% is justified.

Here’s how it compares to the discovery phase most vendors sell:

Here’s why that order matters, and exactly how the two weeks run.

Next: Why planning harder doesn’t fix it.

---

Why planning harder doesn’t fix it

The standard reaction to a failed project is more planning. Longer requirement documents.

More stakeholder meetings. More sign-offs before development starts.

It doesn’t work, because the problem was never a lack of planning. The problem is that nobody — not you, not us, not your most experienced manager — can predict what users will actually use.

In its 2019 Feature Adoption Report, Pendo found that 80% of features in the average sampled product were rarely or never used. Low frequency needs investigation; compliance and recovery controls can remain important despite infrequent use.

That study does not compare Agile and Waterfall success rates. The value of a checkpoint is learning what should change before the next investment, without promising a universal success multiplier.

So the fix isn’t a thicker document. It’s flipping the order: validate first, build second.

Think of it like mining for gold. The usual way is months of digging on faith — you find out whether the gold exists only after the money is spent.

The smarter way is to scan the ground first, then dig only where the scan says dig.

That scan is what Blueprint & Prototype does. Two weeks.

Here’s exactly how.

---

The 2-week system, day by day

Blueprint & Prototype is 10 working days, two phases. Week 1 turns your idea into a decision-ready blueprint.

Week 2 builds a working prototype slice and puts it in front of real users.

The whole process runs on Skematika, our blueprint platform — interviews, requirements, and scope decisions become a test-ready plan without weeks of document ping-pong.

Two details matter here.

What do the prototype sessions test?

Author’s note — Ganis Atmawarin: The prototype is working software, not a clickable mockup. Users perform real tasks in it. A Figma prototype tests whether people understand your idea; a working slice tests whether they’ll actually use it. (If you’re weighing the options, here’s when to build a prototype, a pilot, or an MVP.)

The users are real. Not your team, not your friends. The people who’d actually pay for or work in this product. What they do in the sessions counts for more than what they say — and we capture both.

---

What you walk away with

Day 10 isn’t a slide deck — it’s a complete, decision-ready package that any development team can build from:

1. Business requirements (BRD) — the problem, the users, and the business case in one document
2. Feature requirements — every feature mapped to the evidence behind it, with explicit out-of-scope lines
3. Full design mockup — the complete product designed, not just the tested slice
4. Technical architecture — system components, technology choices, integration points
5. Data model — entities, relationships, and flows, ready for engineering
6. Project plan & estimation — what the production build costs and how long it takes, scoped from evidence

Plus the prototype itself — a clickable, working slice on mobile and web — and the user session results: adoption signal, comprehension signal, and where people got stuck.

Any development team can build from this package. Including, but not necessarily, us.

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.

---

The decision gate: build, adjust, wait, or stop

The last deliverable is the one most agencies won’t give you: a straight recommendation. Four possible calls, each with real meaning.

• Build. Users completed the core flow and wanted more. The signal is strong. Move to production — 8 weeks, from $13,000 / IDR 200jt — building only what the evidence supports.
• Adjust. The problem is real, but the solution needs to change. Users hesitated somewhere specific. Revise the slice, retest. Cost of being wrong: days, not months.
• Wait. The idea holds but the timing doesn’t — the market, the budget, or the organization isn’t ready. Park it with the blueprint intact. Common for teams testing a new market before committing headcount.
• Stop. Users didn’t care. That stings for two days — and saves you eight months and IDR 200jt+. A stop at week 2 is the cheapest outcome in product development.

Notice the incentive: we recommend stop when the evidence says stop, even though “build” is what we’d get paid for. The blueprint is yours either way.

That’s the point of separating the validation fee from the build fee.

---

What it costs vs. what it saves

Blueprint & Prototype starts at $3,000 / IDR 49jt. Production-grade development starts at $13,000 / IDR 200jt — and most custom builds in Indonesia run IDR 300jt or more before a single real user has touched anything.

So the real comparison is:

The blueprint fee is roughly 15–25% of the build cost, and it’s the only stage where “we were wrong” costs days instead of months. If the answer is build, you’ve lost nothing — the blueprint becomes the production spec.

If the answer is anything else, IDR 49jt just bought you out of an IDR 200jt+ mistake.

Next: FAQ.

---

The next step

If you’re sitting on an idea — or a budget request for one — don’t start with a development quote. Start with two weeks of evidence.

1. Book a 30-minute call. We’ll tell you honestly whether Blueprint & Prototype fits — and if your case is already proven, we’ll say so and skip straight to scoping the build.
2. Week 1: decision-ready blueprint, signed off.
3. Week 2: working prototype, tested with your real users.
4. Day 10: build, adjust, wait, or stop — with the evidence to back it.

Two weeks. IDR 49jt.

One decision you won’t have to defend on faith.

See how Blueprint & Prototype works → or book a discovery call.

---

FAQ

How much does product validation cost?

Blueprint & Prototype starts at $3,000 / IDR 49jt — roughly 15–25% of a typical production build, which starts at IDR 200jt and often runs past IDR 300jt in Indonesia. Compare the two failure modes: a wrong assumption caught on day 14 costs the blueprint fee; the same assumption caught at launch costs the entire build budget.

Validation isn’t an extra line item — it’s the cheap version of a lesson you’ll pay for either way.

What if I already know what to build?

Maybe you do. Pendo measured feature usage, not how confident teams were before building. Test your own workflow with users before treating confidence as evidence.

If you’re right, two weeks produces the evidence to prove it — to your board, your investors, your own engineers — plus a build-ready spec. If you’re wrong, you find out for IDR 49jt instead of IDR 200jt.

Confidence without evidence is just optimism with a budget.

Blueprint vs traditional discovery — what’s the difference?

Traditional discovery runs 4–12 weeks and produces documents: a PRD, wireframes, a roadmap — and still no proof that users want the thing. Blueprint runs 2 weeks and produces a decision: assumptions are made explicit and tested against real users in working software, and the output is a build / adjust / wait / stop call backed by recorded sessions.

Documents tell you what the team agreed on. Decisions tell you what users did.

Can we run product validation ourselves?

The method isn’t secret: interview users, scope a slice, build it, test it. What’s hard internally is honesty and speed.

Your team has opinions to defend and a roadmap to protect; a deadline that’s “two weeks” internally becomes two months. We have no attachment to your idea surviving — only to the answer being right by day 10.

If you do run it yourself, start with the discovery questions we ask founders.

Is two weeks enough for real research?

For a market study, no. For a build decision, yes — because the strongest evidence isn’t another interview, it’s watching real users attempt real tasks in working software.

Day 9 of this process produces more decision-grade signal than a month of surveys. Behavior beats opinion.

Sources

• CB Insights: The Top Reasons Startups Fail
• Nielsen Norman Group: Why You Only Need to Test with 5 Users

Related Posts

• What the 80% Unused-Feature Finding Means
• Pilot, Prototype, or MVP? What Founders Should Build First
• 12 Discovery Questions Every Founder Should Ask Before Building