We Built and Launched an MVP in One Working Day. Here Is What Actually Mattered.
Yesterday evening we started with an empty folder and a question: what would a todo list look like if you designed it for a world where software can do the maintenance for you? By the time we went to bed, the app was live at newdo.beaverminds.com, the code was public, and a Product Hunt launch was scheduled for today.
One working day. That number will get the attention, so let us be honest about it up front. The speed came from three decisions made in the first hour, not from typing fast. Most founder MVPs we see take months for reasons that trace back to skipping exactly these decisions.
Decision one: write the spec before the first file
The first thing that existed was a one-page document. What the product believes (the list is an output, never an input), what the core object is (an obligation, with who it is for, when it is due and how firm that is), what the one screen shows, and what version one deliberately does not do.
That page took thirty minutes and saved hours. Every later question, from “should this be a dropdown” to “do we need accounts”, was already answered. When a spec and the code disagreed, we fixed one and said which. We do the same on client MVPs, and it is the part founders most often want to skip because it does not feel like progress.
Decision two: no AI model in version one
newdo infers dates, people and effort from a plain sentence. “Send Arun the revised quote by Thursday” becomes an item for Arun, hard deadline Thursday, about fifteen minutes. The obvious build is to send that sentence to a language model.
We did not. Version one uses rules: a date parser, a list of people to match against, and a few small lexicons for effort and urgency. It is instant, works offline, sends nothing anywhere, and costs nothing to run.
The reason is not cost. It is that the core idea, the list as an output with a reason under each item, either works or it does not, and a model would make it impossible to tell which. If the idea holds up on rules, adding a model later is a one-file change behind an interface that already exists. If it does not, no model would have saved it. We wrote about charging before you build the feature last week. This is the engineering version of the same instinct: prove the idea with the cheapest thing that could possibly work.
Decision three: local-first, static, no server
Everything the app knows lives in the visitor’s browser. There is no account, no database, no backend. The deploy is a folder of static files on Cloudflare, which means the hosting bill is zero and there is nothing to secure, patch or wake up at 3am for.
This closed off some features on purpose. It does not sync across devices. It cannot read your email yet. Both are on the list, and both would have doubled the build and added an authentication system before a single person had tried the idea. An MVP is defined by what you leave out, and the leaving out has to be a decision you can name, not an accident of running out of time.
What we would tell a founder
If you take one thing from this, take the order of operations. Spec, then the cheapest inference that could work, then the cheapest infrastructure that could work, then launch, then measure. We set two numbers before launch: how often the app’s proposals get confirmed, and whether the maker still opens it after three weeks. Launch-day votes are not on the list.
The tools mattered less than you would think. Yes, we used an AI coding assistant, and it did most of the typing. But it could not decide what to leave out, and that is where the day was won or lost. The founders who ship in weeks are not faster typists. They make the scoping decisions early, write them down, and hold to them.
You can try newdo in thirty seconds, no signup. It opens with demo data. The source is public and the spec is the first file in the repo. If you want yours built the same way, this is how we work with founders, and Labs is where our own experiments live.