Hartdrawss ships 50 MVPs, shares rules
- Developer Harshil Tomar, who posts as @Hartdrawss, used a May 6 X thread to distill lessons from shipping 50 MVPs for clients and founders. - The thread’s sharpest rule is brutal scope control — sell the problem first, test concepts in a day, then cap real MVP builds at 42 days. - It matters because solo builders now have faster AI tooling, but the bottleneck has shifted from coding speed to judgment.
Shipping an MVP used to sound like a technical problem. Now it sounds more like a restraint problem. That’s the point of Harshil Tomar’s May 6 thread on X — posted from the @Hartdrawss account — where he says he’s shipped 50 MVPs and then lays out the rules that kept those projects moving. The useful part isn’t “build fast.” Everybody says that. The useful part is how aggressively he narrows what “build” even means. ### Who is this advice for? This is founder-and-freelancer advice, not enterprise product doctrine. Tomar is talking to solo builders, small agencies, and early-stage founders who need to get something into users’ hands before they burn months polishing the wrong thing. That framing matters — because a lot of the thread only makes sense if your main risk is wasting time, not coordinating a 40-person roadmap. ### What’s the core rule? Scope is the whole game. The thread’s through-line is that most MVPs fail before launch because they start too big, not because the code is too hard. So the rule becomes: cut until the product does one thing clearly. Navigation, flows, and screens exist to support that one action. Fancy UI can wait. “Ugly” but usable beats structure first, features later. ### Why “sell first” before building? Because demand is a better validator than compliments. One of the thread’s more practical ideas is to test the market with a service before writing software — basically, do the job manually, charge for it, and watch where the pain repeats. If people won’t pay a human-assisted version, there’s a decent chance that's an old trick in the book, but it keeps resurfacing because it works. ### What’s with the 1-day test? That’s the anti-overthinking move. The thread argues for one-day concept sprints to answer a narrow question fast — can users understand the promise, click through the flow, or complete the key action? This is not a real product build. It’s more like a cardboard mockup of the product. The goal is signal, not software weeks. ### Why 42 days for an MVP? Because a deadline forces honesty. Tomar’s 42-day window is long enough to ship something real, but short enough that you can’t keep sneaking in “just one more” feature. That constraint also changes what counts as success. The MVP is not supposed to be complete. It’s supposed to be measurable. You ship, watch usage, and decide whether to iterate, reposition, or kill it. ### Why does ugly wireframing matter? Because polish hides indecision. A rough wireframe makes it easier to ask the only question that matters early on — does this flow solve the problem? Clean visuals can create fake confidence, the same way a nice pitch deck can make a weak business feel stronger than it is. Ugly screens are harder to fall in love with, which is exactly why they’re useful. ### Why does this hit now? AI tools changed the cost of building. They did not change the cost of building the wrong thing. That’s why this thread lands right now: more founders can
