How I build

This page is about the method rather than the tools. If you want the tools, they are Salik Optimizer, Layover and SEO Deck, and each has its own write-up. What follows is what is common to all three, drawn from the build sessions rather than the tidy documents written afterwards.

Salik calculates a toll someone will actually be charged. Layover calculates the time by which someone must turn round or miss a flight. In both cases there is no language model anywhere in the path, and in both cases that was written down as a locked decision on day one.

The reasoning is the same each time. A model that is usually right is the wrong instrument for a number with a consequence. When deterministic logic over verified data is wrong, it is wrong in a way you can find, reproduce and fix. When a generated number is wrong, it is wrong in a way that looks exactly like being right.

The cost of the rule is that both tools are less impressive in a demo. Neither has a moment where something clever happens. That is the trade, and it was made on purpose.

• A belief that our pages were invisible to AI crawlers had been approved as a headline feature. Measured, the raw server HTML held 129% of the rendered page’s word count. The premise was backwards and the feature was cut.
• Salik’s gate coordinates were between 0.4 and 3.6 kilometres out, which defeated detection entirely. The input was wrong, not the logic built on it.
• A text colour used for every hint and description failed accessibility contrast at 3.5:1 against a 4.5:1 floor. Found with the real luminance formula, not by deciding it looked a bit light.
• A row of six badges squeezed its own label to zero width. The screenshot looked fine; the element’s measured box did not.
• A tooltip dismissed on hover, which collapsed a banner and shifted every button up a row, landing the cursor on a different button mid-read. Only reproduced in a real browser, because a synthetic click never has a cursor that stays put.

The pattern is that a clean compile and a correct-looking screenshot tell you almost nothing about whether a thing works. So the standard is to exercise the change and check a computed value, and where that is not possible, to say plainly that it is untested rather than imply otherwise.

Salik was pitched as a nudge to shift your driving time and save money. The gap between peak and off-peak is AED 2.10 a crossing, and someone working nine to five crosses at peak in both directions by definition, so the advice reduced to "drive at three in the morning". The saving was real and useless. It became a route comparator instead, which saves the whole charge and is something a person can act on. That reframe deleted about half the planned build.

SEO Deck’s flagship AI-readiness feature was killed by the measurement described above, a feature I had believed in myself.

Layover went the other way and grew. The brief scoped the visa table to the forty most common nationalities, which is a sensible engineering call and a bad product one, because the traveller whose passport is not on the list is exactly the person who most needs the answer and least able to find it. It ships covering every nationality, with anything unclassified defaulting to the cautious answer. An omission in the data can make the tool too careful, never too permissive.

The quote above is how I brief. I had an idea for a scroll indicator and I did not want it taken just because I was the one who said it. If there is a better answer I want the better answer, and my suggestion is the fallback.

The same goes in the other direction. When something looks wrong I stop the work rather than let it continue: "answer, dont do anything" is a real instruction from a real session, given when a change removed an animation I liked and I wanted the reasoning before any more code. Building through an objection is wasted effort, and discussing it costs one message.

I also expect the work to be done rather than handed back to me. "why dont you do it?" is another verbatim one. Anything reachable through a command line or an API should be done, and what genuinely needs a human should come back as numbered steps with the exact path to click, not as a vague instruction to go and configure something.

And I ask to be interviewed. "ask me 5 questions" opened one of the SEO Deck sessions, because the fastest way to a good build is for the gaps in my own brief to be found before the build, not during it.

Salik’s calculator page carried a worked pricing example, sitting directly above the real calculator. I had it moved. Not because it was wrong, but because a worked example next to a live tool invites you to read invented figures as your own result.

The same instinct runs through the rest. Layover once styled a static fallback estimate with a pulsing indicator that read as live data, which was corrected. Salik’s home page map is deliberately decorative and does not pretend to route. And when a tool’s data perishes, as Salik’s toll rates do, the file carries the date it was last checked against source, and it is re-verified before any launch.

It shows up in my own copy too. Reviewing an about page written for one of the tools, I changed a line describing my work from "led" to "managed", because the first was a slightly better word and the second was the accurate one.

One session closed with this instruction: "Update the context files so that I can close the session. Note that I didn’t test the changes made in this session thoroughly." That note is in the project record, permanently, next to the work it describes.

It costs nothing to write and it saves the next session from treating an untested change as verified. The same discipline is why Layover’s project notes still carry its original success criterion, that several people would test the time arithmetic and report it felt trustworthy, marked as outstanding. It has not happened. It stays marked that way until it does, and it does not appear anywhere as an achievement.

Two of these tools exist because I wanted to answer a question nobody had answered for Dubai. The third exists because I manage a content team and the friction they were paying every day was friction I was paying too.

What they have in common is the part that transfers. Deciding what not to build. Knowing where automation belongs and where it is a liability. Keeping perishable data dated. Refusing to show an estimate as though it were a fact. Those are content platform problems before they are engineering ones, and they are the same judgements I make on a content system serving a great many more people than any of these three tools ever will.