What Do You Actually Get After a One-Week MVP?

In just one week, your idea can become a working product you can put in front of real users—with the source code, accounts, and a clear walkthrough to make it yours. At OneWeekMVP, we build that first version with you, so you can start learning from customers and take your next step with confidence.

At OneWeekMVP, the agreed scope covers a live working product, its code and accounts, and a walkthrough at handover. The fixed public offer is $999 for a scope agreed before the week starts.[1]

Here is what that means in practice—and what you should clarify before any MVP build begins.

1. A working user journey, not a pile of screens

The most important deliverable is one complete flow. A user should be able to arrive, do the thing your idea promises, and reach a useful result.

That might be booking a service, uploading a document, receiving an analysis, managing a membership, or completing a payment. The exact flow changes by product. The principle does not: the MVP must make one meaningful outcome possible from start to finish.

This is why scope matters more than screen count. Five connected screens can form a usable product. Twenty disconnected screens can still be a prototype.

Our public offer defines an MVP as the smallest version that real users can use to do the one thing the idea promises. It explicitly excludes a clickable mockup as the finished result.[1]

2. A live product your users can open

A repository is not a launch. By the end of the week, the agreed product should be deployed and reachable in the environment chosen during scoping.

That creates the first honest test. Can a user find the product, understand what to do, complete the core flow, and tell you where it breaks down?

The form of deployment depends on the product. A web app may have a public URL. A mobile product may use an agreed testing or distribution route. What matters is that “done” has been defined before work starts—and that it includes access by the people who will test it.

This is visible in our published work. The first policeler.in release went live under three days after the first commit, with online payments added later in the same week.[2] TonUtils launched publicly on day six after scope, development, design review and security checks.[3]

3. The source code and the accounts behind it

Ownership only becomes useful when you can actually take control.

Your handover should identify:

• where the source code lives;
• which account hosts the product;
• which services store data;
• which third-party tools the product depends on;
• how domains, email, analytics or payments are connected, where applicable;
• who currently has access.

Our offer includes the code and accounts in the handover.[1] We prefer client-owned accounts where practical, because a clean exit should not require rebuilding access from memory.

Credentials should never be pasted into a handover document. They belong in a password manager or another secure transfer process. The handover should explain what exists and where it is controlled, without turning the document into a security risk.

4. A walkthrough of what was built

Code is only one part of understanding the product. The handover walkthrough should show:

• the core user journey;
• the operating or admin flow, if one exists;
• how to make a basic content or configuration change;
• how releases are made;
• what was deliberately left out;
• where known limitations sit;
• what should be watched during the first user tests.

This is the moment to remove ambiguity. A good walkthrough is not a victory lap. It is a practical transfer of context so that you can test, operate and discuss the product with confidence.

5. A clear list of what did not make the week

A focused MVP always leaves things out. That is not an incomplete delivery; it is the result of making a deliberate scope decision.

The useful output is a short backlog with reasons. Each deferred item should answer at least one question:

• What user evidence would justify building it?
• Is it essential for safety, compliance or reliable operation before a wider launch?
• Does it remove a repeated manual step?
• Is it a growth feature that only matters after the core flow works?

Our published offer says we write down what was left out and why.[1] That keeps “later” from becoming a vague promise and gives the next decision a starting point.

6. A decision for day 8

The first week does not prove that a business will work. It gives you something concrete enough to learn from.

On day 8, you should be able to choose among three honest paths:

1. Stop. The test weakened the idea, and you avoided a larger build. 2. Continue with your own team. You have the code, accounts and context needed to move forward. 3. Keep building with us. If the test is promising, we can agree a monthly retainer separately.

Nothing in the public OneWeekMVP offer renews automatically; post-MVP continuation is optional.[1]

A handover checklist to use before you start

Do not wait until the final day to ask what you will receive. Put the handover into the scope conversation.

Use this checklist:

• [ ] The single core user journey is named.
• [ ] “Live and usable” is defined for this product.
• [ ] The deployment environment and owner are named.
• [ ] Source-code access is included.
• [ ] Product and service accounts are listed.
• [ ] Data export or access is explained where relevant.
• [ ] A walkthrough is scheduled.
• [ ] Deferred features and known limitations will be documented.
• [ ] Ongoing costs are identified.
• [ ] Post-launch support is either defined or explicitly excluded.

The best MVP handover is boring in the right way: no hostage accounts, no mystery deployment and no surprise dependency on the builder. Just a small working product, enough context to operate it, and a clear next decision.

Let’s turn your idea into a working product

Bring us the idea. We’ll help you define the first version, agree on what we’ll deliver, and build it in one week for $999. You’ll leave with a live product, its code and accounts, and a walkthrough to get you moving.

Book your MVP scoping call (opens in a new tab) — tell us what you want to build, and let’s map out your first week.

Sources

[1] https://oneweekmvp.io — OneWeekMVP | Your idea, built and working in seven days. [2] https://oneweekmvp.io/work/policeler-in — policeler.in case study | OneWeekMVP [3] https://oneweekmvp.io/work/tonutils — TonUtils case study | OneWeekMVP