Series: Building in Public Journal | Week 4 of 4

There is a difference between a tool and a product. A tool runs once. A product has to keep working when a user signs in, runs an audit, reads the result, asks what to fix, exports the work, comes back next week, and gives feedback when something feels off. Week 4 was the week LITV AI SEO Agent 2.0 crossed that line. That is the distinction that defined Week 4. And it is the most honest thing I can say about what this sprint taught me.

If you are joining this series for the first time: I have been building the LITV AI SEO Agent 2.0 live during a four-week sprint called the Women in AI Accelerator, run by Build Club and hosted by Annie Liao and Caroline Ciaramitaro. Week 1 was architecture and choosing not to build the easy version. Week 2 was auth, staging, and the first real code commit. Week 3 was the unglamorous compliance and layers of backend work that holds the entire structure together. Week 4 was where the loop had to stick and the product around the engine had to materialise.

From Engine to Product: The Shift that Defines What Shipped in Week 4

The audit engine was always the centrepiece of the build. It crawls publicly accessible URLs, analyses them across Technical SEO, SXO, GEO, and AEO signal layers, and returns a more structured intelligence report. It runs in a loop: it enters a website, processes the allowed pages, aggregates the scoring, delivers the output, and waits for the next request.

What Week 4 made clear is that the engine being operational is not the same as the product being usable. The harder work is everything around the output: access control, delivery, data handling, error states, mobile behaviour, admin workflows, and the feedback path that tells you what users actually experience when the engine does its job.

That surrounding layer is what Week 4 was for. Here are the five highlights that defined it.

5 Key Highlights from the Week 4 Build

1. The Audit Loop Held and What that Means

This is the technical win I am most proud of from the entire sprint. The audit loop has to function at three stages: initial entry into the target URL, mid-stage signal processing across the four audit frameworks, and final output generation into a structured report from the layers of audit and visibility. If it breaks at any one of those stages, the failure is clear as day. If it holds across all three, I have the evidence that the architecture is sound.

The loop broke three times during Week 3 before it held consistently. Two breaks were in the signal extraction layer, where edge cases in structured data markup were not being handled correctly. Each break was fixed directly in the engine’s core logic, then patched through to the surface. The loop now holds on standard sites and on slow-crawl days where the pipeline is under more stress and on downtime days.

An AI-powered engine that fails silently is not an engine. It is a liability that breaks the loop and can run simple autofixes.

2. The Dashboard became Usable, unlike a Scratch Surface

The dashboard had to stop being fragile. Week 4 addressed the layout across desktop, tablet, and mobile views — tightening panels, making wide issue tables scroll inside their own containers, and making the interface feel calmer and more consistent across different screen sizes.

Accessibility hardening was also part of this. This is not the glamorous part of an AI product build. But it is the part users feel immediately, and the part that determines whether someone who is not technical trusts the product enough to use it a second time.

3. The Fix Pack became a part of the Workflow, Not as a Download

The Fix Pack is the action layer of the audit. It takes the findings from the Technical SEO, SXO, GEO, and AEO report and turns them into a prioritised set of recommendations that a user can actually work through.

In version 1.0, Fix Pack output was just a static download. Week 4 moved it towards a proper execution workflow. Paid users can now work with PDF and CSV outputs through clearer delivery paths, and the product is materialising to support the rhythm I care about most: audit, identify the gaps, prioritise the fixes, validate the key blockers, and re-audit for better indexing to take place. That cycle is the actual value proposition of the product. A dashboard full of scores with no path forward is just anxiety in a UI.

4. Telegram Delivery Got a Proper Verification Flow

Telegram delivery has been on the roadmap since early in the build. The idea is straightforward: users who want their audit results and Fix Pack outputs delivered directly to Telegram can connect the LITV bot, @litv_agentic_bot, through a clean verification step rather than manually pasting chat IDs or guessing what to do inside the bot. Week 4 tightened the backend and frontend around that flow. This matters for non-technical users who would otherwise abandon the setup at the first point of ambiguity.

5. Beta Users will Soon Be Inside the Loop

