Why We Shut Down Our AI-Built App

We were genuinely excited about the idea of doing a Vibecoder’s Quest, but we never forgot one of TGK’s core rules: we only keep going with ideas we really care about. By the end, the unfinished app felt less like something we wanted to build and more like an idea that simply made sense on paper because there was demand for it. We took it far enough to see what vibe coding could actually do, but once the test had proved its point, neither of us was particularly excited to keep turning it into a real business.

Quick Answer

We stopped working on Unfinished because the experiment had already given us what we wanted. We’d taken a prototype, used Codex to turn it into a functioning web app, tested it with three people, and documented the whole process. What we hadn’t found was a strong enough reason to keep building it.

The idea made sense on paper, and there was clearly demand in the market, but that alone wasn’t enough for us. One of TGK’s core rules is that we only keep pushing ideas we genuinely care about, and by that point neither of us was excited enough about Unfinished to spend months developing, distributing, and selling it. Since we stopped before attempting distribution, we also can’t claim the product failed commercially; we simply chose not to take the experiment that far.

Before taking the hosted services offline, we saved the code, development history and database, then confirmed that the backup could be restored locally. So Unfinished isn’t gone forever, but we’d need a genuinely good reason to come back to it.

What Unfinished Was Built to Do

Unfinished was a small web app for freelancers and small agencies to track client work between finishing a job and actually getting paid. You could record a project, its value, where the payment stood, and what needed to happen next, whether that meant chasing approval, sending the invoice, or following up on an overdue payment.

That distinction was the main reason for building it: finishing €1,000 worth of work does not automatically mean the client owes you €1,000 right now; they might still need to approve the job, or you might simply not have sent the invoice yet. We wanted the dashboard to make those stages obvious at a glance, including whose turn it was to do something next.

The app included user accounts, saved projects, payment history and account-recovery emails, and worked in a browser on both desktop and mobile. It did not try to replace invoicing or client communication tools; instead, it tracked the invoice status and helped prepare follow-up messages when something needed chasing. Our original Codex experiment shows how we built it, what the interface looked like, and the problems we ran into along the way.

Codex wrote and revised the application code under our direction, while we decided how the workflow should behave, configured the external services, and repeatedly tested the running app. Getting the first attractive screen was the easy part; turning it into something that actually behaved like a usable product gave us plenty more to solve.

Why We Built a Client-Payment Tracker

The project started with a question about AI development: could someone on our editorial team build and run a real app without hand-coding it? We wanted to test the kind of claim you see everywhere about building products with AI, then show what actually happened when we tried it ourselves.

A client-payment tracker gave us a useful test case because it involved more than putting a clean interface on top of a database. The app had to make sensible decisions about money, dates, responsibility and records. If it forgot an original payment deadline after a client promised a later one, for example, it could give you the wrong picture of your business no matter how polished the dashboard looked.

We could see that the problem itself was real, and there were already products in the market trying to solve parts of it. That made Unfinished a credible product idea, but not necessarily one we wanted to spend years on. We were much more interested in finding out whether AI could help us build it than in becoming the people responsible for refining, distributing, and supporting a client-payment tracker.

Once the beta was running, that distinction became difficult to ignore. We could keep asking Codex for new features and polishing the design almost indefinitely, but the real next step was no longer another feature. It was deciding whether we actually wanted to turn the experiment into a business.

What the First Testers Told Us

Three people tried the app informally, and the most useful response came from a lesson tutor who already tracked payments in a notebook. Entering the same information into our app took her longer, which gave us a much better question than whether the dashboard looked professional: what would make switching worthwhile for her?

We made a repeat-entry shortcut locally, carrying stable details from an existing item into a new one. That was a response to the problem, although we hadn't measured whether the revised flow was actually quicker for her. Adding the shortcut gave us something to test next, rather than a reason to declare the complaint solved.

Another tester found the interface template-like and wanted a better experience of using it as an app on a phone. A third suggested custom fields or templates so people could adapt it to their work. All three responses were useful, and following them would have meant making choices: simplifying entry, changing the mobile experience or adding flexibility without making the form more complicated.

We also thought the app was clean and minimal but still too generic to be particularly compelling, and the tutor's notebook made that weakness obvious. A new account and a cleaner dashboard aren't much of an offer when entering the information takes longer, so we needed to improve the routine enough to make switching worthwhile.

Those conversations gave us development questions, but we hadn't tested sustained use or willingness to pay. They couldn't tell us whether a more developed version would find an audience.

