Every Dev Has the New-Project Itch. Rapid Prototyping Makes It Creative.

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. 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

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: .

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