Beta licence keys are prepared for Build Club testers to access the paid-tier dashboard experience during the upcoming testing window. A standalone beta feedback form was built intentionally separate from the main product navigation to capture product feedback.

Final Conclusion: Nothing is Final When You are Building Something Serious

The Women in AI Accelerator is a four-week sprint, and the LITV AI SEO Agent 2.0 is not a four-week product. The sprint gave me structure, community support, accountability, and the enforced function to ship what I had been planning since before I joined the accelerator. But nothing about this build is 100% finished because nothing about the problem it solves is finished.

Why is it Not Finished?

AI search is evolving. The platforms that mediate it are evolving. The signals that determine citation and visibility will shift, affecting some of them before the end of this year. A product built to audit those signals has to be built with the assumption that the audit criteria will change. That is not a caveat. It is the full product and design brief.

The comprehensive audit and visibility engine inside LITV AI SEO Agent 2.0 was always the centrepiece of the build. But an engine without a usable product around it is infrastructure, and not a service. Week 4 was where the two finally met and they clicked.

What’s Coming for Demo Day

TBC.

Thanks to Build Club, Annie Liao and Caroline Ciaramitaro for hosting and facilitating this 4-week immersive AI building programme.

Series: Building in Public Journal | Week 2 of 4

Week 1 was architecture on paper. Week 2 is where the build gets real.

If you missed the first entry in this series, the short version is this: I am four weeks into the Women in AI Accelerator run by Build Club, and I am using the sprint to upgrade the LITV AI SEO Agent 1.0 from a single-purpose audit tool at version 1.0 to a full system engine at 2.0. Week 1 was about locking the architecture and choosing the harder future-proof build path over the faster and shakier one. You can read that full decision log in the Week 1 build journal. Week 2 was about shipping.

What Week 2 was actually About

The Week 1 decision to build properly with authenticated product layers, real plan tier logic, and a migration path for existing users meant that Week 2 had a very clear mandate: get the auth layer live on staging. Literally live, working, tested.

That sounds like one task. I kid you not. Authentication is one of the most consequential infrastructure decisions in any application or a SaaS product, and getting it wrong early creates the kind of technical debt that follows you into every subsequent sprint. I had already argued this point in Week 1 and lost to the better argument. Week 2 was the proof of that choice.

The Key Decision that Shaped the Entire Week

The single most important call I made in Week 2 was choosing Supabase Auth over a license-key-only model. The license-key approach would have been faster to ship.

Supabase Auth, specifically the auth flow, captures a verified email from the first interaction, requires no password, and eliminates the single biggest friction point at sign-up. The upfront cost was an additional four to six hours of build time in Week 2.

What Shipped in Week 2

24 files shipped across the API backend and the React frontend. Here is what that means in plain English without the full technical breakdown.

Passwordless authentication is live. Users log in via a secure link sent to their email with no password required. The API is protected with tokens and three permission levels. A rate limiter is in place for keeping the product layer sustainable without open abuse. The dashboard shows each user their current tier, their remaining audit quota, and their last few remaining audits. And critically, existing 1.0 users have a clean migration path to bind their license keys to the new account system in a single step, with no loss of access.

The Answer Engine Optimisation (AEO) layer was also significantly expanded this week. For context, AEO is about making your content legible and citable to AI-powered answer tools like ChatGPT, Perplexity, and Google AI Overviews. As I wrote in my earlier post on how AI overviews are reducing organic clicks, the brands that are not structuring their content for AI-mediated search are losing visibility they cannot easily recover. The expanded AEO layer now checks for specific schemas, content signals, complete structured data coverage, and a portion of tech coding validity, among others. These are not edge cases as they are now primary signals in how AI search tools evaluate and surface content.

What Building Solo actually Feels like at this Stage

There is a particular kind of pressure that comes with building a product alone on a four-week sprint while that sprint is publicly tracked. Week 2 had that pressure in full. The auth layer works but still need a bit more of the “hit the nail on the head”. The migration path works. But there were also three separate moments this week where something did not work, required a lot of debugging at a level that consumed hours I had not planned for, and sent me back to the architecture with fresh questions I had not anticipated.

