{"id":7,"date":"2026-11-05T06:07:08","date_gmt":"2026-11-05T06:07:08","guid":{"rendered":"https:\/\/blog.jibonstudio.com\/?p=7"},"modified":"2026-11-05T06:07:08","modified_gmt":"2026-11-05T06:07:08","slug":"what-a-14-day-mvp-actually-looks-like","status":"publish","type":"post","link":"https:\/\/blog.jibonstudio.com\/?p=7","title":{"rendered":"What a 14-Day MVP Actually Looks Like"},"content":{"rendered":"<p>&#8220;Two weeks&#8221; sounds like a sales pitch until you see the schedule behind it. Here&#8217;s what actually happens inside those fourteen days, stage by stage \u2014 the same four stages every project here runs through: Define, Design, Build, Launch &amp; Improve.<\/p>\n<h2>Days 1\u20132: Define<\/h2>\n<p>This is the stage most teams skip, and it&#8217;s the one that decides whether the other thirteen days are well spent. Before a single screen gets designed, we write down three things in plain language:<\/p>\n<ul>\n<li>The one user action that proves the idea works.<\/li>\n<li>Everything the product does <em>not<\/em> need to do yet, written down explicitly so it stops coming up in week two.<\/li>\n<li>What &#8220;done&#8221; looks like \u2014 not visually, but functionally: what a user can do end-to-end by day 14.<\/li>\n<\/ul>\n<p>Most MVPs balloon in scope because nobody wrote this down. A scope doc that fits on one page is worth more than a 40-slide deck here.<\/p>\n<h2>Days 3\u20136: Design<\/h2>\n<p>Design moves fast because it isn&#8217;t starting from zero \u2014 it&#8217;s working from a system: type scale, spacing, components, and states already decided before the first screen is drawn. That means days 3\u20136 go toward the actual product flows, not toward relitigating what a button should look like.<\/p>\n<p>By day 6, every core screen exists at least as a clickable prototype. Not polished \u2014 clickable. The goal is to catch flow problems while they&#8217;re still cheap to fix, which is &#8220;before engineering builds them,&#8221; not after.<\/p>\n<blockquote><p>If a reviewer can&#8217;t click through the whole flow by day 6, the schedule is already slipping \u2014 better to know on day 6 than day 12.<\/p><\/blockquote>\n<h2>Days 7\u201312: Build<\/h2>\n<p>This is the longest stage and the most boring to describe, which is the point. Nothing here should be a surprise, because days 1\u20136 already removed the two things that blow up a build: unclear scope and undesigned edge cases. What&#8217;s left is writing the code.<\/p>\n<p>We build in the order a user would hit things, not the order that&#8217;s technically convenient \u2014 the signup flow before the settings page, the core action before the nice-to-have one. That way, if day 10 runs long, what&#8217;s cut is the least important thing, not a random half-finished feature.<\/p>\n<h2>Days 13\u201314: Launch &amp; Improve<\/h2>\n<p>Launch day is not a finish line \u2014 it&#8217;s the first time real data starts coming in. The last two days go toward making sure that data is actually usable: basic analytics wired up, a way to see where users drop off, and a short list of what we&#8217;re watching in week one.<\/p>\n<p>An MVP that ships without a way to measure what happened isn&#8217;t an MVP \u2014 it&#8217;s a guess with a URL.<\/p>\n<h2>Why fourteen days, specifically<\/h2>\n<p>Not because it&#8217;s a round number. It&#8217;s roughly the longest a scope can stay frozen before someone&#8217;s priorities change, a competitor ships something, or the &#8220;quick idea&#8221; quietly turns into six other ideas. Fourteen days is long enough to build something real and short enough that the thing you agreed to build on day 1 is still the thing that ships on day 14.<\/p>\n<p>If you&#8217;ve got an idea that keeps getting bigger every time you talk about it, that&#8217;s usually a sign it needs a Define stage before anything else.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>&#8220;Two weeks&#8221; sounds like a sales pitch until you see the schedule behind it. Here&#8217;s what actually happens inside those fourteen days, stage by stage \u2014\u2026<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[7,4,5,6],"class_list":["post-7","post","type-post","status-publish","format-standard","hentry","category-process","tag-in-two-weeks","tag-mvp","tag-process","tag-startups"],"_links":{"self":[{"href":"https:\/\/blog.jibonstudio.com\/index.php?rest_route=\/wp\/v2\/posts\/7","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.jibonstudio.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.jibonstudio.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.jibonstudio.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.jibonstudio.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=7"}],"version-history":[{"count":1,"href":"https:\/\/blog.jibonstudio.com\/index.php?rest_route=\/wp\/v2\/posts\/7\/revisions"}],"predecessor-version":[{"id":9,"href":"https:\/\/blog.jibonstudio.com\/index.php?rest_route=\/wp\/v2\/posts\/7\/revisions\/9"}],"wp:attachment":[{"href":"https:\/\/blog.jibonstudio.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=7"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.jibonstudio.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=7"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.jibonstudio.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=7"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}