A model nobody can reach is a research project. Most of the distance between a working prototype and a product is ordinary platform engineering, and it is usually the part that was not budgeted.
What that involves
- APIs and integration. The service layer between your application and whatever is doing the thinking, with sane timeouts, retries and backpressure.
- Data pipelines. Keeping indexes and knowledge bases current, observably, on infrastructure sized to the workload rather than to the hype.
- Plugin and extension work. WordPress and MCP plugins built to real specifications: scoped permissions, audit trails, recovery points and honest failure modes.
- Multi-platform delivery. Linux, macOS and Windows, including the build and packaging work that decides whether anyone can install it.
- Cost control. Caching, routing and smaller models where they win, so the bill stops being a surprise.
Signals you need this
- A prototype that works and cannot be deployed.
- An integration that fails whenever the upstream service is slow rather than down.
- Infrastructure spend that grows faster than usage.
- A release process only one person can perform.
How the work runs
Smallest thing that can go to production first, then hardening against real traffic. The site you are reading is an example: a custom theme, three purpose-built plugins, an arcade and an MCP integration, all of which I maintain.
Related writing
- Temperature and top-p: controlling how a model gambles
- The context window, and why caching changes prompt layout
Start a conversation
Bring the awkward part. If it is not something I should take on I will say so, and point you at what would help.