Building Navigator in Public #10: The Last Mile is 90% of the Work
AI Can Build the Interface. The System Still Has to Work
A month ago I had a very serious conversation with myself, and I decided that I needed to pivot for two reasons. Today I want to share one of them.
The S2N Navigator desktop version was a 1 gigabyte zip file that needed to be extracted and then executed for Windows only. Users had to jump through pretty steep onboarding friction that, frankly, for a complex developing product, was too big an ask in my opinion.
So I made the best decision, but it was nothing like I expected given all the AI media hype I have been exposed to. “Just rewrite it for the web” is the easiest sentence to say and the hardest project to ship.
Look at any working desktop application that has been in development for a few years, and you will see the same thing.
A front end with many buttons. Many tabs. Many parameter configurations. Dropdowns inside dropdowns. Checkboxes that change which fields appear. Sliders, ranges, dates, symbol pickers, file pickers.
It looks like a UI problem. It looks like a simple port.
It is not. The buttons are the easy part. The buttons are the first ten percent. AI can rebuild the buttons in a couple of days.
The last ninety percent is where every button is wired to a backend value that used to live on the user’s own machine and now has to live in the cloud somewhere.
That is why I am nearly 4 weeks in and the finish line is still not in site.
What changed when the backend moved
On a desktop, each of those buttons connects to a value through a wire that is essentially free. A function call. A file read. A SQLite query against a database on the same disc. The data is there, or it is not. The latency is microseconds. There is one copy of every file and one process touching it.
In the cloud, the same button becomes a chain.
The form submits. The config is serialised. It uploads to one cloud bucket. A background worker on a second cloud service picks it up. That worker downloads its own copies of the data it needs from a third cloud service. It runs. It writes outputs back. A fourth process notices the outputs and ingests them. A fifth caches the result for fast read. A sixth serves the page that finally shows the user what they asked for.
Every one of those steps has timing. Every one can be delayed or skipped. Every one is a contract between two systems that may have been written months apart by people working in different layers of the stack.
When a user clicks a button on the desktop and nothing happens, the file does not exist. When a user clicks a button in the cloud version and nothing happens, the answer is somewhere in a chain of seven services, each of which has its own logs, its own caches, and its own assumptions about what should already be true by the time it ran.
The data lake is hard like ice
The buttons can be rewritten. The data layer cannot.
A desktop application can rely on a local data store. The user has it or they do not. The dates are what they are. The schema is whatever the application wrote last time.
A cloud application cannot. The data has to be staged into a shared store before any worker can read it. The staging has to run on a schedule. The schedule has to land before the user clicks the button. The schema has to be versioned because workers from different deploys may read it at the same time. The freshness has to be observable because nothing is more demoralising than a fast cloud product giving you stale answers and not telling you.
This is the work that does not show on the screen.
This is the work that takes weeks of decisions about where data lives, who writes it, how often, in what format, with what manifest, and with what retention. None of it is the kind of work a user can see, and none of it is the kind of work that can be skipped.
This is the last mile. And the last mile is the project.
Why the hype gets this wrong
The current AI-coding pitch treats the front end as the product. Ship the buttons fast and call it done.
If your codebase really is mostly a front end, that pitch is fair. Ship the buttons. Move on.
If your codebase is a front end on top of a runtime that has timing, state, schedule dependencies, a data layer that has to be true at the moment of the click, and strategies written on top, you are not shipping buttons. You are re-architecting a system that used to live on one machine to live across a fleet of services, and you are doing it while keeping the buttons looking the same.
That is the actual transition. The buttons are the wrapper. The wiring underneath is the work.
The injection/pill culture
Every shortcut culture sells the same product.
The injection that lets you skip the discipline and lose weight.
The pill that ensures your concentration.
The course that lets you skip the time.
The tool that lets you skip the understanding.
They all work for a while. They all let you avoid the part of the work that the outcome actually requires.
There are no shortcuts to greatness. AI did not change that. AI changed the slope of the work, not its existence.
The founders and trading system developers who win in this era will be the ones who use AI to go further than they could have gone alone, but with an understanding of what and why they are doing. Not the ones who use AI to avoid hard work and have no clue what they have just done.