The site was live. The first article was published. A handful of real visitors were arriving and reading real content. And I had no idea what any of them were doing once they landed.
The standard answer at that point is to install Google Analytics. Paste a snippet, connect a property, and within a few minutes you have a dashboard telling you how many people visited, which pages they read, and broadly how they arrived. It works. Millions of sites use it. There is nothing wrong with it.
But there was a problem — and it wasn't really about analytics at all. It was about the kind of site we were building. This site is about owning your tools, understanding what you're running, and making decisions based on your own first-party data. Installing a third-party script that sends visitor behaviour to an external server before a visitor has meaningfully agreed to that felt like the wrong foundation for a site built on exactly those values. I wanted to understand how the site performed. I wanted to own that understanding completely.
What I actually wanted
I made a list. It was short, which is usually a sign you've thought about something properly.
Privacy-first — analytics should only run after a visitor has accepted cookies. Not a dark pattern, not a pre-ticked box. A real choice, honoured properly. Self-hosted — the data stays on our server. No third-party receives it. Useful, not impressive — I wanted page views, session patterns, and which links get clicked. Not a dashboard designed to look comprehensive while delivering noise. And finally, something I understood completely. Because I had built it.
That last point matters more than it might sound. There is a meaningful difference between looking at a number in a dashboard and knowing exactly how that number was calculated, what it includes, what it doesn't, and what the edge cases are. When you build the tool yourself, you have that. When you install someone else's, you don't — and you often don't know what you don't know.
The build: from nothing to v1.6 in nine days
I had been working with CC — Claude Code, the technical builder on this project — for a few weeks by this point. We had already built the flat-file website together, published the first article, and proven that the whole approach worked. So when I decided I wanted to build my own analytics platform, CC was the natural partner for it.
The first conversation established the scope. We were not building Google Analytics. We were building something with a clear, specific purpose: track how visitors use this site, help us understand which content works, and eventually give us the ability to act on what we learn — applying tags, triggering automations, feeding an email subscriber pipeline. A platform, not just a counter.
The name came early. Track n Dash. Short, functional, says what it does. We registered trackndash.com nine days after the first build session — not because we had plans to sell it immediately, but because by that point it had earned a name of its own.
The architecture decisions
A few decisions shaped everything that came after. The visitor identifier system was the first important one. We needed a way to recognise returning visitors without storing any personally identifiable information. The solution was a one-way SHA-256 hash that rotates daily — the same visitor gets a different identifier on Tuesday than they had on Monday. It cannot be reversed. It cannot be linked to a real person. Analytics runs, privacy is preserved.
The second was the consent gate. Analytics only fires after a visitor accepts cookies via the cookie banner. This is not technically complex, but it is worth being explicit about: the tracking code is not loaded at all for visitors who decline. The consent is real, and the system honours it.
The third was the module system — and this one had implications we didn't fully appreciate until much later. Rather than building everything into the core application, we designed Track n Dash so that integrations live in a /modules/ folder and boot themselves. The core doesn't know about the modules. A broken module can't take down the site. This is the architecture that eventually made the Brevo connector possible without touching a line of core code.
What got built, version by version
v1.1 brought inline tag creation, page-visit tag rules, and the first proper update path. v1.2 added the form builder — TnD's own subscriber forms, themeable via a CSS hook, with tag-on-submit logic so every form submission tells the system something specific about that visitor.
v1.3 was the big one. GDPR per-user delete — the ability to remove a single user from the database entirely, with a full cascade delete across every related table and a non-personal audit trail that confirms the deletion without logging what was deleted. The right to erasure, implemented properly. That matters. If you're collecting subscriber data, you need this. A lot of tools paper over it; we built it properly from the start.
v1.4 and v1.5 brought the scoring engine and the rules engine. The scoring engine assigns points to user behaviour — visit a pricing page, earn ten points; read three articles in a session, earn more — and uses thresholds to trigger tags automatically when a score crosses a line. The rules engine is the if-then brain that wires those triggers to actions. Tag applied → do this.
v1.6 was where everything came together. The module system, the Brevo connector, and the proof that the entire architecture actually worked end to end.
The moment that proved it worked
We had built a lot of plumbing by this point. The real test was whether the whole chain held under live conditions — a real visitor, submitting a real form, with a real tag being applied, firing a real sync to Brevo, and a real contact appearing in a real list.
We ran the test. The tag was applied manually to a user record in the TnD admin. Within three seconds, the contact appeared in the WAIDN_Central_User_List in Brevo. No manual intervention. No script to run. The module had listened to the tag event, found the Brevo mapping, called the API, and the list updated in real time.
The contact appeared in Brevo within three seconds of the tag being applied. That is the moment the whole product architecture proved itself — not as a plan, but as a thing that runs.
We also confirmed the downstream deletion. Delete a user in TnD → the Brevo contact is removed too. The right-to-erasure loop closes in both directions. That matters legally, but it also matters because it's the right thing to do.
What Track n Dash actually does today
As of v1.6, running live on this site: visitor and user tracking with privacy-safe identifiers, a full tagging system applied manually or automatically via page rules and form submissions, a scoring engine that watches behaviour over time, a rules engine that acts on scores and tags, a Brevo connector that syncs contacts to email lists without manual work, GDPR-compliant per-user delete, a timezone-correct admin dashboard, and a form builder that produces styled, embeddable forms that carry subscriber intent data into the platform automatically.
That is a long list for nine days of build sessions. It exists because we made clear decisions early and stuck to them — modular architecture, privacy-first defaults, and building for the product we wanted to have in two years rather than just the features we needed this week.
What this means for the site — and possibly further
Track n Dash is currently our tool, running on our site. The plan — and it was always the plan — is to use it here first. Test it properly. Build real understanding of how it performs under real conditions. Let the site itself become the proof of concept.
The commercial architecture is already built. The licence-key field is in the database schema. The module loader is designed so that paid modules can sit behind a licence check. The free core and paid module model is the direction — but it is not the rush. We're not launching a SaaS product tomorrow. We're building something worth using first.
What I can say now, nine days and six versions in: I understand exactly how this site's analytics work. I know what every number means, how every identifier is generated, what triggers every tag, and what happens in the database when a visitor accepts cookies and reads an article. That knowledge was the original goal. Everything else — the subscriber pipeline, the automation engine, the eventual product — came from building the right foundations and seeing where they led.
That, honestly, is what building with AI looks like when it's going well. You start with a clear idea of what you want. You make decisions that compound. And somewhere around v1.3 you realise you're building something that is genuinely bigger than the problem you started with.
Track n Dash is documented as it gets built. The decisions, the architecture, the things that didn't work — all of it. Follow the journey below and we'll send you each update as it's published.
