<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Blog on 90 Day MVP</title><link>https://90daymvp.com/blog/</link><description>Recent content in Blog on 90 Day MVP</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 14 Oct 2026 00:00:00 -0400</lastBuildDate><atom:link href="https://90daymvp.com/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>Prototype or Foundation: Will Your MVP Get Thrown Away?</title><link>https://90daymvp.com/blog/prototype-or-foundation-will-your-mvp-get-thrown-away/</link><pubDate>Wed, 14 Oct 2026 00:00:00 -0400</pubDate><guid>https://90daymvp.com/blog/prototype-or-foundation-will-your-mvp-get-thrown-away/</guid><description>&lt;p&gt;There is a question nearly every founder asks us quietly, usually right before signing. After the demos, the plans and the excitement die down, they pause and ask: &amp;ldquo;Are we going to have to throw all of this away?&amp;rdquo;&lt;/p&gt;
&lt;p&gt;They ask because they have heard the folklore. Build an MVP fast, learn from it, then rebuild it properly. Like most folklore, it wraps a piece of truth inside a costly misunderstanding. Some MVPs are experiments that should end once they have answered their question. Others are first versions of the real product and should never stop growing. The expensive failure is not building either one. It is paying for a foundation when you needed a prototype, or worse, building a prototype when the business you are funding depends on a foundation.&lt;/p&gt;</description></item><item><title>Web, Mobile, or Device: Where Your MVP Should Live</title><link>https://90daymvp.com/blog/web-mobile-or-device-where-your-mvp-should-live/</link><pubDate>Wed, 14 Oct 2026 00:00:00 -0400</pubDate><guid>https://90daymvp.com/blog/web-mobile-or-device-where-your-mvp-should-live/</guid><description>&lt;p&gt;Almost every product conversation we have starts the same way. A founder describes the problem they want to solve, and within two minutes someone says the word &amp;ldquo;app.&amp;rdquo; Usually an iPhone appears, and someone sketches boxes on a napkin.&lt;/p&gt;
&lt;p&gt;Here is the interesting part: the platform is often the least examined decision in the whole project. &amp;ldquo;We need an app&amp;rdquo; is a delivery mechanism, not a strategy. Whether your MVP lives on the web, on a phone or inside a piece of hardware changes your budget, your timeline and how quickly you can learn from real users.&lt;/p&gt;</description></item><item><title>How to Validate Your Software Idea Before You Build It</title><link>https://90daymvp.com/blog/validate-your-software-idea-before-you-build/</link><pubDate>Wed, 07 Oct 2026 00:00:00 -0400</pubDate><guid>https://90daymvp.com/blog/validate-your-software-idea-before-you-build/</guid><description>&lt;p&gt;Every founder we meet has a product idea they believe in. Most of them are right that a problem exists. Where they get into trouble is assuming their specific solution is the one people will pay for, use and recommend.&lt;/p&gt;
&lt;p&gt;That gap between &amp;ldquo;a real problem&amp;rdquo; and &amp;ldquo;the right solution&amp;rdquo; is where most software budgets disappear. You can spend six figures building something nobody wants, or you can spend a weekend figuring out whether the idea has legs before a single line of code gets written.&lt;/p&gt;</description></item><item><title>Railway vs. Vercel: Choosing a Home for Your MVP</title><link>https://90daymvp.com/blog/railway-vs-vercel/</link><pubDate>Tue, 06 Oct 2026 00:00:00 -0400</pubDate><guid>https://90daymvp.com/blog/railway-vs-vercel/</guid><description>&lt;p&gt;Twenty years ago, launching a web application meant renting servers, configuring them by hand and hoping nothing caught fire on launch day. Today, platforms like &lt;strong&gt;Railway&lt;/strong&gt; and &lt;strong&gt;Vercel&lt;/strong&gt; take a code repository and turn it into a live, scalable product in minutes.&lt;/p&gt;
&lt;p&gt;For an MVP that has to launch on a fixed date, that matters. Every day not spent on infrastructure is a day spent on the product. Both platforms are excellent, but they&amp;rsquo;re built around different ideas, and picking the right one early saves headaches later.&lt;/p&gt;</description></item><item><title>Why 90 Days Is the Sweet Spot for an MVP</title><link>https://90daymvp.com/blog/why-90-days/</link><pubDate>Tue, 29 Sep 2026 00:00:00 -0400</pubDate><guid>https://90daymvp.com/blog/why-90-days/</guid><description>&lt;p&gt;When people hear &amp;ldquo;90 Day MVP,&amp;rdquo; the first question is usually whether 90 days is enough. The second, from people who have been through a software project before, is whether 90 days is &lt;em&gt;too long&lt;/em&gt;.&lt;/p&gt;
&lt;p&gt;Both are fair questions. Here&amp;rsquo;s why we landed on 90.&lt;/p&gt;
&lt;h2 id="shorter-timelines-tend-to-produce-demos"&gt;Shorter timelines tend to produce demos&lt;/h2&gt;
&lt;p&gt;You can build something impressive in two weeks. Hackathons prove it every weekend. But what you usually get is a demo: a happy path that works when the right person clicks the right buttons.&lt;/p&gt;</description></item><item><title>What Belongs in an MVP (and What Doesn't)</title><link>https://90daymvp.com/blog/what-belongs-in-an-mvp/</link><pubDate>Tue, 22 Sep 2026 00:00:00 -0400</pubDate><guid>https://90daymvp.com/blog/what-belongs-in-an-mvp/</guid><description>&lt;p&gt;Every founder we talk to has the same problem, and it isn&amp;rsquo;t a technical one. They have a vision for a product that does fifteen things well. They need to launch something that does &lt;em&gt;one&lt;/em&gt; thing well, and they have to choose which one.&lt;/p&gt;
&lt;p&gt;That choice is the whole game. Get it right and you have a focused product in front of real users in weeks. Get it wrong and you spend six months building features nobody asked for, while the thing that mattered sits half-finished.&lt;/p&gt;</description></item></channel></rss>