✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
This is the canonical warning against throwing away working code and rebuilding from scratch, told through Netscape's rewrite that handed years to competitors. Read it before you convince yourself the messy MVP needs a clean-slate v2: it names the exact trap you are about to walk into. Treat it as a starting point, not gospel, since sometimes a rewrite really is right, but the burden of proof is on you.
From
Joel on Software
by Joel Spolsky
~10 min read
- Old code that looks ugly is usually carrying years of hard-won bug fixes and edge-case knowledge you cannot see, and a rewrite silently throws all of it away.
- It is harder to read code than to write it, which is why the instinct to rebuild almost always feels stronger than it should.
- Most of what tempts you toward a rewrite (architecture, slow spots, cosmetic mess) can be fixed incrementally through refactoring instead.
Open
joelonsoftware.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
If Spolsky tells you not to rewrite from scratch, this gives you the alternative: replace the old thing piece by piece while it keeps running, so you never take a big-bang risk. Fowler's strangler fig metaphor (a new system grows around the old one until it can stand alone) is the practical middle path between suffering the MVP and blowing it all up. A good next read once you have decided some part genuinely needs replacing.
From
martinfowler.com
by Martin Fowler
~8 min read
- You can modernize a system incrementally by building new features alongside the legacy code and gradually routing traffic away from the old path, instead of a risky all-at-once cutover.
- Investment and returns arrive gradually and visibly, so you can stop, ship, or change course at any point rather than betting everything on one launch.
- A facade or proxy in front of old and new lets you shift functionality over piece by piece while the product stays live for users.
Open
martinfowler.com →
📄 Article
✓ Link checked
Free
Advanced
Why we picked it
This lays out when accumulated shortcuts actually start slowing a growing company down, versus when they are just cosmetic. It gives you language to tell your co-founder the difference between debt that is costing you real velocity and debt that is only annoying. Use it to pressure test whether your no-code setup is genuinely blocking growth.
From
martinfowler.com
by Tim Cochran and Carl Nygard
20 min read
- Measure tech debt by the velocity it costs, not by how ugly it looks
- Debt only matters once it blocks a thing you are trying to do now
- Address the specific bottleneck rather than rebuilding everything
Open
martinfowler.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
First Round reframes the rewrite instinct as remodeling rather than demolition, which is the honest way to think about your no-code app. It gives you a checklist for deciding whether the existing thing is worth remodeling or truly needs replacing. Good ammunition for the conversation with your technical co-founder about scope.
From
First Round Review
by Andrea Goulet (via First Round Review)
18 min read
- Remodel working systems instead of tearing them down by reflex
- A rewrite freezes new value while you rebuild old value
- Assess the current system honestly before deciding to replace it
Open
review.firstround.com →
📄 Article
✓ Link checked
Freemium
Intermediate
Why we picked it
Concrete, field-tested advice on deciding which debt to pay and how to justify it. Orosz and Franco share practical rules of thumb for tying rewrite pressure to real jumps in usage or scope, which matches your point about rebuilding under real load rather than on a hunch. It also covers measuring the payoff so cleanup does not become an endless detour.
From
The Pragmatic Engineer
by Gergely Orosz and Lou Franco
20 min read
- Tie rewrite decisions to real jumps in scale or usage
- Pick debt to repay based on where it slows real work
- Measure the impact of cleanup so it stays honest
Open
newsletter.pragmaticengineer.com →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
When you and your technical hire are arguing about the stack, this essay reframes the whole fight: the goal is not the best or newest tool, it is shipping a product and keeping the company alive. McKinley's idea that every team has only about three innovation tokens gives you a shared, honest test to settle most stack disagreements before they turn personal. It is the closest thing to a neutral referee both sides can respect.
From
mcfunley.com
by Dan McKinley
~20 min read
- Every team gets about three innovation tokens, so spend novelty only where it is core to the product, not on the database or the framework.
- Prefer well understood technology, because its failure modes are documented and the long-term cost of keeping things running dwarfs any early convenience.
- Adopting new tech should require a real conversation about the problem it solves, not one person's preference, which is exactly the frame a founder and hire need.
Open
mcfunley.com →
📄 Article
✓ Link checked
Freemium
Intermediate
Why we picked it
This draws the line between code (or a no-code build) that exists to learn and a system that carries real users, money, and data. It helps you name the moment your MVP crosses from learning tool to product that must not fall over. That crossing, not a feeling, is what should trigger the migration talk.
From
Unknown Arts
by Patrick Morgan
10 min read
- Prototypes exist to learn, production exists to hold weight
- The trigger is real users and revenue on the line, not vibes
- Name the production requirement your current build cannot meet
Open
unknownarts.co →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
Teal reached a million-plus users and raised five million dollars while still running on Bubble, which is direct evidence that no-code is not automatically the thing holding you back. Read it as a reality check against the assumption that real code is required to be a serious company. Note the platform has a stake in the story, but the traction numbers are real.
From
Bubble Blog
by Emmanuel Straschnov
8 min read
- No-code carried a real product to over a million users
- Investors funded the company, not the tech stack under it
- The bottleneck is often the product, not the tool it runs on
Open
bubble.io →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Many founders fear that no-code will make them look unserious to investors, and this piece tackles that head on. It gives you language for framing your stack as a speed advantage rather than a liability. Handy to read before a fundraising conversation.
From
Bubble
by Bubble
~10 min read
- No-code is a speed advantage, frame it that way
- Investors care about traction, not your stack
- Have a clear answer for the re-platform question
Open
bubble.io →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
This is a clear-eyed breakdown of where a major no-code platform genuinely struggles, including that you cannot export your app as source code and are locked to the platform. Vendor lock-in you cannot stomach is one of the few honest reasons to migrate, and this names it concretely. Use it to judge whether lock-in is a real risk for your specific product.
From
Contrary Research
by Matthew Wong (Contrary Research)
20 min read
- No source code export means real vendor lock-in
- Latency-sensitive and real-time apps strain the platform
- Lock-in you cannot live with is a legitimate migration trigger
Open
research.contrary.com →
📄 Article
✓ Link checked
Freemium
Intermediate
Why we picked it
Jason Levin grew a product to $100K ARR on Bubble with no engineers, then raised $3M and re-platformed to an API. It is a clean example of the arc our answer describes: find traction on no-code first, re-platform later once it is worth it. You get the specific decisions behind when and why he made the switch.
From
Lenny's Newsletter
by Jason Levin
~20 min read
- Reached $100K ARR on Bubble with zero engineers
- Re-platforming came after traction, not before
- Outgrowing your no-code stack is a good problem
Open
lennysnewsletter.com →
📄 Article
✓ Link checked
India
Free
Advanced
Why we picked it
The CTO of India's largest broker explains how a tiny team scales huge load by optimizing the application before touching infrastructure or rewriting. It is a strong reminder that hitting a limit usually means fixing the slow query, not rebuilding the system. A grounded Indian counterweight to the belief that scale requires a from-scratch rewrite.
From
Zerodha Tech Blog
by Kailash Nadh
15 min read
- Exhaust easy optimizations in the app before rebuilding
- Most bottlenecks are the database, not the platform
- Simple, boring, well understood setups scale further than you think
Open
zerodha.tech →
📖 Book
✓ Link checked
Free
Intermediate
Why we picked it
Basecamp's battle-tested, opinionated system for shipping meaningful work in fixed cycles without endless backlogs, a primary source, free in full. The antidote to over-planning your roadmap.
From
Basecamp / 37signals
by Ryan Singer
free online book
- Work in short cycles with a cool-down between them.
- Fix time, vary scope, use 'appetites,' not estimates.
- Make bets, not plans; no runaway backlog.
Open
basecamp.com →
📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
The origin text for the modern MVP and validated-learning vocabulary every founder now uses. Read it for the mental model that a startup is a series of experiments, not a single bet.
From
theleanstartup.com
by Eric Ries
~330 pages
- Progress = validated learning, not features shipped.
- Run the Build-Measure-Learn loop as fast as you can.
- An MVP is a learning tool, not a cheap product.
Open
theleanstartup.com →
Why we picked it
The permission slip to recruit users by hand, do things manually, and deliver 'insanely great' experiences to your first few customers. The cheapest, most honest way to validate demand is to go get it one person at a time.
From
paulgraham.com
by Paul Graham
~15 min read
- Recruit your first users manually, don't wait for them to come.
- A tiny group of users who love you beats a big group who like you.
- Manual, unscalable effort early is a feature, not a failure.
Open
paulgraham.com →
📄 Article
Freemium
Beginner
Why we picked it
If you do not want to read the whole book, this is Ries in his own words defining the MVP in a few pages. His guiding rule is to strip out anything that does not add to the learning you are after, which is exactly the logic behind delivering the outcome by hand first. It is a fast way to get the concept straight from the source.
From
Eric Ries (Medium)
by Eric Ries
- Remove any feature or effort that does not add learning.
- An MVP is about validated learning, not a finished-looking product.
- Early adopters expect a rough experience, so start with them.
Open
medium.com →
