How to Pick Project Ideas That Actually Ship

The best project I ever shipped started as a complaint. I was tutoring RNVS, a computer networks course at LMU, and I kept drawing the same TCP handshake and sequence-number diagrams by hand, over and over, for students who needed to see the packets move. It was tedious and my drawings were ugly. So I built SequenceFast, a tool that generates those diagrams properly. It shipped because the idea had a property that most of my ideas did not: I was the user, the pain was happening weekly, and I would feel the relief immediately.

That property is what this article is about. Over the years I have started far more projects than I have finished, and the pattern in the wreckage is consistent. The projects that died were not killed by bad code or lack of skill. They were doomed at selection, by an idea that could never have shipped given who I am and how much time I actually have. Picking the right idea is not the romantic part of building, but it is the part that decides everything before you write a line.

Idea generation is not the bottleneck. Idea selection is.

Developers love to act as if ideas are scarce. They are not. You have twenty ideas in your notes app right now and so do I. The scarce resource is the judgment to look at twenty ideas and pick the one that will actually exist in three weeks instead of joining the others in the graveyard of half-finished repos.

So I have stopped optimizing for having more ideas. I optimize for filtering the ones I have. The filter matters more than the source, because a great idea you cannot ship is worth exactly as much as a bad one: nothing. A mediocre idea you actually finish, deploy, and put in front of a person beats a brilliant idea that lives forever in a branch called wip.

So here is the question that reframed everything for me. Predict your answer:

The four questions I run every idea through

Before the four questions, it helps to know roughly which kind of project the idea even is, because that changes how hard the bar should be. Walk the branches below and it will route you to the move I would actually make in your spot.

I do not have a scoring spreadsheet. I have four questions, and an idea has to survive all four to earn my limited evenings.

Do I feel this pain myself, regularly? This is the strongest predictor I have found, by a wide margin. Every project of mine that shipped scratched my own itch on a schedule. SequenceFast from tutoring. AiCal from manually copying flight times into my calendar. MyUniNotes from drowning in my own course material. When I am the user, I do not need market research, I do not lose motivation, and I know instantly when the thing is good enough, because I use it. Ideas where I am not the user die quietly, because the moment the novelty fades there is nothing pulling me back.

Can the first useful version exist this month? Not the full vision. The first version that does one thing a real person would touch. If I cannot picture that version fitting into the fragmented hours I have as a working student, the idea is too big, and "too big" is just "never shipped" wearing a costume. The honest move is to shrink the scope until the first useful version is uncomfortably small, then build exactly that.

Does it have a natural stopping point? Some ideas are bottomless. A "personal knowledge management system" or "the perfect task manager" has no edge; you can polish it forever and never be done, which means you will never feel finished and will eventually drift away. SequenceFast had an edge: it draws the diagrams correctly, the end. Ideas with a visible finish line ship. Ideas without one become hobbies you resent.

Will finishing it teach me or show me something? Since my building time competes with a master's degree and a job at BMW, an idea has to pay rent in either learning or proof. CanvasConvo, my bachelor thesis, paid in both. openAIScientist, an R package, taught me a packaging ecosystem I would never have touched otherwise. If a project teaches me nothing new and demonstrates nothing to anyone, it had better be solving a real personal pain, or it does not make the cut.

An idea has to survive all four to earn my limited evenings. Click through them:

The traps that look like good ideas

There is a specific category of idea that feels exciting and is actually a trap, and I have fallen into all of these.

The first is the idea that is exciting to architect and boring to finish. You can tell because you are already drawing the database schema and the microservice boundaries before you have established that anyone wants the thing. The fun is in the design; the work is in the last 20% nobody enjoys; and that 20% is where these projects go to die. If the appeal is the architecture, that is a warning, not a green light.

The second is the idea whose first version is enormous. "An app like X but better" where X is a mature product with a hundred features. Your version-one needs all hundred to be comparable, so version one never arrives. The ideas that ship are the ones where a tiny first version is already independently useful to at least one person, namely you.

The third is the trend-chasing idea, the thing you are building because a technology is hot rather than because a problem is real. I am genuinely interested in new tooling, but "I want to use this shiny thing" is a reason to build a tiny throwaway demo, not a reason to commit a quarter of evenings. The tech is a means. When it becomes the end, the project has no real why, and projects without a why stall the moment they get hard.

When two of these survive my filter at once, the tiebreaker is almost always scope, so test your own instinct here:

I used to reach for the exciting one every time, and that instinct is exactly what filled my graveyard with wip branches.

A small process that keeps me honest

When an idea passes the four questions, I write down two things before I open an editor: the single sentence describing the first useful version, and the one concrete behavior that tells me it works. For SequenceFast that was "renders a correct TCP handshake diagram from a short spec" and "I use it in my next tutoring session instead of drawing by hand." Two sentences. They take five minutes and they have saved me from countless scope spirals, because the moment I am tempted to add a feature I check it against that first sentence and most temptations fail the test.

First useful version: <one sentence, one user, one outcome>
Done when: <one concrete behavior you can observe>

