The problem
AI3 set out to build tooling that helped developers work with AI models without wrestling the plumbing every time — the kind of product where the whole value proposition is that it takes something fiddly and makes it feel obvious. As CTO of an early-stage team, I owned the technical direction: what we built, how we built it, and the standard it had to meet before it went in front of users.
The central challenge with developer tooling is that your users are the harshest possible audience. Developers notice everything — a confusing error, an inconsistent API, a slow response — and they abandon tools that waste their time without a second thought. The bar wasn't "does it work," it was "does it feel trustworthy enough that a skeptical engineer keeps using it."
The approach
I made two decisions early that shaped everything. First, I chose deliberately boring, proven technology for the foundation, so our limited energy went into the parts that were actually novel rather than into fighting our own infrastructure. Second, I treated the developer experience — clear errors, consistent interfaces, predictable behaviour — as a feature with the same weight as the core functionality, not as polish to add later.
Day to day, that meant I was hands-on across the stack: designing the APIs, building the parts that were hardest or least rewarding, setting up the deployment pipeline, and owning the unglamorous reliability work that nobody notices until it fails. On a small team the technical lead has to take the load-bearing pieces, and I did.
The stack
The platform combined a service layer for handling model interactions and developer requests with interfaces that made the tooling approachable. I leaned on technologies I could operate confidently and hire against — a proven backend, a relational data layer, and a modern frontend — connected by clean, well-documented APIs. Where AI features were involved, the engineering effort went into making inference feel reliable and the surrounding experience feel calm, rather than into novelty for its own sake.
What it taught me
AI3 was where I learned what technical leadership at an early stage actually is — mostly protecting focus, choosing tools boring enough to forget about, and doing the essential work nobody else wants. I wrote more about that in what a CTO actually does at an early-stage startup.
The lasting lesson was about audience. Building for developers taught me a standard of care I've carried into everything since: assume your user is smart, impatient, and will notice every rough edge — then earn their trust by removing those edges before they find them.