GEO, AEO and building AI software

What this section is for

Most agency blogs exist to occupy keywords. They are written to a brief derived from a search volume tool, by someone with no first-hand experience of the subject, and they say what the pages already ranking said. They are cheap to produce and, increasingly, worth nothing — search engines are better at detecting the pattern than they were, and assistants composing an answer have no reason to cite a source that adds nothing.

This section is written for the opposite reason. Everything here comes out of work we have actually done or problems we have actually hit, and it is written for the person who will have to implement something rather than the person approving a budget. That means it is more specific than most marketing writing and occasionally less flattering to us.

The practical test we apply before publishing anything: would an engineer reading this learn something they could not get from the first page of results? If not, it does not go up. That constraint produces fewer posts than a content calendar would, which we think is the correct trade.

How the categories are organised

Categories are nested rather than flat, which is a deliberate structural choice rather than an aesthetic one. A parent category covers a domain broadly; its children cover the specific problems inside that domain.

The reason to nest is that it produces genuine topical depth rather than a scatter of unrelated posts. A search engine or an assistant assessing whether a site knows something about, say, multi-tenant architecture is looking at whether the coverage has depth and internal coherence, not whether a single post exists. A parent page with substantial content, linking to children that go deeper, is a structure that communicates that. A flat tag cloud is not.

Each category page carries its own long-form body rather than being a bare list of links, for the same reason this page does. An archive that only lists posts competes with those posts and adds nothing to the site's claim to know the subject.

What we write about, and what we do not

The subjects here follow the work: AI product engineering, SaaS architecture, early-stage product decisions, web and mobile engineering, and the three flavours of search visibility. Where a post covers something adjacent — data protection, payments infrastructure, hiring — it is because that thing turned out to constrain an engineering decision rather than because it was a keyword worth targeting.

What you will not find is news commentary, opinion on the latest framework release, or posts explaining a concept that is already well explained elsewhere. Those get written constantly and read rarely, and none of them are things we would be a useful source on.

You also will not find case studies here yet, because we have not completed engagements we can write up honestly. When that changes, they will appear with real numbers and their measurement windows — and until then, saying so is better than publishing something invented.

How these posts are structured, and why

Every post opens with a direct answer to the question it addresses, placed immediately under the heading, at forty to eighty words. That is not a stylistic preference. It is the format that survives extraction — when an assistant is asked the question a post addresses, that passage is what it has to work with, and a page that buries its answer under three paragraphs of context loses to a worse page that stated its answer sooner.

The same rule applies within a post. Each section answers its heading in its first sentence and elaborates afterwards, rather than building to a conclusion. That reads slightly differently from conventional prose and it makes the content considerably more useful, both to a reader skimming for the part that applies to them and to a machine deciding what to quote.

Passages are written to stand alone. A paragraph beginning with "this approach" or "as mentioned above" refers to nothing once lifted out of the page, so the subject is named inside each passage even where that reads slightly repetitively. That mild redundancy is the cost of being quotable.

Where a post carries FAQs, the visible questions and the structured data render from the same source. Markup describing something a reader cannot see is treated as spam rather than as an error, and maintaining the two separately is how they drift apart.

On being wrong in public

Technical writing ages, and some of what is here will turn out to be wrong — either because we misjudged something or because the ground moved. The convention we hold to is that a post gets corrected rather than quietly deleted, with the correction visible.

This matters more than it used to. Content that is confidently wrong and then silently amended is a pattern both readers and assistants can detect across time, and the cost of being caught at it exceeds the embarrassment of a visible correction. It also matters practically: someone who acted on an earlier version deserves to know it changed.

The related discipline is being explicit about confidence. Where something is well established we say so plainly; where it is our read of an unsettled situation, we say that instead of writing it with the same certainty. Generative search visibility is the clearest current example — the mechanisms are real, the measurement is genuinely harder than in conventional search, and anyone presenting precise figures with guaranteed trajectories is presenting a model as a measurement.

Why we publish at all

The commercial argument for an agency writing publicly is usually framed as lead generation, which is true and incomplete. The more useful reason is that writing something down forces you to find out whether you actually understand it.

A great deal of technical knowledge in this industry is held as pattern recognition — an engineer knows an approach will cause trouble without being able to say precisely why. That works until someone asks, or until the situation differs slightly from the ones that formed the intuition. Writing the reasoning out exposes the gaps, and the gaps are where the expensive mistakes live.

The second reason is that it makes us accountable in a way a sales conversation does not. A position published here can be checked against what we actually do, and a client can hold us to it. That asymmetry is deliberate: an agency whose public writing contradicts its practice is easier to identify than one that says nothing.

The third is more mundane. Questions that arrive repeatedly are better answered once, properly, than repeatedly and briefly. Several of the posts here exist because the same question came up in four separate conversations and deserved a real answer rather than a paragraph in an email.

A note on how this site is built

The structure described above is not theoretical — it is how this site works, and it is inspectable. Answer blocks are word-count checked in development so a passage outside the forty-to-eighty range raises a warning rather than relying on discipline. FAQ sections and their structured data render from one array, so they cannot disagree. Pages are server-rendered, so the substance is in the initial HTML rather than assembled after a crawler has already read the document.

We mention it because the alternative — describing practices we do not follow ourselves — is the most common failure in this category of writing, and because it is checkable. Fetch any page here without executing JavaScript and see whether the content is there.

The measurement problem with technical writing

It is worth being honest that the value of this section is hard to measure, and that the industry has responded by measuring the wrong things confidently. Traffic to a post says little about whether it was useful. Time on page is a weak proxy at best and is frequently just a measure of how long someone hunted for the part they needed.

The signals that actually carry information are less convenient. Whether a post gets referenced by someone who was not asked to reference it. Whether a question stops arriving in conversations after being answered here. Whether an assistant cites the page when asked the question it addresses — which requires running the query rather than reading a dashboard.

None of those produce a chart, which is why most content programmes report on the ones that do. We would rather track fewer things honestly than present a number whose relationship to the outcome nobody can explain.

Frequency, and why there is no schedule

There is no publishing calendar here, deliberately. A schedule guarantees a post exists on a date; it guarantees nothing about whether there was anything worth saying. The predictable consequence is filler, and filler dilutes the material around it — a site of forty posts where twelve are substantial performs worse than a site of twelve substantial posts, because the average quality is what an assessment of the domain reflects.

The alternative is writing when a problem has been solved properly enough to explain, which produces irregular output and better material. It also means the writing follows the work rather than leading it, which is the correct direction for anything claiming to be based on experience.

How to get the most out of this

If you are working on something specific, start from the category rather than the newest post. Each category page carries a substantial overview of the domain, and the posts beneath it go deeper on individual problems within it. That path gets you to the relevant material considerably faster than a reverse-chronological list.

If you are evaluating whether we know what we are talking about before starting a conversation, that is a reasonable use of this section and we would rather you did it. Read something in the area your problem sits in and judge whether it is specific enough to be written by someone who has done the work.

And if something here is wrong, or you have hit the same problem and reached a different conclusion, we would genuinely like to hear it. Most of what is worth writing about came from someone pointing out that the obvious approach did not survive contact with their situation.