Inside every developer lives a second self — the one who wants a new project the moment they get bored with the current one.
Most advice says you should fight that self. Discipline. Focus. Finish what you start.
I think that's wrong. 99% of the ideas that second self hands you really are going nowhere. But the 1% is worth every other one combined — and the only way to find out which is which is to let the second self speak, fast.
Tutorial hell is when you follow step-by-step guides without actually understanding them. You open a "Build X with Y" article, you type the code the author tells you to type, you rename a few variables, and six hours later you have a thing that runs. It looks like you learned something. You didn't. You learned the shape of someone else's decisions — their project layout, their preferred libraries, their stylistic quirks — but you didn't make a single call of your own. The moment your own idea diverges from the tutorial by one step, you're stuck. You close the tab, tell yourself you need "more practice", and open the next tutorial. Repeat for years.
Rapid prototyping looks similar from the outside: you start, you don't finish, you move on. The content is completely different. You make every decision yourself. You don't know the "correct" way to do it, so you pick the shortest path. The result is ugly but it's yours, and every line of it represents a choice you made — which means you can extend it, break it, debug it, or throw it away on purpose.
Concrete example. Say the idea is a habit tracker.
Tutorial hell version: "I'll follow a 'Build a Habit Tracker App' tutorial." Six hours later you've typed the code the author told you to type. You have something that runs. If someone asks you why useEffect has an empty dependency array, you shrug. If you want to add a feature the tutorial didn't cover, you go hunting for another tutorial. Somewhere along the way the original idea of "a habit tracker" became irrelevant — you're just solving the puzzles the author gave you.
Rapid prototyping version: "Can habits be tracked with a bash alias that appends to ~/.habits.txt?" Thirty minutes later, yes they can. Next morning: did you actually use it? No → the idea was the problem, not the stack. Delete it. Yes → now you have a signal that something is worth building, and you already know the minimum it has to do.
The difference isn't how much time you spend. It's who made the decisions.
Tutorial hell answers: "Did I finish the tutorial?"
Rapid prototyping answers: "Does this idea even work?"
Those are not the same question. And the side-project graveyard in most developers' GitHubs is full of answers to the wrong one
Rapid prototyping's real superpower
Here's what I missed for years: the point of rapid prototyping isn't speed. It's feasibility.
When you start a project the traditional way, you commit before you know anything. Two days of setup, one day picking a UI kit, half a day deciding between Postgres and SQLite — and you've spent a week on the question "what stack should I use?" before you've touched the question that actually matters: does this idea work at all?
Rapid prototyping inverts that order. You answer the second question first. You build the ugliest possible version of the idea — a single HTML file, a bash script, a route that returns JSON — and you look at it. Not the code. The thing the code does. And you ask: is this useful? is it fun? does it solve the problem I thought it did?
Most of the time, the answer is no. That's the part people don't want to hear. Most ideas that look brilliant in your head collapse the moment they exist in the real world. You only find out by making the cheapest possible version first.
Here's the reframe that finally clicked for me. The second self — the voice inside every developer that wants a new project every time the current one slows down — isn't what needs fixing. The cost of listening to it is. When that cost is two weeks of setup per impulse, you either fight the second self with willpower, or you end up in a graveyard of half-finished folders. When the cost is two hours, you can let it speak. You can try the thing. Most attempts still collapse — but you find out in an afternoon instead of a month, and the attempts that don't collapse have already proved themselves before you commit to them.
That's the real move. Not "follow every impulse." Not "ignore every impulse." Reduce the price of every impulse until it stops mattering whether the impulse was right. Feasibility testing by default, built into the way you start.
Which brings me to the thing I actually built.
The thing I built: PointArt
A month ago, PointArt didn't exist. My default stack was Spring Boot — that's what I reach for when I start anything serious. Then a client asked for something simple: just a website. Nothing that justified spinning up a JVM.
I'd written PHP years ago and hadn't touched it in a while. Sitting with the brief, I started remembering how cheap PHP can be, shared hosting for a few dollars a month. Aggressively un-cool and aggressively cheap. But I didn't want to give up the parts of Spring that made me productive: JPA, dependency injection, attribute-based routing. Those aren't luxuries once you've built real apps with them — they're how you move fast without shooting yourself in the foot.
So I built my own. PointArt is a PHP microframework with zero dependencies that runs on the cheapest shared hosting you can find and carries the Spring-shaped programming model I was used to. Attribute routing. Dependency injection. An ORM with repositories.
The original reason for building it was one client site. But once you have a framework you trust, everything downstream gets cheaper — and that's where the ratchet came from. My cold-start cost for a new prototype dropped from a week to an afternoon, and every idea I'd been putting off became worth trying.
The first thing I built on top of it was a RAG system — an AI retrieval-augmented-generation demo for a different idea I had been sitting on. I never published it. The prototype took an afternoon and it answered the question: does the idea work? (Not really.) But more importantly, it answered the question the framework actually needed: what's annoying about writing a real app on this thing? The first round of framework fixes came directly out of that RAG prototype. Nothing about the RAG itself survived. Everything I learned about the framework did.
The second thing had a longer runway than PointArt itself. I took a game design course in college and I've been a quiet fan of browser-based games for years — the kind you open in a tab with no install, no launcher, no friction. Recently I'd stumbled across Phaser.js and realised I finally had the right tool to make one myself. The PointArt prototype was the excuse I'd been waiting for.
So I built GameHub — a browser-based game platform with a dot-com era deckbuilder called DotCom Broker 98 as its first resident. It's in beta right now at PointArt GameHub. Everything runs in the browser: no download, no install, no app store. The game itself is fully web-based and server-authoritative, so the client can stay as dumb as Phaser allows.
That's three live pieces in about a month:
- PointArt — the framework itself, live at pointartframework.com
- The PointArt website — the docs + marketing site, built on the framework itself (eating its own food from day one)
- GameHub — in beta, the first real load test for the framework at scale
Plus one unpublished experiment — the RAG — whose only lasting purpose turned out to be sharpening the tool that built the next two.
That's what the ratchet looks like in practice. The graveyard version of this same month would have been three half-finished folders in my Projects/ directory and nothing to show anyone. The ratchet version is three URLs, one platform, and a pile of concrete lessons heading into whatever I build next.
Fundamentals first, then speed
Everyone quotes Kent Beck's "make it work, make it right, make it fast" — and most solo devs get it exactly backwards. They try to do all three at once on a brand-new prototype. They reach for the perfect ORM before they've validated the idea. They argue about what database to use before they've written a single line of feature code. Then they stall out, call it a "focus problem", and move on to the next project.
Kent Beck wasn't handing us three boxes to tick simultaneously. He was handing us three gates. Make it work — and only after the thing actually works, and only if it deserves to exist, do you graduate it to "make it right". Only after "right" is meaningfully right do you earn the question of "fast". The gates are the whole point. Skipping the gates is what kills solo projects, not the order itself.
Rapid prototyping, stripped of the buzzword, is just phase 1 taken seriously. Make it work. Don't worry about refactoring — you haven't earned that question yet. Don't worry about performance — you don't have users yet. Just: does this thing, in its ugliest possible form, answer the question I set out to ask? If yes, you graduate it. If no, you delete it and move on without guilt, because you never paid the "right" tax on an idea that didn't deserve it.
There's a catch, though. Phase 1 is only cheap if you can actually write phase-1 code. "The ugliest possible version" still has to be real code that runs. If you don't know your language well enough to throw something together without looking things up every thirty seconds, phase 1 isn't a two-hour sprint — it's a three-day tutorial hunt. Which is exactly the thing you were trying to escape.
I wrote a whole separate post about this fundamentals half: "The Hidden Cost of Framework-First Thinking.". Short version: reach for a framework after you've written the thing it abstracts away at least once, not before. The same principle applies here — you earn the right to prototype fast by having written the boring, foundational version first. Once that knowledge is in your hands, the ugliest-possible-version is an hour, not three days.
So the order matters. Fundamentals first. Framework second. AI third. Get any of those in the wrong order and the whole stack collapses into a different flavour of tutorial hell.
The order matters because of the symmetric case. Without language fundamentals and a framework you trust, AI output has nothing to land on. You can't verify what you don't understand, and you end up stacking generated code on top of generated code, chasing bugs that move every time you regenerate. That's not a problem with the AI — the tool is fine, it's the ground underneath that's missing. It's the same pattern as copy-pasting Stack Overflow without reading the answer first: the shortcut only works if you already understand what it's shortcutting. Once that's true, the same AI goes from noise to leverage overnight.
Speed without understanding is just faster mistakes. Speed with it is leverage.
If you're reading this and thinking "this sounds great, let me go start prototyping fast" — maybe. If you know your language well enough to catch === when it should be hash_equals(), yes. If you don't yet, do that first. It's the best investment you'll ever make in your own velocity.
Concrete practices
Enough philosophy. Here are the rules I actually follow, cribbed together from a year of getting most of this wrong.
Time-box phase 1 to one sprint. Whatever "one sprint" means in your calendar — for me it's usually a focused afternoon, for you it might be a weekend. The point is the bound, not the length. If nothing resembling an answer exists at the end of that window, the problem isn't effort. It's either the approach or the problem statement itself. Do not extend the sprint "just a bit more" — that's how prototypes become tutorial hell. End the sprint, look at what you have, make a decision.
Best case scenario only. Phase 1 is about the best-case scenario, nothing else. No auth. No error handling. No input validation. Hardcoded credentials if they make the demo shorter. If even the happy path is boring when it works, the idea doesn't deserve a phase 2 — and you'll have learned that in a day instead of a month.
Rapid prototyping is not "skip testing". This one needs saying out loud because I know how the rest of this post sounds. Phase 1 compresses the discovery phase, not the quality phase. Once an idea graduates to "make it right", you still write tests, still handle errors, still watch real users hit the rough edges. GameHub is in beta when I am writing this article. Phase 1 told me the idea worked. Phase 2 is sitting behind a small door while I fix whatever the first handful of players break. Cutting phase 1 short gives you clarity. Cutting phase 2 short gives you embarrassment.
It's about your future self, not your code
Here's what this whole thing is really about.
Solo devs talk a lot about "discipline" and "focus" as if the hardest part of shipping software alone is making yourself work harder. It isn't. The hard part is that the version of you who starts a project and the version of you who has to finish it are not the same person. Your future self is going to be tired, distracted, bored, and — most importantly — already thinking about the next idea. That's not a character flaw. That's just how creativity runs.
Everything in this post is a process for protecting that future self from themselves.
Time-boxing phase 1 is a promise you make to the future-you who would otherwise spend three weeks on setup for an idea that was never going to work. The happy-path-only rule is a promise to the future-you who would otherwise get stuck wiring input validation for a demo nobody is going to run. Rapid prototyping is a promise to the future-you who would otherwise look at an unfinished project with shame and quietly close the tab.
And the second self — the voice that wants a new project every time the current one slows down — isn't something you fight. It's the same voice that originally got you into this. It's the part of you still reading the frontier, still noticing where the interesting problems live. You don't want to silence that voice. You want to give it a system where being right or wrong costs almost nothing, so it can keep speaking.
This is why solo devs need a development model at all. Not because the code quality matters in the way it does for a ten-person team. Because nobody else is going to stop your past self from signing your future self up for a three-week tutorial marathon on behalf of an idea that'll die in the first afternoon. You're the whole reviewing committee. You have to install your own guardrails.
The methodology isn't really about the methodology. It's about keeping faith with the version of you who hasn't shown up yet.
If you want to see any of this in action
Two live things, one devlog series, and an open offer.
PointArt — the framework that started all this. Zero dependencies, attribute-driven, Spring-shaped, runs on the cheapest shared hosting you can find. Live at pointartframework.com.
PointArt Devlog — this post is one of a series. The others cover how the framework got built, when not to reach for a framework at all, the self-updater, webhooks, and a handful of other posts I'll keep adding to. They all live at PointArt Devlog Series.
GameHub — DotCom Broker 98 — the deckbuilder the second half of this post is about. It's behind a key-based beta at gamehub.pointartframework.com. If you want a key, just ask. Drop a comment below, or email me at
info@pointartframework.com— I'm handing them out one at a time to anyone curious enough to poke at it.
And honestly: if you've got your own second self nagging at you right now, I'd rather hear which project it's pointing at than whether you liked this post. Tell me in the comments
Top comments (0)