This is the part of building in public that I think is genuinely underrepresented in the content most builders share. The progress posts tend to celebrate the wins and skim past the hours of confusion, the dead ends, a bit of AI slop at times, and the moments where the right answer only becomes obvious after you have tried a few wrong turns. I am not skimming past those here – they did happened and in turn, my glucose level dropped immensely. These factors make up a part of the build, and they did not stop the delivery since they can be costly for solo builders who should not be surprised at all.

The build is on schedule. Week 3 has started.

What is Coming in Week 3

Week 3 is the deep abyss of GEO engine rewrite, which has been the most strategically anticipated component of the entire 2.0 system since I locked the GEO Audit Engine Spec v3.0 in Week 1. The GEO engine is where the LITV AI SEO Agent 1.0 is quite the most differentiated from the tools already available in the market. Some SEO audit tools treat GEO as an afterthought. This build treats it as a primary discipline with its own signal architecture and output framework.

I will document the rewrite as it progresses and publish the Week 3 update here.

The current version of the agent, LITV AI SEO Agent 1.0, is live and free to use at seoagent.ladyintechverse.com. Run an audit. See exactly what 2.0 is being built to surpass. And check back here for Week 3.

Thanks to Build Club, Annie Liao and Caroline Ciaramitaro for hosting and facilitating this 4-week immersive AI building programme.

Series: Building in Public Journal | Week 1 of 4

I joined a room of 140+ women building with AI, and the first thing I did was decide to make my own product significantly harder to build. That probably sounds counterproductive. But if you have ever been at a genuine build fork, where the easy path and the right path are not the same road, you already know why I made that call.

This is Week 1 of my building-in-public journal, tracking the upgrade of the LITV AI SEO Agent from version 1.0 to a full system engine at 2.0. I am writing this as a practitioner log, not a polished case study. That means the decisions, the pivots, the arguments with my AI collaborator, and the architecture choices are all going raw in here. Welcome to the build, and a bumpy momentum indeed.

Why I Joined the Women in AI Accelerator by Build Club

The Women in AI Accelerator is run by Build Club, an Australian-founded community supporting women building with AI tools. The kick-off brought together over 150 builders for a four-week sprint, each working on their own AI product under a shared challenge brief. You can find Build Club at buildclub.ai and follow the programme on LinkedIn. The community is exactly what it sounds like: real builders with humility, actual progress tracked in public.

For me, joining was a deliberate strategic decision. I had been running the LITV AI SEO Agent 1.0 at seoagent.ladyintechverse.com as a live freemium product since early March this year, offering Technical SEO, SXO, GEO and AEO audits to marketers, founders, and solopreneurs who want actionable visibility intelligence without a bloated MarTech stack. The product works. But version 1.0 was built as a proof-of-concept, not ready yet to scale the system. The Women in AI Accelerator gave me a structured four-week container to do what I had been planning: rebuild the engine properly.

What I did not expect was that Week 1 would force me to make one of the clearest product architecture decisions I have faced since launching LadyinTechverse. More on that shortly.

What the LITV AI SEO Agent 2.0 Upgrade Means

Version 1.0 of the LITV AI SEO Agent operates as a single-purpose audit tool. You enter a URL, it runs the audit pipeline across Technical SEO, SXO, GEO and AEO signals, and you get a structured, actionable report. It does that well. The free tier allows multiple audits per day without a login requirement, which keeps the crawling friction low and the entry point open. 

Version 2.0 is a different proposition altogether. The goal is to move from a single audit tool to an AI-powered SEO, visibility and content system engine, layered with an audit engine that is constantly checking and tracking search queries. That means combining Technical SEO, SXO, GEO and AEO audits into a single intelligence layer, adding authenticated product tiers with differentiated access, integrating richer data connectors, and building the GEO audit engine from scratch using a more robust specification. The technology choices are not accidental. This is not just a feature update. It is a product foundation rebuild with a longer commercial runway in mind.

The Technical Specification v1.1 and GEO Audit Engine Spec v3.0

