I've Built Software for 20 Years. My Own Product Took 12.

I have been writing software professionally for over twenty years. In that time, I have built and delivered systems used by millions of users, led engineering teams through complex migrations, and delivered projects on schedule in high-stakes environments. I am good at what I do, and I love doing it!

And yet the personal finance app I have been building took 12 years to launch.

The Disconnect

At work, I thrive. Someone defines the requirements. A product manager sets the scope. There are deadlines, stakeholders, and a shared understanding of what "done" means. In that context, I execute well. I design clean architectures. I write thorough tests. I deliver on time. The process works because there is an external structure that channels my instinct for quality into productive output.

On my own projects, that structure disappears. And without it, every decision becomes an open question. Should the data model use UUIDs or KSUIDs? Should I build the API in Go or Rust? Is the category system flexible enough? Each answer leads to more questions, and each question feels like it deserves the same rigor I bring to my day job.

The result is a loop. I build something. I decide it could be better. I refactor. I research alternatives. I rebuild. Months pass. The project has technically improved, but it has not launched. Nobody has used it. And at this rate, nobody ever will.

The Project

The project is Trupocket, a personal finance platform. I personally have been tracking every penny I have spent since 2004 and I have tried nearly every finance app out there. None of them gave me the combination of manual transaction entry, flexible categorization, developer API access, and detailed reporting that I wanted in a single tool. Before Trupocket, my system was two apps and a spreadsheet with 5 tabs, and logging my transactions took anywhere from 15 to 60 minutes depending on how much spending I had done. It worked, but it was tedious and time-consuming.

So around 2013, I started building my own. The earliest iteration was a raw PHP app that eventually grew into a Laravel application. When Go became my primary language at work, I rewrote the whole thing for the performance gains. Then I rewrote it again and again in Go because I was getting better at the language, the language itself was maturing, and I kept finding ways to make pieces of the code more resilient, extensible, and structured. Along the way, I migrated databases for better performance and introduced code-driven database migrations so the schema could evolve alongside the application. Each rewrite produced a better architecture. None of them produced a product that anyone could actually use. The finish line kept moving because I was the one drawing it.

The Loop

When you are the sole decision maker on a project with no external deadlines, perfectionism does not look like procrastination. It looks like progress. You are writing code every week. You are solving real engineering problems. Your test coverage is excellent. Your architecture is clean. By every technical measure, the project is improving.

But you are not releasing. And the reason is that "done" is a moving target that you control. Every time you get close to a milestone, you see three more things that could be better. The authentication system works, but it could be more elegant. The transaction model is functional, but there is a more normalized schema you could try. The API documentation exists, but you could add more examples.

At work, a product manager would say "that is good enough, let's release it." On a personal project, there is nobody to say that. The same instinct for quality that makes you effective as a professional engineer becomes the obstacle when there is no external voice to say "stop."

I will give you a concrete example. In 2022, I spent three months building a complete scheduled transactions system. It worked well. You could set up recurring transactions with flexible frequencies, skip dates, and auto-generation. Then I decided the internal scheduling model was not elegant enough, so I rewrote it. The rewrite took two months and produced a system that was marginally cleaner but functionally identical. Five months of work, zero user-facing progress.

I did this repeatedly, across years, with different parts of the codebase. Every component got the same treatment. Build it, evaluate it, rebuild it. The project was perpetually six months from being done.

I spent 12 years in that pattern. I was never idle. I was always building. I was never releasing.

What Changed

Three things shifted in late 2024 and into 2025.

The first was a change in perspective that took far too long to arrive. After a decade of false starts, I accepted that the project would never be perfect and that waiting for perfection was functionally the same as never launching. I know this sounds obvious when written down. It was not obvious when I was living it.

The second was a layoff in mid-2025 that gave me three unplanned months. Instead of immediately job hunting, I committed to finishing one feature in Trupocket without refactoring it. Just one. That single completion sparked something I did not expect. Finishing one piece fueled finishing the next. And the next. Momentum built on itself in a way that 12 years of circular development never had. Success begets success, it turns out, and the opposite is also true.

The third was building an autonomous AI engineer system that writes first-draft implementations. This changed my relationship with the project in a way I did not anticipate. Instead of being the sole creator making every decision from scratch, I was reviewing and directing work. That put me back in a role I excel at professionally: technical leadership. Evaluating output against a standard, making targeted improvements, and deciding when something is good enough to move forward.

But the AI did more than replace the blank page. I specifically trained it to be an accountability partner. It was configured to challenge me on any feature I wanted to build or refactor that was not essential to launching. When I started slipping into the perfectionism loop, it would call me out directly and tell me to stop. I gave it enough freedom to be blunt about it, including the occasional cuss word when the situation called for it. I was using AI as a forcing function for discipline, and it worked.

With those shifts, the Go API that had been evolving through multiple iterations reached a point where it was genuinely complete. Over 60 endpoints. 107 test files. 85,000 lines of Go. 11 database migrations. Authentication, budgeting, transaction tracking, scheduled transactions, and a complete reporting system.

On December 7, 2025, I tagged v1 and deployed to production.

The Launches

The API launched first. 6 releases went out on launch day as I worked through deployment configurations, plan settings, and documentation updates. By the end of December, there were 12 releases. The rapid iteration felt different from the years of circular development that preceded it. Every release addressed a real issue discovered by real usage, not a hypothetical improvement for a product nobody had tried.

The web app followed on February 11, 2026. Another intense launch day: 7 commits and 5 releases, fixing server-side rendering deployment, environment variables, Node.js compatibility, and service role permissions. The kind of problems that only surface when code meets production for the first time. 356 React components. 340 test files. Over 200,000 lines of TypeScript across 34 pages.

On March 5, 2026, mortgage tracking went live. A full account type for the single biggest financial commitment most people have, with principal and interest breakdowns, escrow tracking, and amortization schedules.

From a 12-year loop to three production milestones in three months. The contrast still catches me off guard when I think about it, to be completely honest.

The Pattern

I have always assumed my struggles are ones other people would not relate to. The way my mind works, the specific flavor of perfectionism that kept me stuck for over a decade. It all felt uniquely mine.

But when I finally stepped back and looked at it honestly, the pattern was not that complicated. I am an architectural perfectionist. Professionally, I can balance that trait to deliver high-quality systems and solutions because external constraints keep it in check. Deadlines, stakeholders, and shared goals create friction that converts quality instinct into launched product. But on a solo project where I am the person defining all aspects of the product end-to-end, that same trait becomes the blocker. There is no counterweight. The perfectionism runs unchecked, and the engine runs forever without producing output.

What broke the cycle for me was introducing friction artificially. A deadline I committed to. An AI system that produced drafts I could evaluate rather than create from nothing, and that was specifically trained to push back when I drifted toward unnecessary work. A conscious decision to treat "good enough for real users" as the bar instead of "good enough for my internal standard."

If you have a side project that has been collecting dust for years, the question worth asking is whether the problem is technical or structural. If you know how to build it and you have the skills to build it, but you still have not released it or keep refining it, the challenge may not be more hands-on-keyboard time. It might be whatever your version of a forcing function looks like.

Try It

Trupocket is live. The API, the web app, the documentation, all of it. After 12 years, it is real and it works.

If you are interested in a personal finance platform built by someone who has been tracking every dollar for over 20 years, give it a try. And if you are staring at a side project that has been "almost done" for longer than you want to admit, I get it. I spent 12 years in that exact spot. The way out was not another refactor.