Four systems, and what each one taught us

Aggregating vehicle listings across a European market is not a search problem. It is a normalisation problem: sources disagree about what mileage means, what a trim level is called, whether a field is a number or a string with the unit inside it. The interesting work happens before anything is indexed.

The decision that shaped the build was to let ambiguous records fail loudly into a review queue rather than guess. A wrong odometer reading on a car listing is a legal exposure, not a data-quality annoyance, and a pipeline that silently rounds is worse than one that stops.

Growth then turned into a crawl-budget question. At six figures of listing pages, whether pages are server-rendered and how internal links are structured decides how much of the catalogue a search engine ever sees. That is why we default to static and server-rendered output on everything we build, including this site.

The digital dictionary we built for the Bulgarian Ministry of Education is reachable from any school in the country. That single sentence changes every engineering default. Traffic is not uniform; it arrives in a September-shaped spike aligned to a school timetable, and the failure mode is not lost revenue but a teacher improvising in front of a class.

Public-sector work also fixes constraints you do not get to negotiate: accessibility is a requirement rather than a later task, Cyrillic has to be correct through every layer including collation and search, and the client is an institution with a procurement process and change control rather than a product owner in a chat channel.

What it taught us was to design for the low end of the connection and the device, and to treat "works on a nine-year-old machine in a classroom" as an acceptance criterion rather than a nice-to-have. That habit is why performance appears in our proposals as a constraint and not as a phase.

A trading team was answering the same product and pricing questions by email and by Instagram direct message, in two different inboxes, from the same head. The module reads each incoming message, classifies it against the categories the team already used, and drafts the answer from the product and pricing data they already maintain, so the person on the other side edits a draft instead of typing from a blank box. Their measurement, on their own before-and-after: about 85% less manual typing on repeat trading questions.

The decision that made it usable was refusing to let it send. Every reply is approved by a person before it leaves, which caps the worst case at an awkward draft nobody sent rather than a wrong price quoted in writing to a customer. It also makes the economics legible: the running cost of a system like this is the review time, not the inference bill.

The transferable lesson is that the hard part is never the model. It is the category list — the questions a team actually receives, written down as something a human can argue with — and the pricing data existing correctly in one place rather than three. Where both exist, the drafting is the easy fortnight. Where they do not, the model faithfully reproduces whichever version of the price it was shown.

Email-marketing automation for a beauty brand removed roughly 60% of the time the team spent on outreach — their measurement, their before-and-after. We publish it as theirs, because it is theirs.

What made it work was not the automation. It was that segmentation and the trigger conditions were agreed and written down first, in a document of about a dozen rules a human could argue with. The tooling then had almost nothing left to decide, which is exactly the property you want when a campaign goes out to a live list.

The general rule fell out of that project: a process that is broken by hand does not improve when you automate it — it breaks faster, and now nobody is watching. Where the audit says the process is the problem, the correct deliverable is the audit.

On more than one of the four we started building before the baseline existed on paper. It made the early weeks feel productive and it made the final claim weaker, because a delta measured against a remembered number is not a delta. We now refuse to start a build without the before-measurement, even when the client would rather we did not spend the fortnight.

We have also shipped reporting nobody opened. Dashboards are cheap to build and easy to sell, and they are frequently a substitute for deciding what the number is for. The fix we adopted is blunt: no chart without a named person and a decision it changes, and if either is missing we do not build it.

And we treated handover documentation as the last task rather than a running artifact, so it was written by people who had stopped being surprised by their own system. It is now written during the build and validated by a client engineer performing a full recovery from it unaided. That test failed the first time we ran it, which is precisely why it is now standard.

The method we sell now is those four projects with the mistakes removed: measure before touching anything, name the constraint that rules out the obvious fix, build the smallest thing that moves the number, re-measure with the same instrument, and write down what you would reverse.

Each stage carries a stopping condition, which is the part that makes it a method rather than a sequence. A phase that cannot end the engagement badly never had stakes, and a proposal without one is a brochure with dates in it.