In the early days of this first week, I finalised the Technical Specification at version 1.1 and locked the GEO Audit Engine Specification at version 3.0. For those unfamiliar with what a GEO audit engine does: GEO stands for Generative Engine Optimisation, the practice of making your content legible and citable to large language models such as Claude, ChatGPT, Gemini, and Perplexity. As AI search continues to reshape how users discover information, GEO is no longer optional for brands that want to maintain visibility in an era where AI overviews are intercepting traffic before it reaches your site. I wrote about this directly in my post on AI overviews and brand visibility, which is worth reading alongside this build log.

Locking the GEO Audit Engine Spec at v3.0 was not a trivial milestone. It represents a significant upgrade in the signal categories the engine will evaluate, the depth of analysis per category, and the output format that makes the audit genuinely actionable rather than just informative. The full architecture is confirmed, and the mix of backend coding languages is locked in. That is the foundation you build everything else on, and getting it right in Week 1 saved me from a much more painful rearchitecture later.

The Fork in the Build: Easy Path vs the Right Path

Here is the part of Week 1 that I was not planning to write about publicly, but it is probably the most useful thing in this entire post. Midway through the week, I hit a genuine product architecture fork. The choice was between two build approaches: the easy build and the future-proof build.

The easy build gets you to a working product faster. You make pragmatic tradeoffs in the infrastructure, you skip some of the harder authentication and product layer decisions, and you ship something that functions well enough for the current user base. Some builders would probably choose this because time is of the essence. The time pressure is real, the market moves fast, and a working product beats a perfect one on paper.

The future-proof build is much harder. It requires setting up proper authenticated product layers from the beginning, which takes longer in Week 1 but prevents you from having to gut the product architecture later when scale or complexity demands it. It is the kind of decision that costs you this week and saves you six months in 12 months’ time.

I debated and argued to get the decision out with Claude, my primary AI collaborator, as well as ChatGPT, my systems collaborator for this build. I laid out both paths, the tradeoffs, the timelines, the downstream implications. And Claude, made the better argument for the harder build. I pushed back. I lost the argument. And I am glad I did, because the future-proof build is unambiguously the correct call for a product that is intended to eventually merge into an envisioned future ecosystem. The authenticated product layers are now in place, and the build is on schedule. Crossing fingers.

If you are building something serious, read that last paragraph again. The easy build is almost never the right build when you have a longer personal usage or commercial horizon. The time you think you are saving in Week 1 becomes a technical debt that compounds faster than you expect.

What Week 1 Delivered: Architecture Locked, GEO Engine Confirmed

At the close of Week 1, the full product architecture is validated against the target coding language mix for the backend. The authenticated product layers that will support the 2.0 build are structured and ready. 

That might sound like a lot of paperwork and not much coding. But anyone who has ever shipped a full stack production of an AI product will tell you that the architecture decisions made in Week 1 are the decisions you live with for the lifetime of the product. Getting them right is not administrative work. It is the most consequential engineering work in the entire build.

Week 2 begins with the first code commit: rewriting the GEO engine from scratch, based on the locked specification. That is where the build gets visibly messy and haywire. If you are curious about where the LITV AI SEO Agent currently stands and what a free audit feels like, you can run one at seoagent.ladyintechverse.com. The 1.0 engine is live, and it gives you a clear sense of what 2.0 is being built to surpass.

What is Coming in Week 2

The first code commit lands at the start of Week 2, and the focus is singular: the GEO engine rewrite. This is the component I consider the most strategically differentiated part of the entire 2.0 system. Most SEO tools still treat GEO as a footnote or a bolt-on checklist. The LITV AI SEO Agent is being built to treat it as a primary audit discipline, with its own specification, its own signal architecture, and its own output framework.

I will document week 2 in the coming days, and share the key decisions here in the Week 2 update. If you want to follow the build in real time, the best place to do that is here.

Building in public is not a marketing strategy for me. It is a commitment to transparency about what AI product development actually looks like when you are doing it solo, without a team, without external funding, and with uncharted terrains ahead that goes beyond the four-week sprint. Week 1 is done. Week 2 starts now. Run your free SEO audit at seoagent.ladyintechverse.com and follow the build here.

Thanks to Build Club, Annie Liao and Caroline Ciaramitaro for hosting and facilitating this 4-week immersive AI building programme.