Four apps in eight weeks

The default tech stack for this kind of project was Vercel for hosting & Supabase for database & user management. Instead of assuming this common stack would suit, I wrote down what the platform had to do, then used that list to rule options out.

Logins. Supabase sells itself partly on handling user accounts for you. While that is convenient, it also creates vendor lock-in, as user accounts and passwords are difficult to migrate. I researched various options that retained portability, and selected a well-maintained open-source solution, Better Auth instead. With logins handled elsewhere, Supabase was really just selling me a PostgreSQL database at a premium.

Scheduled work. The platform needed activities running in the background from day one: fetching data via APIs, recalculating rankings, summarising content, clearing caches, sending email, aggregating statistics, etc. At the time neither Vercel nor Supabase could run background jobs. I commissioned a research report using AI comparing the alternatives and went with its recommendation, Railway.

Working on your own, the thing you miss most is a senior engineer telling you your plan is wrong. So I bought one. I paid for Supastarter, a mature commercial Next.js starter kit — not initially to build on, but to check my own technical specification against.

It found real gaps, and I adopted all of its answers: a simpler structure than the microservices I had been sketching, Turborepo to manage the applications together, Prisma for the database, TanStack Query for loading data, and Zod to validate data at every boundary. I rewrote the specification around what it taught me, and in the end used the starter kit as the foundation too.

The boilerplate natively supported the abstraction of 'organisations' vs associated users (members) which mapped well to Web3Connect.com where a user could manage multiple 'partner' profiles, or a partner could have multiple associated editor accounts.

Prisma allowed me to define the whole database and all its relationships in a single readable file, which meant the AI could read the entire data model at once. That turns out to matter a great deal, for reasons the next two sections explain.

With the specification, database design, category structure and brand positioning settled, I used AI to turn the specification into targeted design briefs, and then into working clickable prototypes — real pages, using the real design system, before any of the actual product existed.

On day four of the production build, I checked the database against my specification and found it had drifted badly: more than a hundred fields that weren't in my schema specification. AI had invented them, plausibly and consistently enough that nothing had visibly broken yet.

I must admit my confidence in building the whole platform using AI was shaken at this point. I was working with early-stage models with 200-250k token context windows, no sub-agent functionality, which dictated a high bar on context management.

I rolled back to a clean copy and updated the AI's base context file to place a mandatory check on database field alignment with my source specification schema.

By day eleven it was clear the single large application I was building was the wrong shape. I was working toward four distinct surfaces and each surface had genuinely different security risks and traffic patterns.

So I split it into four separate applications plus a background service, still managed as one project.

An AI can only hold so much information at once, and building a complex platform with consistent coding & architecture practices, unique business model, abstraction of reviewing of offerings (vs partners) – all starts to create context constraints.

As my base approach, I used a roadmap + sprint approach to break the project into chunks that an AI agent with limited context window could handle. I provided pre-built prototype code & database schema to avoid ambiguity on output.

Dynamic context loading. My base context file had grown from 580 lines to 2,845 — this was using up valuable capacity that could be going to the actual task. I cut it to 200 lines: an index page and the rules that always apply, with everything else loaded only when relevant. I also added a hook function that reads the request, works out which reference documents are needed, and loads those before starting.

Handing over between sessions. When a session ran out of capacity prior to completing a sprint, the standard 'compact' process was leading to hallucination in output from that point onward. Monitoring context usage and 'handing over' the work-in-progress to a clean session was the only solution, however no method existed for cleanly transferring state. So I built commands that wrote a hand-off prompt for a new session to pick up where the last session ran out of context.

Writing decisions down. If the business went well it wouldn't have made sense for me to be stuck in engineering, so at every step of the platform build I planned for handover. I kept a build log for every session - and an architectural decision record for every significant technical decision, why it was made, and what alternatives were considered. By the end that came to 149 decision records and 105 session logs.

Avoiding a $10,000-a-year bill. I had planned to use Algolia for both search and filtering across the whole site. Partway through the build I projected the costs: Algolia charges per request, and at the traffic I was forecasting that came to US$3,000–10,000 a year. It also embedded a critical vendor dependency on nearly every page.

I decided to cut back the scope of Algolia to search query parsing — handling the cases where people misspell keywords, used synonyms or US vs UK spelling. I moved the filtering of partner offerings into PostgreSQL at no extra cost.

Measuring speed during the build. I logged how long every database query took and had the AI watching for slow ones as new features went in. That is how I caught a query taking 600 milliseconds and got it below 100ms through query restructuring.

Cutting scope openly. To achieve my launch date I postponed or feature-gated several features, including a pricing builder for offerings (nice-to-have), messaging facility (required claimed partner profiles), and various Pro features (advanced dashboard, visibility boost subscription). Partners would want to see traffic and reviews before they paid - building functionality that wouldn't be used until this happened was a commercial decision. Thanks to the speed of AI development, much of this was built in the weeks after launch.

Four AI sessions running at once means four sessions that cannot see each other’s work. Each one needed something, so each one built it.

By the time I stopped to tidy up, the four applications had separate versions of the same basic operations: saving and editing records, form/content validation, cache clearing, score recalculation, counting reviews.

The worst case was logins: four separate versions, roughly 2,400 lines of duplicated code, each at a different level of completeness. Four different approaches to handling user sessions in one product isn’t just untidy, it’s a security risk.

I had AI perform a duplicate code audit and refactored the duplicates into shared libraries.

Launch week involved three all-nighters in the final push to go-live. I launched on 13 December 2025, eight weeks after the first line of code (and 2 days before a Christmas cruise with family).

Two things went wrong that weekend.

Day one, the review submission app went down. I only found out because I happened to check. That evening I set up automatic monitoring across all three public sites.

Day two, a login bug on the live site. I added thorough error reporting so any error, no matter how small, would come to me immediately via Pumble (Slack alternative).

The months following launch went into speed optimisation, releasing held-back functionality, monitoring user behaviour (PostHog), back-office tools and automations, and targeting vendors to claim thier profiles.

There were various architectural issues that needed attention:

Forms. Adding one field to a partner or offering form meant editing more than ten different places. I audited how every form was built and validated, then consolidated it. The UX behaviour was included – scrolling to a field with an error, highlighting it, explaining the problem, greying out ‘next’ button with a tooltip saying why – all written once and shared, rather than rebuilt in each application.

Release process. I found a gap in my pre-release checks that was letting broken code through to the live site even though it worked fine on my machine, and added several automatic safeguards behind it.

Page speed. Restructured the key pages, removed or delayed code that wasn’t needed immediately, and audited what was actually being loaded.