[{"data":1,"prerenderedAt":141},["ShallowReactive",2],{"blog-\u002Fblog\u002Fwhat-an-mvp-should-include-in-the-first-6-weeks":3},{"id":4,"title":5,"author":6,"body":7,"date":119,"description":120,"extension":121,"faqs":122,"meta":132,"navigation":133,"path":134,"seo":135,"stem":136,"tags":137,"__hash__":140},"blog\u002Fblog\u002Fwhat-an-mvp-should-include-in-the-first-6-weeks.md","What an MVP Should (and Shouldn't) Include in the First 6 Weeks","Attiate",{"type":8,"value":9,"toc":110},"minimark",[10,14,19,22,26,61,65,96,100,103,107],[11,12,13],"p",{},"The most common way an MVP timeline slips isn't bad engineering — it's scope creep disguised\nas reasonable feature requests. Almost every founder we talk to wants to add \"just one more\nthing\" before launch, and almost every one of those things could safely wait. Here's a\nframework for telling the difference.",[15,16,18],"h2",{"id":17},"start-from-the-one-loop-that-proves-the-idea","Start from the one loop that proves the idea",[11,20,21],{},"Every product has one core loop — the sequence of actions that proves whether the idea\nactually works for a real user. For a marketplace, it might be \"list an item → someone finds\nit → a transaction happens.\" For an AI tool, it might be \"upload a document → ask a question\n→ get a grounded answer.\" Everything the MVP includes should exist to make that one loop work\nend to end, reliably, for a real user. Everything else is a candidate to cut.",[15,23,25],{"id":24},"what-almost-always-belongs-in-the-first-version","What almost always belongs in the first version",[27,28,29,37,43,49,55],"ul",{},[30,31,32,36],"li",{},[33,34,35],"strong",{},"The core loop itself",", built properly — not mocked, not hardcoded, actually working.",[30,38,39,42],{},[33,40,41],{},"Enough error handling that the product doesn't silently fail"," on the first bad input a\nreal user gives it. This isn't scope creep; it's the difference between a demo and a\nproduct.",[30,44,45,48],{},[33,46,47],{},"Basic authentication",", in its simplest workable form.",[30,50,51,54],{},[33,52,53],{},"Automated tests for the core loop."," Skipping this to save a few days almost always costs\nmore time during the second version, when the codebase needs to change under real load\nwithout breaking.",[30,56,57,60],{},[33,58,59],{},"Enough analytics to see whether the core loop is actually being used",", and where people\ndrop off.",[15,62,64],{"id":63},"what-almost-always-belongs-in-a-later-version","What almost always belongs in a later version",[27,66,67,73,79,85,91],{},[30,68,69,72],{},[33,70,71],{},"Granular permissions and role hierarchies"," — unless the product is explicitly a\npermissions tool, most early users don't need this yet.",[30,74,75,78],{},[33,76,77],{},"A settings page with a dozen configuration options."," Defaults are fine until a real user\nasks for the option.",[30,80,81,84],{},[33,82,83],{},"Multiple payment providers, or complex billing tiers",", before there's a single paying\ncustomer to validate pricing against.",[30,86,87,90],{},[33,88,89],{},"A polished admin dashboard"," beyond what's needed to operate the product day to day.",[30,92,93],{},[33,94,95],{},"Support for edge cases with no evidence anyone will hit them yet.",[15,97,99],{"id":98},"the-test-we-use-to-scope-a-feature-request","The test we use to scope a feature request",[11,101,102],{},"When a feature comes up mid-build, we ask: if we launched without this today, what would\nactually happen? If the honest answer is \"a slightly worse experience for some users,\" it's a\nfast-follow, not a blocker. If the answer is \"the product doesn't do the thing it claims to\ndo,\" it's core, and it stays in scope.",[15,104,106],{"id":105},"why-this-matters-more-than-it-seems","Why this matters more than it seems",[11,108,109],{},"A bloated MVP doesn't just take longer to build — it takes longer to learn from. The entire\npoint of an MVP is to get real usage signal as fast as possible, so you know what to build\nnext with evidence instead of guesswork. Every feature added \"just in case\" delays that\nsignal without adding to it.",{"title":111,"searchDepth":112,"depth":112,"links":113},"",2,[114,115,116,117,118],{"id":17,"depth":112,"text":18},{"id":24,"depth":112,"text":25},{"id":63,"depth":112,"text":64},{"id":98,"depth":112,"text":99},{"id":105,"depth":112,"text":106},"2026-06-15","A scoping framework for deciding what actually belongs in a minimum viable product — and the features founders almost always want to add too early.","md",[123,126,129],{"question":124,"answer":125},"Should an MVP include user authentication?","Usually yes, in a minimal form — but \"minimal\" matters. Email\u002Fpassword or a single social login is enough; multi-provider SSO, role hierarchies, and granular permissions are almost always premature for a first version unless the product's entire value proposition depends on them from day one.",{"question":127,"answer":128},"Is it okay to launch an MVP without automated tests?","No — this is one of the few things not worth cutting. Skipping tests to move faster in an MVP usually costs more time later, once the codebase needs to survive its first real users and second version. Scope features down, not engineering discipline.",{"question":130,"answer":131},"How do you decide what's \"core\" versus \"nice to have\"?","Ask what breaks the product's core promise if it's missing. If the answer is \"nothing, users just have a slightly worse experience,\" it's not core — defer it. If the answer is \"the product doesn't actually solve the problem without it,\" it belongs in the first version.",{},true,"\u002Fblog\u002Fwhat-an-mvp-should-include-in-the-first-6-weeks",{"title":5,"description":120},"blog\u002Fwhat-an-mvp-should-include-in-the-first-6-weeks",[138,139],"MVP Development","Product Strategy","3o0VTGmqkd6fS--PvqIHK5LWP_ysWCc93HiUgz4f2T8",1784471550522]