That is the whole spec for a side project. Anything more elaborate at the start is usually procrastination dressed as planning.

To make the rhythm concrete, here is the actual sequence a passing idea goes through before it becomes a live thing I use. Click each step to expand what happens and why it matters.

The sequence looks obvious written down, but the discipline is refusing to skip step two, where the temptation to just start coding is strongest.

Scope is the variable that predicts shipping

If I had to keep only one signal from the four questions, it would be scope, because scope predicts shipping better than excitement, novelty, or even how much I care about the problem. The reason is simple and a little unflattering: I do not have a reliable supply of motivation, I have a reliable supply of small windows. A bus ride, a quiet hour after work at BMW, a Sunday morning before the LMU reading catches up with me. Ideas that fit those windows get finished. Ideas that demand a clear weekend I do not actually have get postponed until they rot.

The momentum argument follows from that. Every finished thing, no matter how small, makes the next one easier, because shipping is a habit your brain learns to trust. After SequenceFast actually went live, the next project did not feel like a gamble, it felt like the obvious next rep. Three abandoned grand projects in a row teach the opposite lesson, that starting is pointless, and that belief is far more expensive than any single dead repo.

So I shrink an idea to weekend size without killing it by cutting features, not ambition. I keep the one behavior that makes it real to a single user, namely me, and I defer everything else to a version two that may never come. SequenceFast did one diagram correctly before it did anything else. The trick is that a small finished thing still teaches and still proves, while a large unfinished thing teaches only that I overreached. Shrink the scope, keep the point, ship the rep.

Somewhere between BMW shifts and my LMU M.Sc. CS reading I got tired of arguing with myself about which idea to start, so I turned the gut feeling into arithmetic I can run in thirty seconds. Here is the rough scoring function I use to rank two surviving ideas against each other, with the reasoning behind each weight annotated.

score(idea) =
  + 2 * (can I ship in a weekend?)
  + 2 * (do I personally need it?)
  + 1 * (can I explain it in one line?)
  - 3 * (does it need other people to work?)

The numbers are not sacred, but the ordering has held up across every project on my site. Whenever two ideas tie on excitement, this function quietly breaks the tie toward the one I can actually finish.

To make the cost of an oversized feature list concrete, drag the slider below and watch the launch date move:

The number it shows is not a precise estimate, it is a reminder that scope and time are the same lever wearing two names.

Each pre-launch feature is a week you might quit during

The slider makes a point I learned the slow way: scope is the most honest launch-date predictor I own. When I list the features a project must have before it goes live, I am really listing weeks, and every week before launch is a week I might quit during. Motivation does not decay on a schedule, it decays on a feature list. The longer the road to the first real user, the more chances life at BMW or a deadline at LMU has to knock me off it before anyone ever touches the thing.

So I hold myself to a one-feature launch discipline. I pick the single feature that makes the project worth opening, I build only that, and I ship it before I let myself add a second. SequenceFast launched on one diagram. Everything else arrived later, pulled in by feedback instead of guessed at in advance. Cutting to one feature is not lowering the bar, it is shortening the stretch of road where the project can die, and a shipped tool with one feature beats a perfect plan with ten that never compiles.

Matching the idea to the season you're in

One thing the four questions do not capture on their own is timing, and timing has sunk more of my projects than I would like to admit. The same idea can be perfectly shippable in one month of my life and completely impossible in the next, because the constraint that actually governs a side project is not the idea's difficulty but the shape of the time you have around it. An idea that needs long uninterrupted focus is a bad idea during exam season at LMU, no matter how good it is, and a great idea to queue for the gap afterward.

So I have started being honest about the season I am in before I commit. During a heavy rotation at BMW, I deliberately pick smaller, more self-contained ideas, things I can finish in fragments, like a focused tool or a single-purpose script. When I have a genuine stretch of free time, that is when a thesis-scale project like CanvasConvo or a package like openAIScientist becomes realistic. Matching the idea's ambition to the season's available focus is not lowering your standards. It is the difference between finishing something modest and abandoning something grand, and a finished modest thing is worth infinitely more than an abandoned grand one.

I can put rough numbers on this, because I tracked it for a while. In a normal week I get maybe six to eight usable evening hours for side work, and during an LMU exam block that drops to nearly zero for three or four weeks straight. The gotcha is that those hours do not arrive as one clean block, they come as twenty- to forty-minute slivers between other obligations. An idea that needs a two-hour uninterrupted ramp just to reload context in my head is effectively unbuildable in that shape, no matter how few total hours it claims to need, because I spend the first fifteen minutes of every sliver remembering where I was. The projects that survive a busy season are the ones where a sliver is enough to make one observable unit of progress: render one more diagram type, fix one parser edge case, wire one endpoint. That is also why I bias hard toward tools with a tight feedback loop and almost no setup ritual; if opening the project costs more than the sliver itself, the season will quietly kill it. I learned this distinction the expensive way, and it is the same instinct I lean on when I decide whether a repo is even worth dressing up into a portfolio piece, which I wrote about in turning a GitHub repository into a portfolio asset. The lesson compounds: knowing your real hours per season is worth more than any productivity trick, because it stops you from starting the right idea at the wrong time.

