Averlo Next Template Journey

At the beginning of this journey, before agent-assisted development, I had little understanding of code templates beyond npx. The primitive version that came before this template was a copy-pastable global.css file, born from repeatedly fixing the same autocomplete input-highlighting issue, page-gutter consistency, and a single button.

Starting Zero Emissions Platform was the first time I kept repeating components and their patterns. It was where the first compositions took shape and, after consulting a solution from my first agent in VS Code, I began to understand the idea of a design system. I realized I could strip the reusable parts out of the project and carry them into every new Next.js project—starting with hovers, buttons, inputs, and text styles already in place. Agents were still poor at UI and maintaining patterns, so the system helped future sites begin consistently.

What became ritualistic next was backporting changes from new projects. First came the component details from 8-ball—input variants, icons, focus states, menus, modals, and buttons. The Argosec security-monitor work that followed sharpened marketing layouts, forms, mobile behavior, animation, and data-heavy interfaces. Then a run of client sites brought content-led sections, reveal and transition work, form protection, multilingual layout edge cases, and more resilient image and visual surfaces. I was simply carrying practical things home once they had survived a real project, until the line between the template and its next projects began to blur.

By May and June, those repeated backports had changed the job of the template. It was no longer only a shared visual starting point; Payload readiness, isolated previews, image and reveal work, template intelligence, thin-start tooling, and the public launch were turning it into infrastructure that could travel with a project. This was also a period of testing ideas about how that infrastructure should work. Markdown made sense as the underlying asset for a rendered document page—shareable, lightweight, and easy to extend with configurable notation. As more work involved reading and revising it, it became a natural candidate for content pages—not a universal replacement for rich text, but a practical, versionable option where the content model stays clear. I also tried applying autoresearch to performance work, using measurable scores to find out whether a change actually improved the result rather than merely looking more sophisticated. The orchestration dashboard began in the same spirit: an attempt to make project-building scaffolding visible and autonomous that gradually grew into an overbuilt form of template documentation.

Once the template had enough of these pieces, I tried to see whether they could work as one system instead of a collection of useful additions. That was the most ambitious period: dashboard work, authentication, entities, mutations, inference surfaces, evidence policies, and service assembly were all pulled together at once. It created a real peak of momentum, but it also made the template harder to read. Every new capability brought another decision, another dependency, and another way for a fresh project to inherit more than it needed.

The final phase was about reversing that direction without throwing away what had been learned. Positive assembly meant choosing the capabilities a new project should start with, rather than carrying every capability forward by default. Clarifying ownership and documentation, selecting content more deliberately, and measuring the remaining scroll work were all ways of making the template simpler to enter, less bloated, and more useful as a high-quality product.

Working on Inference Harness MVP later challenged the design side of that system. I started from an existing agent harness, which meant working within another design system instead of my own and moving away from the patterns I had built into the template. During implementation, I became frustrated when I could not organize everything neatly without making exceptions. That frustration led me to a blog about Linear’s redesign, where I began to recognize how much I had been forcing organization onto my own template. Local exceptions are a normal part of design when they serve the user experience. I had been prioritizing consistency and tidy structure over what an interaction actually needed, and the result was a template that felt robotic. The lesson was not to abandon the system, but to let UX take priority and allow the system to bend around it.