The One-Week Prototype Pact: A Tiny Ritual to Finally Ship Your Experiments
How a simple one-week timebox, opinionated tools, and ruthless scope-cutting can turn endless side projects into real, shippable experiments that actually reach users.
The One-Week Prototype Pact: A Tiny Ritual to Finally Ship Your Experiments
Side projects have a bad habit of turning into ghost ships.
They start with a rush of excitement, a fresh repo, a shiny idea. A month later, you’re buried in refactors, architecture decisions, and “just one more feature” — with nothing you’d dare show to another human.
What if you flipped the script?
Instead of “I’ll work on this side project until it’s ready,” you make a tiny, brutally clear promise:
In one week, I will ship a real, usable prototype to real users.
That’s the One-Week Prototype Pact: a small ritual that forces your ideas out of your head, through code, and into the world.
This post walks through why it works, how to do it, and how to turn it into a repeatable practice for exploring many ideas quickly — without burning out or getting stuck.
What Is the One-Week Prototype Pact?
The pact is simple:
- Timebox: You get one calendar week. Not “around a week.” Exactly one.
- Output: At the end, you ship a real, usable prototype (not a concept, not a wireframe, not a local-only build).
- Goal: Learning and validation, not polish or perfection.
- Decision: When the week ends, you must decide: iterate, pivot, or kill.
This is not a productivity hack. It’s a constraint that reshapes how you think:
- You stop fantasizing about v3 and focus on v0.1.
- You stop overengineering and let ugly but working be good enough.
- You stop hoarding ideas and start turning them into testable experiments.
Treat It Like a Rough Draft, Not a Product Launch
Most side projects stall because we secretly treat them like final products:
- “The onboarding needs to be smoother.”
- “I should set up proper microservices.”
- “Let me just design a better logo.”
For a one-week pact, your prototype is a rough draft — or, in engineering terms, a spike:
- Its purpose is to reduce uncertainty: Will anyone use this? Is the core interaction viable?
- It is explicitly disposable: you are allowed to throw it away after the week.
- It ignores long-term concerns in favor of short-term learning.
A helpful mindset shift:
“This code is a question, not a commitment.”
Write code as if you might never see it again. Because you might not.
Use Opinionated, High-Leverage Tools
The tools you choose can make or break a one-week pact.
You do not have time to:
- Hand-roll authentication
- Debate between five deployment platforms
- Design a custom design system from scratch
You want tools that give you batteries included and strong opinions so you don’t waste cognitive energy on infrastructure.
Examples:
- Web app? Use something like Next.js + AWS Amplify, Vercel, or Supabase.
- Auth, hosting, APIs, and data in hours, not days.
- Mobile app? Use Expo or another framework that ships quickly to test devices.
- Internal tools or admin interfaces? Use Retool, Budibase, or similar.
The heuristic:
If a tool saves you from making 10 decisions this week, it’s a win.
Favor tools that:
- Have clear defaults
- Get you from idea → live URL in a day
- Are easy to throw away if you pivot
Your goal isn’t to build the perfect stack. It’s to shrink the distance between idea and user.
Define One Clear Outcome — Then Cut Ruthlessly
A week disappears faster than you think. Without a clear target, you’ll drift.
Before the week starts, define one outcome. For example:
- “A clickable demo where a user can upload a file and see a transformed result.”
- “A working MVP where 5 beta users can sign up and complete one core workflow.”
- “A simple landing page + waitlist form that lets us test if anyone even cares.”
Then ask:
What is the smallest thing we can build that proves or disproves the core assumption?
And cut scope aggressively:
- Remove settings pages, dashboards, and analytics.
- Hard-code values where you can.
- Support only one browser, one platform, one happy path.
If something doesn’t directly support your one outcome, it’s a distraction.
In a one-week pact, “nice to have” features are actually “never to have (this week)” features.
Write the outcome somewhere visible and check tasks against it. If a task doesn’t move that outcome forward, it doesn’t belong.
Work in Tiny, Daily Feedback Loops
Even within a week, you can waste days going in the wrong direction.
To avoid this, design daily feedback loops:
- Day 1–2: Core skeleton and the main user flow.
- Day 3–4: Make it stable and end-to-end usable, even if ugly.
- Day 5: Internal demos and small user tests.
- Day 6: Fix the sharpest edges, onboard test users.
- Day 7: Ship publicly (or to your target group), gather feedback, and debrief.
Each day, aim to:
- Build something demo-able, however small.
- Show it — to a friend, colleague, potential user, or even to your future self via a loom/video.
- Adjust tomorrow’s plan based on what you learn.
This keeps you honest. If it’s hard to demo, it’s probably too abstract or overcomplicated. Tiny loops fight both perfectionism and procrastination.
Ship to Real Users, Then Decide: Iterate, Pivot, or Kill
The pact doesn’t end when you push the last commit. It ends when you’ve put the prototype in front of real users and made a decision.
Your options:
- Iterate – The response is promising enough to justify another week.
- Pivot – Something in the idea resonates, but your assumptions were off.
- Kill – Users don’t care, or you don’t care enough to continue.
The magic is in making this explicit.
A one-week prototype is successful if it gives you a clear answer, even if that answer is “this isn’t worth more of my life.”
Killing an idea after one week is a win. You just saved months.
To do this well:
- Talk to a few users (even 3–5 is helpful).
- Watch them use the prototype, or walk them through it.
- Ask: “What did you expect this to do?” and “Would you use this next week?”
- Look for behavior, not compliments.
Then decide: What’s the next smallest bet? Another week? A new direction? Or a new idea entirely?
Turn It into a Repeatable Practice
The real power of the One-Week Prototype Pact comes when you treat it as a ritual, not a one-off stunt.
Imagine a year where you:
- Run a one-week pact every month (or every quarter).
- Ship 6–12 prototypes.
- Kill most of them.
- Double down on the 1–2 that show real traction.
This rhythm helps you:
- Explore many more ideas than an endlessly dragged-out side project.
- Build a portfolio of shipped experiments, not half-finished repos.
- Learn faster about your market, your skills, and your interests.
You can even create a lightweight structure:
- Day 0 (Planning): Choose idea, define outcome, choose tools.
- Days 1–6: Build with daily micro-demos.
- Day 7: Ship, collect feedback, retrospective, decision.
- Between pacts: Rest, reflect, and queue up the next idea.
Over time, you’ll refine your personal toolkit, patterns, and instincts. You’ll know which tools let you move fastest, which patterns you reuse, and which types of ideas are worth another week.
How to Start Your First One-Week Pact
You don’t need a perfect plan. You just need a starting point:
- Pick one idea you’ve been postponing.
- Block one week on your calendar (even if it’s evenings and a weekend).
- Write your outcome in one sentence. Make it embarrassingly small.
- Choose an opinionated stack you won’t second-guess.
- Tell someone about your pact and your ship date (accountability helps).
- Start building rough and early, and demo something by the end of Day 1.
At the end of the week, ask:
- What did I learn?
- What surprised me about users?
- Do I want to give this idea another week?
Then commit to your decision. That’s the pact.
Conclusion: Trade Fantasy for Feedback
Endless side projects are a kind of fantasy: you get the thrill of imagining success without the discomfort of shipping something imperfect to the world.
The One-Week Prototype Pact is an antidote.
By constraining yourself to:
- One week
- One clear outcome
- One real prototype in front of real users
…you trade fantasy for feedback, and daydreams for data.
You’ll write more bad code, ship more ugly v0.1s, and kill more ideas.
You’ll also, almost inevitably, stumble onto something worth keeping — and when you do, you’ll already have the muscle memory for moving fast, learning quickly, and shipping on purpose.
Make the pact with yourself: one week, one prototype, one decision. Then repeat until something sticks.