I spent two years building my software and abandoned it

I spent two years building my own software, and then I walked away from it. Once I could see that a different approach would reach the goal faster, the right move was to switch immediately, and the new product was running within days.

The lesson in one paragraph

When you understand the biggest move in front of you, you take it right away, even if it means leaving behind something you worked on for years. Time already spent is gone whether you continue or not. The only question that matters is which path gets you to the outcome fastest from where you stand today. In my own words from a recent walk: "once you understand the action you need to take, you take it. You don't sit around pondering or have, you know, a sunk cost."

What I had built

For about two years I built a software foundation designed to let anyone create any tool or workflow. Every tool had to be rebuilt as a plugin for it, and everything ran through one shared log. I believed in it deeply, and I worked on it with very little sleep for months at a time.

The goal behind it never changed. I wanted to give an AI whatever it needs to get the job done and move a person's pursuit forward as fast and as far as possible.

The moment I saw it

The honest truth was hard to admit. As I said on the walk: "I realize that my software was slow, it was not actually delivering the outcome that it was supposed to be delivering."

The goal was right. The way I was reaching it was wrong. The AI tools people already use can run almost any existing software directly. They did not need my foundation in the middle. A simpler design, one open connection that any AI can join, got to the same outcome with a small fraction of the effort.

It did not arrive as one clean insight. It came out of a rough week and a half of doubting the whole thing. I filled pages of my journal, and one night I talked into my camera for about half an hour in near darkness, trying to work out why something I believed in was not getting people the result. The question that finally broke it open was simple: what is the least effort that produces the same outcome? Every honest answer pointed away from the foundation I had built.

Once I saw that, there was nothing to debate. I moved to the new approach the same day. The principles and the good code came with me. The heavy machinery stayed behind.

Here is what that looked like in practice. The old way meant building a plugin, fitting it into the log, and waiting for the whole system to rebuild before anyone could use a new tool. The new way means describing an existing tool once so any AI can find it and run it. A job that used to take days now takes minutes.

Why the sunk cost did not matter

Two years is a lot. It is natural to feel that walking away wastes it. But that feeling is about the past, and decisions are about the future.

If I had kept going, I would have spent months more fighting slow builds and crashes to arrive, maybe, where the new approach already was. Staying would not have recovered the two years. It would only have added to them.

What I did keep was everything I had learned. The two years taught me what the product needed to do, which principles actually mattered, and what to cut. That knowledge made the new version fast to build. The time was not wasted. The machinery was simply no longer the best way to use it.

The result

Three or four days after switching, the first version was done. In my words: "three or four days later, now I have MVP done." It was launching and moving faster than anything I had managed on the old foundation.

Well-known companies have made the same kind of cut. Instagram began as a broader check-in app called Burbn, and its founders cut it down to the one part people loved, sharing photos. Slack came out of a game company whose game did not take off; the team kept the internal chat tool they had built and made that the product. In both cases, the people who made the cut kept what they had learned and dropped what was not working.

How to decide whether to walk away

If you are deep into something that is not delivering, here is the method I would use.

1. Write the outcome you actually want, without naming the project or the tool you are using.
2. Write, honestly, whether the current path is delivering that outcome right now.
3. Describe the fastest possible path to that outcome if you were starting fresh today.
4. Compare the remaining effort on each path, counting only effort from today onward.
5. If the fresh path is clearly faster, switch now, and carry over the lessons, the principles and anything still useful.
6. Ship the first working version as soon as it does the job, then improve it in public.

A small example from coaching makes the same point. When a player I work with has spent months on a technique that keeps breaking down under pressure, the kindest thing I can do is help them drop it early, keep the feel they built, and move to a simpler version that holds up in a match. In my experience, the players who cling to the old stroke because of the hours they put in stay stuck longer than the ones who switch.

The last step matters. I did not wait for a perfect version. My rule now is to "just post it anyway, and it'll get better over time."

What to watch out for

Switching is not the same as quitting whenever something gets hard. Every serious project has stretches where it feels slow. The test is not whether it feels hard; it is whether a clearly faster path to the same outcome exists. If it does not, keep going. If it does, move.

It also helps to talk it through with someone who is not attached to the old plan. The hardest part of seeing a better path is that the old one is yours.

The short version

• Past effort is spent either way; decide only on what gets you there fastest from today.
• Keep the goal, the principles and the lessons. Drop the machinery that is not working.
• When you see the better path, switch immediately rather than pondering.
• Ship the first working version fast and improve it after.
• Hard is not the signal to switch. A clearly faster path is.