The graveyard is a feature, not a bug

I want to push back on the idea that unfinished projects are pure waste, because that belief makes people cling to bad ideas out of guilt. Some of my dead projects taught me exactly the lesson that made the next one ship. PrioTask did not survive, but building it is how I internalized that switching costs kill task-manager ideas, which is knowledge I now apply for free at the selection stage. The graveyard is where you pay tuition for your judgment.

The mistake is not starting things that die. The mistake is starting things that die slowly, dragging on for months past the point where you knew, because admitting an idea was wrong feels like admitting you were wrong. Decide the kill criteria early, the same way I argued in the validation context, and the graveyard fills with quick, cheap lessons instead of slow, expensive regrets. A fast death is a successful experiment. A lingering one is just denial with a commit history.

This is also why I keep the selection bar high rather than starting everything that sounds fun. Every project you start spends attention you cannot get back, and the opportunity cost of building the wrong thing is the right thing you never got to. Saying no to a tempting-but-unshippable idea is not pessimism. It is protecting the time for the idea that will actually exist at the end.

Take the idea sitting in your notes app right now and run it through the filter. An idea has to survive all four to earn your limited evenings, tick honestly, and watch most ideas fail here instead of three weeks into a wip branch:

Keeping a kill log

There is a difference between letting a project die and learning from it, and for years I only did the first. The project ended, I felt vaguely bad, and the lesson evaporated, which is why I kept getting tempted by the same idea-shape over and over. So now I keep a kill log: a plain text file where every abandoned project gets one line naming what it was and one line naming exactly why it died. Not "I lost interest," which explains nothing, but the specific structural reason.

The discipline is in the naming. PrioTask died because the switching cost from my existing setup was too high, so no version of it would ever pull me back. A note-taking experiment before MyUniNotes died because it had no natural stopping point, the bottomless kind I warned about earlier. A small social tool died for the simplest reason of all: I was not actually the user, I just thought the space was interesting. Three dead projects, three different failure modes, and writing them down forces me to say which one it was instead of blaming my motivation.

What surprised me is how the log works forward, not just backward. Before I commit to anything now, I skim it, and half the time a new idea rhymes with a dead one. The shape that killed PrioTask shows up in a new task-manager idea, and I recognize it in thirty seconds instead of three weeks. The log turns the four questions from a checklist I run consciously into a filter I have internalized, because each entry is a scar that makes the next instance of that mistake obvious.

A dead project is expensive. You already paid for it with evenings you cannot get back. The kill log is how I make sure I collected the one thing it was actually worth: a named, reusable piece of judgment instead of a vague feeling that I should be more disciplined. Reviewing it costs five minutes and sharpens the selection filter every single time.

Killing an idea early without regret

The hardest part of building is not starting, it is admitting partway through that the thing should not exist. So I have learned to decide the kill criterion before I write any code, in the same two sentences I use to define the first useful version. If the project is not in front of a real user, namely me, by a date I name up front, it dies. Writing that down before I am emotionally invested is the only way I have found to kill cleanly later, because by week four my judgment is hopelessly biased by the evenings I have already spent.

That bias is the sunk-cost trap, and it is brutal precisely because it dresses itself up as commitment. The hours I poured in feel like a reason to keep going, when they are exactly the reason I cannot see clearly anymore. The honest question is never "how much have I already invested," it is "would I start this today knowing what I now know." If the answer is no, every additional evening is throwing good time after bad, and as a working student at BMW finishing an M.Sc. CS at LMU Munich, time is the one resource I genuinely cannot manufacture more of.

What makes the kill bearable is that a dead project still teaches. PrioTask never shipped, but building far enough to feel the switching-cost problem taught me something no article could have. The lesson is the deliverable when the tool is not, and a project that dies fast and teaches clearly is a better trade than one that limps along teaching nothing. This is the discipline I leaned on in the from side project to SaaS validation work, where killing a weak idea early was the whole point.

The last move is recycling. A dead project is rarely a total loss, because the parts outlive the whole. The auth flow, the deploy script, the data layer, the small utilities I sweated over all get lifted straight into the next idea, so the next one starts further along. The graveyard is not just where bad ideas go, it is a parts bin for the good one that finally ships.

Why this compounds

Here is the part that is easy to miss when you are staring at a single idea. The developers who visibly ship are not the ones with better ideas. They are the ones who finish, and finishing is overwhelmingly a function of what you chose to start. Pick shippable ideas consistently and you end up with a row of finished things, each of which taught you something and each of which you can point at. Pick unshippable ideas and you end up with a row of wip branches and a vague sense that you never have time, when the real problem was selection all along.

You can see the survivors of my own filter on /#projects, and the running commentary on what worked and what did not on /blog. If I had to compress the whole framework into one line: pick the idea where you are the user, the first version is small, the finish line is visible, and you will learn on the way. Everything else is a fun conversation and an empty repo.

Whatever idea you chase next, the projects I ship on adatepe.dev all started as a scoped bet like this, and I love comparing notes on what actually ships.