--- title: What a 2-Week PoC Looks Like url: https://varstatt.com/jurij/p/what-a-2-week-poc-looks-like author: Jurij Tokarski date: 2026-04-07 description: Rapid prototyping service structured as a 2-week engagement. Validate the riskiest technical assumption, get a working prototype + go/no-go. section: Blog (https://varstatt.com/jurij/archive) tags: retainer-shapes (https://varstatt.com/jurij/c/retainer-shapes) --- A proof of concept is the fastest way to test whether an idea is technically buildable — a technical feasibility study run as working code, not slides. The retainer runs at $997/week. A PoC is two weeks — the shortest preset shape. Same retainer, agreed duration, specific outcome: validate one technical assumption before spending six weeks on an MVP. Most rapid prototyping services and prototype development service offerings build a demo of your full product vision. That feels productive but proves nothing. A business plan tells you what might work. A proof of concept shows you what actually works — or doesn't. ## Throwaway Code Is the Feature Most rapid prototyping shops will tell you "the PoC code becomes the foundation of your product." It sounds responsible. It's also wrong, and it's the framing that makes most PoCs fail at the job they're meant to do. A proof of concept's job is to be wrong cheaply. It tests one specific assumption — real-time sync, AI cost at scale, payment routing — and answers it with working code that takes shortcuts everywhere it can. No auth, no UI polish, no test coverage. Just enough scaffolding to make the risky part real. The moment you start building a PoC that "could become the MVP," you've stopped doing a PoC. You're now doing an underbuilt MVP — slower, more expensive, and worse at the only question that mattered. You'll defend bad shortcuts because you don't want to throw them away. You'll spend two weeks proving nothing. I've written about this from the other direction in [If You Throw Away Your MVP Code, It Wasn't an MVP](/jurij/p/if-you-throw-away-your-mvp-code-it). MVP code stays — it becomes the product. PoC code is the opposite case: it goes in the bin once it's answered the question. That's not a failure mode. That's the design. What survives a PoC isn't code. It's the answer: build, pivot, or stop. ## What the Two Weeks Look Like Day 1 is technical discovery: mapping the business model, identifying the riskiest assumption, shaping the scope. The [Business Model Canvas](/discovery/business-model-canvas) and [Feature Prioritization](/discovery/feature-prioritization) tools compress what could be a week of back-and-forth into a single session. Days 2 through 8 are the focused build. Proof of concept software that tests the core hypothesis — no login screens, no dashboards. If the risk is real-time sync, we build real-time sync. If it's AI cost at scale, we instrument cost per call under realistic load. The final days are user testing, results review, and writing the recommendation. The deliverable is a clear go/no-go: continue to MVP, pivot, or stop. ## Proof of Concept vs Prototype vs MVP These three get mixed up constantly. The distinctions matter because they shape what you build and how much you spend. A **prototype** is a visual mock — clickable Figma, a static demo, sometimes a no-code build. It tests whether the idea makes sense to a user. No real backend. A **proof of concept** is working software that tests one specific technical question. Can this scale? Does the AI cost work out? Will the integration hold under load? It exists to answer a question that a Figma file cannot. An **MVP** tests the market — will people pay, do they return, does the growth loop work. It's the first real version of the product. Running them in the wrong order is expensive. Spending $6K on an MVP only to discover the core technical assumption doesn't hold is a worse outcome than spending $2K on a PoC first. ## Who This Is For A founder with a specific technical risk — real-time sync, AI integration, payment complexity — who wants to validate technical feasibility before committing to a full build. Two weeks of focused proof of concept development costs $1,994 — the alternative is six weeks into an MVP build before realising the core assumption was wrong. An investor asking "can this actually be built?" who needs a credible answer, not a slide deck. A domain expert who wants to test before signing off on $50K of MVP development. In all three cases, the value is the same: replace a guess with a working result. If you have a technical assumption you're not confident in, the [business model canvas](/discovery/business-model-canvas) and [feature prioritization](/discovery/feature-prioritization) tools help frame the question before we talk. When you're ready, [submit a project brief](/brief).