How many graveyards of half-finished projects have I made
You start building something on a burst of motivation, but it doesn’t take shape that day, and a day later the drive you had is gone. Have you had that experience?
I’ve been doing indie development for several years, building things like iOS apps, Chrome extensions, and web services. I stockpile ideas in Notion every day. But as time passes, I start thinking “I guess I don’t have to do it,” or I stop and wonder “is there even any point in building this?” With too many options for what to do next, my motivation would sometimes drop straight to zero. I’ve quit before publishing an app more than once or twice.
This is the idea memo I keep accumulating in Notion. Of the 300-plus, I’ve actually built 12. On top of that, there were 36 I scrapped before building. I manage them by category on a board. The proportion that reaches completion is roughly this.
From here, I’ll introduce the failure patterns I experienced as someone who broke his own spirit again and again, and the things that were good to keep in mind to keep going.
I want to but I have no drive — motivation isn’t “willpower,” it’s “fuel”
“I have the desire to do it, yet for some reason I can’t get started.” I think this is the trickiest state in indie development. It’s not that the drive has completely vanished. The idea I want to build is always in my head, yet only my hand refuses to open the editor.
Digging into the reasons, I usually arrive at these two.
- The bar rises on its own: You inflate the finished form in your head, and the first step becomes a big deal—“I have to build it properly,” “I can’t ship something half-baked.” The more you think, the heavier starting gets.
- You don’t know where to begin: Design, tech selection, design, priorities—you decide everything yourself. Overwhelmed by the sheer number of choices at the entrance, you freeze right there.
For a long time I thought this “can’t get started” was a matter of willpower. But most of the reasons for not sticking with it aren’t weakness of will. When you reframe motivation not as something you squeeze out by grit but as fuel supplied from outside, the way you see it changes.
Motivation is “fuel” supplied from outside
The fuel I’m talking about here is the sense of response, reactions, and the feeling of moving forward. The code ran, someone used it, you reached a small milestone. In moments like these, fuel is replenished and becomes the drive to move to the next step. Conversely, when this supply is cut off, no matter how high your initial drive was, you lose momentum.
Running out of fuel usually happens in set patterns.
- The goal is too far: The distance to completion is long, and it takes weeks before you get any sense of response.
- The windless period where no one sees it: Since you haven’t published, you keep building with zero reactions.
- Running out of steam on environment setup: Before you get to the main topic, you use up your most energetic time on configuration and boilerplate.
- Boredom just before launch: You’re almost ready to ship, yet for some reason your hands stop.
Lining them up, a common point emerges. In all of them, the distance until you get “completion” and “reactions” is far. In other words, running out of fuel is not a problem of grit but a structural problem of building in a way where fuel is hard to reach you.
Making “money” your fuel is the first thing that won’t last
When you try to make money from what you build, this fuel shortage accelerates even more. Making a profit from indie development is, in most cases, extremely hard. When you make money the goal, the period without money is very long, and during it you keep running while fuel never reaches you.
Money is fuel supplied too slowly. Your spirit breaks before the first yen comes in. More than that, your own passion—that you want it, that you want to build it—is a far faster and thicker fuel.
Using your own passion as motivation rather than money makes a world of difference in both drive and productivity.
Weapon #1: Fastest deploy — create a state where “there’s a URL” before any code
From here, I’ll introduce two weapons for not running out of fuel. The first is fastest deploy. The idea is to run the deployment pipeline before writing any code, creating a state where a production URL exists even if the contents are empty. It’s a topic covered in all sorts of articles, and that’s because it works.
Flip the order to “publish, then build”
Most people proceed in the order of build → complete → publish. In this order, publishing is dead last, so if you run out of fuel before reaching it, everything gets shelved.
With fastest deploy, you flip this order. You prepare the box for publishing first, and add the contents afterward. The first contents can be Hello World. What matters is prioritizing above all a state where a production URL exists and you can show it to people anytime.
Always keep open the entrance where you can get reactions
Being deployed means the entrance where the fuel of reactions comes in is always open.
Just by having it published, you can receive small fuel even while you’re mid-build. Watching your own access logs, getting a word from an acquaintance, pasting it on social media and watching the reactions. That kind of sense of response. When you develop only locally, this entrance stays closed the whole time, so no fuel comes in until you finish.
Building the first box
In my case, I deploy a minimal setup to Cloudflare or Vercel, hook up a domain, and first build up to where just one screen displays. Before the contents, I create the state of it being live.
Conversely, a common failure is trying to make it perfect locally before publishing, and ending up in the graveyard without ever publishing. If you deploy after over-building, when it’s finally time to publish you stumble on build errors or environment differences, and your motivation drops all at once right there. If you run the pipeline first, it’s also easier to isolate which change during your work caused the error.
There was no AI back then, but the situation is different now. For example, if you use Jumpstart, which you can choose when creating a repository on GitHub, you get a reasonable foundation built almost at the same time as creating the repository.
If your usual setup is fixed, you can template the repository and turn your usual implementation and favorite design into a skill, so you can assemble a Jumpstart tailored to your taste. You can keep lowering the very cost of building the first box.
”Ship fast and surface the problems” over “build it clean”
If you try to build it clean from the start, perfectionism eats fuel here too. Time spent carefully tidying up code isn’t necessarily forward progress. Rather, shipping fast and quickly surfacing real-world problems moves the project forward more.
And what users look at isn’t the level of polish. Does it work properly, does it display fast, is it usable. That’s about all they care about, and it doesn’t need to be perfect down to every corner at the freshly-built stage.
“Building fast and surfacing problems” is the only way to move a project forward.
Don’t try to build it clean from the start. You’ll rebuild it in the end anyway, so the time spent building it clean goes to waste.
— The only way to move game development forward, grasped over 15 years in the field
The only three things users care about are the UI, the site’s display speed, and whether the site actually works. Even the UI doesn’t need to be perfect for a site that was just made.
— Why does your indie development fail? Learning service-building anti-patterns from failure cases
Weapon #2: Small start — split it into “a size you can finish in one work session”
The second weapon is small start. It’s the technique of splitting what you want to build down to a size that reaches a milestone in one chunk of work.
Split down to the “smallest completion,” even further before MVP
People often say to build an MVP (minimum viable product), but from the perspective of managing fuel in indie development, even an MVP is often still too big. What you aim for is one step before that: the smallest unit of completion you can finish in a single sitting.
If it’s split small, completion comes frequently. Since fuel is replenished each time you complete something, you avoid creating long windless periods.
What to cut: how to choose the first single feature
So what do you cut. The criterion is simple: discard starting from things that hold value even without them. Login features, admin screens, granular settings—these can usually be pushed back.
For the first single feature you build, narrow it down to just the core of the experience you most want to show. First aim for a state where the one thing you most wanted to do in that app works, and only that. I myself have experienced many times cutting something I’d originally envisioned packed with features down to just the core single feature for the first release, and finally managing to get it published.
Five rules for indie development without stumbling
- Build as little as possible of what you can avoid building
- Birth it small and grow it big
- Don’t make skill acquisition the goal; build things within your reach
- At minimum, build something that you or an acquaintance will absolutely use
- Aim for a tool that even one person can use, not a platform
As a way to lower the probability of giving up, it’s good to proceed with everything roughly and loosely. With the belief that you’ll fix the details later, narrow down to the absolute minimum of features and build something that works fast, even if the design is terrible.
— How to learn programming while lowering the probability of giving up
Choose to build something where “you can be the heaviest user”
Whether you can keep going even with a small scope is largely decided by your choice of subject. My recommendation is to build something where you can be the heaviest user.
If it’s something you use every day, you can supply the fuel of reactions yourself. Even in a windless period where no one uses it, at least there’s one user: you. This is also the flip side of the point that making money your goal won’t last.
Be the heaviest user yourself.
— Three things to raise your motivation in indie development
Turn the two weapons as a single loop
The two weapons so far aren’t separate techniques; they work when you turn them as a single loop.
Split small with small start, ship right away with fastest deploy. Receive the fuel of reactions and sense of response from what you shipped, and use it as capital to split the next small piece. Picture keeping this circle turning: split small → build → deploy right away → receive fuel → split again.
Since you ship small, watch the reactions, and then add the next piece, you also naturally prevent overbuilding and unnecessary features. The trick to keeping one cycle short is to divide by the next unit you can ship rather than by deadlines, and to deploy once right before perfectionism is about to ignite.
Indie development isn’t a sprint. Even so, you can break a long distance down into repetitions of short distances.
Indie development is a long-distance run. Split the course yourself.
Follow the output-supremacy strategy of taking many shots so some will land.
Other switches for adding fuel
Let me also introduce a few smaller fuel-replenishing switches that don’t fit onto the two weapons.
Motivation grows just from good looks
Motivation grows just from good looks.
When I ask “make it look nice” with no UI idea at all and something better than expected comes out, my motivation clearly lasts longer. Just the fact that what I’m building looks good becomes fuel in itself. So obsessing over looks from early on is also a fine strategy for keeping going.
Offload decision fatigue to AI
In indie development, you control everything alone. Flip that around, and thinking and deciding all fall entirely on you. It’s not rare to be unable to decide what to do next and stop right there.
Deciding, in itself, quietly eats fuel. So when you can’t decide the next move, let AI decide. Even just having it lay out options and leaving only the final decision to yourself keeps you moving without stopping.
Words I’d like to offer myself when my motivation is about to break
Finally, an emotional switch that works when fuel is about to run out.
Watch people who are working hard
Just following other indie developers and watching X can be fuel. Your timeline carries release announcements for new apps and reports of earning revenue. Just watching that brings back the feeling of “I’ll do it too.” Following people who are working hard is also often cited as a way to raise motivation.
And it’s not only fellow indie developers who are working hard.
Quoted from Professional: The Way of Work
Even someone as accomplished as Hayao Miyazaki grumbles “what a pain” when facing his work. And yet he keeps his hands moving. Thinking about that, somehow I can push on too, so I periodically rewatch this footage.
Summary
What has stopped my indie development isn’t weakness of will but running out of fuel. The weapons to prevent it are the two: fastest deploy and small start. Build the box for publishing first, split small and ship, and turn the next piece using reactions as fuel. Designing this loop is what matters.
If reading this far has stored up even a little fuel for you, the next step is decided. The contents can be zero, so today, build just the deploy box. Start from creating the repository.