Why We Stopped at the Beta

Getting Unfinished in front of paying users would have been a new experiment of its own. We would have needed to choose a specific audience, find people with the problem, persuade them to try the app, and learn why they kept using it, abandoned it, or refused to try it in the first place. Charging for it would have added another set of questions around value, reliability, and support.

We never ran that experiment, which means we also can't rewrite the story as Unfinished failing against better-funded competitors or struggling to find customers. We stopped before trying to distribute it, so we don't know whether people would have used it or paid for it. There may well have been a viable product somewhere in the idea, but finding that product would have required much more time and commitment than we wanted to give it.

By then, the experiment we actually cared about had already given us what we wanted: we had used AI to build a working beta, tested it with real people, dealt with the less glamorous parts of making it function, and documented what happened for TGK. We could have kept perfecting forms, adding features, and improving the dashboard almost indefinitely, but having more things to improve wasn't a good enough reason to keep going.

The Cost of Keeping It Online

Our app running-cost breakdown put the server at $7 a month and its 1 GB disk at $0.25, using the listed rates recorded in September 2026. That $7.25 was a server-and-storage subtotal, with account email, additional usage and continued development considered separately.

We used an existing ChatGPT subscription for Codex, shared with our other work, so it would be misleading to charge its entire price to this app. We also didn't keep a complete record of development hours or establish a final all-in bill.

Keeping the service running was affordable enough to postpone the decision, but paying a small bill every month wouldn't improve the product or make us more interested in it.

The larger commitment was returning to the app: checking changes, resolving problems, following up on feedback and eventually promoting it. We could see that work clearly enough to decide we didn't want to keep allocating our time to it, without inventing a precise financial loss.

What We’d Do Differently Next Time

Next time, we'd decide much earlier whether we're running an experiment or building a product we actually want to keep. Both are worthwhile, but they need different plans, so an experiment can end once we've built something, tested it, and documented what happened; a commercial product needs evidence that real people have the problem, understand the solution, and want to keep using it.

If we were building something to continue beyond the experiment, we'd start with a problem we cared enough about to keep investigating after the initial excitement wore off. We'd also talk to potential users earlier and understand what they currently do instead, rather than adding features simply because they make the app feel more complete.

On the development side, we'd keep treating the running app as the final test, regardless of how confidently Codex said something was working. During this build, one form passed its tests but still failed in practice because the newer interface was talking to an older server process. We only caught it because we opened the app ourselves and tried to save a record.

We also learned not to assume that every behaviour we initially dislike is a bug. When we changed the default currency, we questioned why existing euro records stayed in euros before realising that automatically relabelling those amounts as dollars would have been wrong. AI can confidently implement a bad instruction just as easily as a good one, so checking our own assumptions is part of the job too.

What We Kept Before Taking It Offline

We archived the project before deleting the hosted services, as we wanted to retain the build and its records without leaving an unused app running indefinitely, and the shutdown work gave us a way to do that.

We downloaded the live backup and restored it locally, checking database integrity, references between records, and the retained data. The restore also checked the handling of deletion records, and sessions and authentication tokens were cleared as intended.

That recovery check mattered because an earlier restore during development had failed when the script expected a deletion-history file that didn't exist. We'd already seen why having a backup file and successfully restoring it are different things.

The code and recovery material remain, while the hosted web services have been deleted. Bringing it back would require setting up a running service again and checking the app before anyone depended on it; the archive gives us a starting point if we decide to do that.

Final Verdict

Shutting down Unfinished was the right decision for us because we got what we came for: a functioning app, real feedback, and a much clearer picture of what AI-assisted development looks like once you move past the attractive prototype and have to make the thing actually work.

We can't call Unfinished a failed business because we never tested it as one, and while there may have been a viable product there, finding out would have meant committing to distribution, support, and months of further development around an idea we simply didn't care enough about to pursue. AI made it possible for our editorial team to build the app, but it couldn't give us a reason to keep building it, and that decision was still ours.

FAQ

Is an AI-built app the same as an app with AI features?

An AI-built app is software made with help from an AI coding tool. An app with AI features uses AI to do something for its users, such as generating text or analysing an image. The descriptions can apply to the same product, but using a coding assistant doesn't by itself mean the finished app needs to call an AI model.

Could we reopen Unfinished later?

We retained the code, configuration and a backup that passed a local restore, so we have material to work from. Reopening it would still involve hosting setup, appropriate credentials and checks of the running app, including account access and data handling. Our app-security checklist covers those checks in more detail.