--- title: "How We Scope a One-Week MVP | OneWeekMVP" description: "See how we scope a one-week MVP, with real release timelines from policeler.in, Fit'n Co and TonUtils—and a practical brief for your own first version." canonical_url: "https://oneweekmvp.io/blog/how-we-scope-a-one-week-mvp" last_updated: "2026-10-27T11:36:40.116Z" meta: "og:description": "See how we scope a one-week MVP, with real release timelines from policeler.in, Fit'n Co and TonUtils—and a practical brief for your own first version." "og:image": "https://oneweekmvp.io/_og/d/a_A%2Bfocused%2Bpath%2Bfrom%2Bpossible%2Bfeatures%2Bto%2Ba%2Bworking%2Bfirst%2Brelease.%2Cc_OneWeekMVP%2Ctitle_~SG93IFdlIFNjb3BlIGEgT25lLVdlZWsgTVZQOiBMZXNzb25zIGZyb20gT3VyIFByb2plY3Rz%2Ckicker_Blog%2Cimage_~L21lZGlhL2hvdy13ZS1zY29wZS1hLW9uZS13ZWVrLW12cC1jb3Zlci1lZjMyMzU3YzUzLndlYnA%2Cp_Ii9ibG9nL2hvdy13ZS1zY29wZS1hLW9uZS13ZWVrLW12cCI%2Cs_0cGjxWXT612Ttx4X.png" "og:image:alt": "A focused path from possible features to a working first release." "og:image:height": "630" "og:image:type": image/png "og:image:width": "1200" "og:title": "How We Scope a One-Week MVP | OneWeekMVP" "twitter:image": "https://oneweekmvp.io/_og/d/a_A%2Bfocused%2Bpath%2Bfrom%2Bpossible%2Bfeatures%2Bto%2Ba%2Bworking%2Bfirst%2Brelease.%2Cc_OneWeekMVP%2Ctitle_~SG93IFdlIFNjb3BlIGEgT25lLVdlZWsgTVZQOiBMZXNzb25zIGZyb20gT3VyIFByb2plY3Rz%2Ckicker_Blog%2Cimage_~L21lZGlhL2hvdy13ZS1zY29wZS1hLW9uZS13ZWVrLW12cC1jb3Zlci1lZjMyMzU3YzUzLndlYnA%2Cp_Ii9ibG9nL2hvdy13ZS1zY29wZS1hLW9uZS13ZWVrLW12cCI%2Cs_0cGjxWXT612Ttx4X.png" "twitter:image:alt": "A focused path from possible features to a working first release." --- > Index of every page on this site: [llms.txt](https://oneweekmvp.io/llms.txt) 27 Oct 2026 · Umurcan Gorur # How We Scope a One-Week MVP: Lessons from Our Projects What ships first, what follows, and why a one-week build is not a race to collect features. ![A focused path from possible features to a working first release.](https://oneweekmvp.io/media/how-we-scope-a-one-week-mvp-cover-ef32357c53.webp) A week is a useful constraint. It forces a decision: what needs to work when the first user arrives, and what can follow once there is a real product to build on? Our answer is not a fixed number of screens or features. We start with the flow the product needs to deliver, the people on each side of it, and the checks that make it usable. Then we separate the first release from the next stage. Our projects show different versions of that boundary. For policeler.in, the first release came before online payments. For Fit'n Co, the member app and staff panel came before later design and purchase updates. TonUtils shows why feature count alone is a poor way to measure scope. ## policeler.in: a first release, then online payments [policeler.in (opens in a new tab)](https://oneweekmvp.io/work/policeler-in) needed a working web product for insurance agencies and their customers in Turkey—not a mockup to discuss indefinitely. Our published timeline records the first commit on 18 September 2026 and the first release on 21 September, under three days later. Online payments followed on 23 September, within five days of the first commit. The case study shows an agency panel with a searchable policy list and PDF upload, and a customer page where policy PDFs are accessible. It also records a checked release process from the first release. The payment milestone is documented separately, after that release. That sequence matters. A first release and a payment milestone did not have to be the same event. We could put a working product in front of agencies and add online payments within the same week. **The scoping lesson:** distinguish what must work at the first release from what can follow as a separate milestone. Payments may be essential on day one for your product; in this project's documented timeline, they followed the first release. The business flow decides—not a universal MVP checklist. ## Fit'n Co: build both sides of the service, then keep growing [Fit'n Co (opens in a new tab)](https://oneweekmvp.io/work/fitnco) began with a concrete operational need. Its dietitians coached members over WhatsApp and needed a member app and a staff panel on a platform of their own. The one-week core build ran from 15 to 22 July 2026: a member app for iOS and Android, a staff web panel, and the backend behind both. Staging and production pipelines were in place from the first days. The published timeline then separates later work: - **29–31 July:** the app and panel were restyled to the client's own design. - **10–14 August:** Apple in-app purchases for coaching and content packages. - **23 September:** real SMS sign-in and push notifications for the app and staff panel. The client continued with a monthly retainer, building on that backend through October 2026. **The scoping lesson:** a useful first version may need more than a customer-facing screen. When staff are part of delivering the service, their side belongs in the core scope too. But the first week does not have to contain every later design treatment, payment mechanism, or communication channel. These dates describe what shipped and when. They do not imply that every later feature was already planned or deliberately rejected during the initial week. ## TonUtils: count dependencies, not just features [TonUtils (opens in a new tab)](https://oneweekmvp.io/work/tonutils) is a free toolbox for everyday TON users and developers. Scope and preparation started on 21 October 2026. Development began on the evening of 22 October; by the next morning the site had more than 100 tools. After design review and security checks, it went live on 26 October, day six. The published delivery includes tools for addresses, wallets, tokens, NFTs, domains, smart contracts, and transactions, plus hand-checked links and an ecosystem directory. There were also explicit boundaries: seed phrases and keys stay in the user's browser and never reach a server; wallet actions display the exact transaction before the user signs it. **The scoping lesson:** “one flow” does not mean “one button,” and “small” cannot be measured by counting features alone. The number of tools tells only part of the story. What the product touches, where sensitive information goes, and what must be reviewed before launch matter too. TonUtils is an example of what we delivered for that brief—not a promise that any list of 100 features fits into a week. ## What belongs in the week—and what should wait? We use the first conversation to draw a release boundary. The question is not whether an idea is good. It is whether it is needed for this version to do its job. ## Put it in the first-week scope when… - **It completes the main task.** A user must reach a useful outcome, not just see a convincing screen. - **It makes the operation possible.** If a member needs staff support to receive the service, staff need a workable way to provide it. - **It protects the flow.** Necessary access controls, sensitive-data boundaries, and release checks are part of the build—not a reward for finding users later. - **Its dependencies are understood.** We need to know which accounts, data, integrations, and decisions the work relies on. ## Separate it into a later milestone when… - It serves a different audience or adds a second business flow. - It improves an existing journey without being necessary to complete it. - It introduces a new integration or external approval that cannot be responsibly promised within the agreed week. - It automates a step the team can initially handle clearly and reliably by hand. Those are scoping questions, not a claim that every payment integration should wait or every mobile app fits. Fit'n Co needed both an app and a staff panel; policeler.in's online payments followed its first release. The boundary changes with the brief. If there is no honest one-week version of the idea, we say so before you pay. A smaller first release should still be worth putting in front of people. ## Bring us a brief, not a hundred-item wish list You do not need a complete specification before talking to us. Start with these six answers: - **Who is the first user?** Name the person and the situation they are in. - **What must they finish?** Describe the result, not a collection of screens. - **Who handles the other side?** Identify staff, administrators, or partners needed to complete the service. - **What must be ready?** List accounts, source data, content, integrations, and permissions. - **What can wait?** Keep a separate list so later ideas do not quietly become launch blockers. - **How will we check it?** Write the behavior you expect: a request is saved, the right person can access it, and a failed action is not reported as successful. Then choose what you want to learn from the release. Can people complete the task? Does the team get what it needs to deliver the service? Where do users ask for help? A launch gives you something real to observe; it does not answer those questions on its own. ## A week with us starts before the code In [“Why not just build your MVP with AI tools?” (opens in a new tab)](https://oneweekmvp.io/blog/why-not-just-prompt-it), we explain why access to a coding tool is different from deciding what to build. This is the practical next step: define the release boundary, build the flow, and leave a clear path to the next version. Our [published projects (opens in a new tab)](https://oneweekmvp.io/work) show what that has looked like across different products. Your scope should come from your users and constraints, not a copied feature list. **Tell us who your product is for and what they need to accomplish.** [Bring your idea to OneWeekMVP (opens in a new tab)](https://oneweekmvp.io/). We will work through what belongs in the first week—and what does not. ## Frequently asked questions ## Can a one-week MVP include a mobile app? It can. Fit'n Co's documented one-week build included an iOS and Android member app, a staff panel, and a shared backend. That is a project example, not a blanket commitment for every app brief. ## Should online payments be in the first release? Only the product's core flow can answer that. policeler.in's first release preceded online payments, which followed within five days of the first commit. If completing a purchase is the task your first user needs to perform, that changes the release boundary. ## What happens after the first week? The next step depends on what the product needs. Fit'n Co continued on a monthly retainer, with later design, in-app purchase, and notification milestones documented in its case study. A first-week scope is a starting boundary, not the entire product roadmap. ## Does an MVP need to have very few features? Not necessarily. TonUtils launched on day six with more than 100 tools. Complexity, dependencies, and review requirements are more useful scoping questions than a feature count on its own. ```json {"@context":"https://schema.org","@graph":[{"@id":"https://oneweekmvp.io/#website","@type":"WebSite","description":"A working MVP of your idea in 7 days for a fixed $999, built by a team that has worked in many startups.","name":"OneWeekMVP","url":"https://oneweekmvp.io/","publisher":{"@id":"https://oneweekmvp.io/#identity"}},{"@id":"https://oneweekmvp.io/blog/how-we-scope-a-one-week-mvp#webpage","@type":"WebPage","dateModified":"2026-10-27T11:36:40.116Z","datePublished":"2026-10-27","description":"See how we scope a one-week MVP, with real release timelines from policeler.in, Fit'n Co and TonUtils—and a practical brief for your own first version.","name":"How We Scope a One-Week MVP | OneWeekMVP","url":"https://oneweekmvp.io/blog/how-we-scope-a-one-week-mvp","breadcrumb":{"@id":"https://oneweekmvp.io/blog/how-we-scope-a-one-week-mvp#breadcrumb"},"isPartOf":{"@id":"https://oneweekmvp.io/#website"},"potentialAction":[{"@type":"ReadAction","target":["https://oneweekmvp.io/blog/how-we-scope-a-one-week-mvp"]}],"primaryImageOfPage":{"@type":"ImageObject","url":"https://oneweekmvp.io/media/how-we-scope-a-one-week-mvp-cover-ef32357c53.webp","inLanguage":"en","contentUrl":"https://oneweekmvp.io/media/how-we-scope-a-one-week-mvp-cover-ef32357c53.webp"}},{"@id":"https://oneweekmvp.io/#identity","@type":"Organization","description":"A working MVP of your idea in 7 days for a fixed $999, built by a team that has worked in many startups.","email":"hello@oneweekmvp.io","legalName":"Sigmus Limited","name":"OneWeekMVP","url":"https://oneweekmvp.io/","address":{"@type":"PostalAddress","streetAddress":"Suite 13a Ideas House, Station Estate, Eastwood Close","addressLocality":"London","postalCode":"E18 1BY","addressCountry":"GB"},"logo":{"@id":"https://oneweekmvp.io/#logo"}},{"@id":"https://oneweekmvp.io/blog/how-we-scope-a-one-week-mvp#article","dateModified":"2026-10-27T11:36:40.116Z","datePublished":"2026-10-27","description":"What ships first, what follows, and why a one-week build is not a race to collect features.","headline":"How We Scope a One-Week MVP: Lessons from Our Projects","inLanguage":"en","thumbnailUrl":"https://oneweekmvp.io/media/how-we-scope-a-one-week-mvp-cover-ef32357c53.webp","@type":["Article","BlogPosting"],"author":{"@id":"https://oneweekmvp.io/#/schema/person/1"},"image":{"@id":"https://oneweekmvp.io/#/schema/image/1"},"isPartOf":{"@id":"https://oneweekmvp.io/blog/how-we-scope-a-one-week-mvp#webpage"},"mainEntityOfPage":{"@id":"https://oneweekmvp.io/blog/how-we-scope-a-one-week-mvp#webpage"},"publisher":{"@id":"https://oneweekmvp.io/#identity"}},{"@id":"https://oneweekmvp.io/blog/how-we-scope-a-one-week-mvp#breadcrumb","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","name":"Home","item":"https://oneweekmvp.io/","position":1},{"@type":"ListItem","name":"Blog","item":"https://oneweekmvp.io/blog","position":2},{"@type":"ListItem","name":"How We Scope a One-Week MVP: Lessons from Our Projects","position":3}]},{"@id":"https://oneweekmvp.io/#/schema/person/1","@type":"Person","name":"Umurcan Gorur"},{"@id":"https://oneweekmvp.io/#logo","@type":"ImageObject","caption":"OneWeekMVP","contentUrl":"https://oneweekmvp.io/logo.png","inLanguage":"en","url":"https://oneweekmvp.io/logo.png"},{"@id":"https://oneweekmvp.io/#/schema/image/1","@type":"ImageObject","contentUrl":"https://oneweekmvp.io/media/how-we-scope-a-one-week-mvp-cover-ef32357c53.webp","inLanguage":"en","url":"https://oneweekmvp.io/media/how-we-scope-a-one-week-mvp-cover-ef32357c53.webp"}]} ``` ## Sitemap See the full [sitemap](https://oneweekmvp.io/sitemap.md) for all pages.