How I Use AI Agents to Keep Blue Fast for 19,000 Organizations

Blue started as a side project inside my previous company. I built it to manage the company’s projects. Today, it is a process management platform that powers more than 19,000 organizations.

I take that responsibility very seriously.

In 2025, I made the decision to go from a team of around ten people to operating Blue with me as the solo founder. Since then, I have thought very consciously about how to structure the work, how to use AI, and how to use monitoring and telemetry to maintain world-class engineering quality with an incredibly efficient operation.

Some venture-backed companies in Blue’s category have several thousand employees while serving perhaps ten or twenty times Blue’s customer base. Blue is an extreme experiment in the other direction: how can one person manage a large customer base across engineering, support, marketing, and everything else?

For performance, the question is simple: how does a solo founder keep a platform used by 19,000 organizations consistently fast?

Speed is part of the product

Reliability and speed are two of Blue’s most important features. They are integral to product quality.

You do not notice them much when everything is working. You notice immediately when it is not.

People spend a lot of time in Blue. An average user may spend several hours of the day adding comments, reviewing work, updating records, and running reports. A slow interaction is not merely a technical metric. It is repeated frustration throughout someone’s working day.

It also communicates something about the company behind the product. When software becomes slow or unreliable, customers can reasonably wonder whether the company has stopped caring.

I cannot hand performance to a dedicated department. I have to consider it myself. That creates pressure, but it is also freeing. Everything is my responsibility. There is no communication overhead and no blame game. If something is not good enough, there is nobody else to blame. I can understand it, take accountability, and improve it.

Why performance became the priority after V2

In 2026, I rewrote Blue’s frontend from Vue 2 to Vue 3 and shipped a large number of new features. V2 became the product I had always wanted Blue to be.

Getting there created an awkward period. I was maintaining V1 while V2 was available as an open preview, finishing the new product while still preserving backwards compatibility with the old one. At the same time, Blue’s usage increased by roughly six times during the first two quarters of 2026.

I did not want to delay the V2 launch in pursuit of perfection. Launching meant I could stop carrying the full weight of V1 compatibility and concentrate on one product.

Once V2 had been live for several months, the balance changed. I did not stop building functionality, but I took my foot off the new-feature accelerator and put more attention into polish, reliability, and speed.

Some of that work was architectural. I moved Blue from Redis to Dragonfly and introduced dedicated in-memory caching for Pro and Enterprise customers. Certain cache-backed operations can be hundreds of times faster than repeatedly reaching into the database.

But new infrastructure alone does not prove that a product feels fast.

A sophisticated architecture can still have slow paths

Blue already had a sophisticated frontend cache that I built from scratch. It loads data in phases, keeps durable data in IndexedDB, moves heavy work into Web Workers, and refreshes records in the background. I believed the architecture was strong, partly because I use Blue every day.

Then I dug deeper into the telemetry.

Across normal successful board loads, production monitoring showed a p95 useful paint of approximately 3.6 seconds. It recorded 7,508 long main-thread tasks on boards in one day, with a p95 of 675 milliseconds and individual freezes reaching 13.3 seconds. Other views showed rare events lasting far longer.

The problem was not that the architecture was fundamentally wrong. It was that some customers have data structures very different from mine: 10,000 or 50,000 records, sometimes considerably more, with large numbers of complex custom fields and uneven relationships.

At those sizes, innocent-looking work changes character. Reading an entire IndexedDB partition in one operation can freeze the browser while it clones the data. Applying thousands of small worker batches can repeatedly recalculate the same board. Looking up custom fields by scanning every returned row for every record can turn a linear operation into a quadratic one.

I did not feel any need to defend the existing design. Good engineering is not proving that your previous decisions were perfect. It is understanding how the product behaves now, under real customer workloads, and improving it.

Performance is part of Blue’s economics

Blue no longer runs on metered public-cloud infrastructure. As part of the V2 work, I moved its application servers, databases, email infrastructure, telemetry, and other systems onto dedicated servers in Germany. Leaving the cloud saves Blue more than $100,000 per year and has helped raise its gross margin above 90%, the highest it has ever been.

That means a faster query does not necessarily reduce this month’s server invoice. The capacity is already there.

Instead, performance work lets me sweat the existing infrastructure. If each request uses less CPU, examines fewer database rows, transfers fewer bytes, and occupies resources for less time, the same fixed infrastructure can support more customers before it needs to expand.

Performance also affects revenue. A fast, reliable product is more delightful to use. Customers use it more, recommend it, expand their usage, and upgrade.

This is closely connected to Blue’s unusual business model. Customers can buy Blue through a permanent lifetime plan, with an optional Pro subscription for more advanced requirements. That only works because Blue has very high gross margins and low operating costs. Better engineering efficiency gives me room to keep passing savings on to customers while maintaining a strong business.

I do not see bootstrapped constraints as a disadvantage. They encourage better architecture.

From one benchmark to a reusable skill

I began the concentrated performance work with record loading. As I created the first benchmarks, I noticed the same process repeating.

First, define the user operation. Form a narrow hypothesis about the wasted work. State what behavior must remain unchanged. Build a representative harness. Measure the untouched baseline more than once. Make one focused change. Run the same measurement again, including scenarios that might oppose the optimization. Then decide whether the improvement is worth the complexity it adds.

After several investigations, I thought: this should be a skill.

In the major AI-agent tools, a skill is usually a structured Markdown file containing instructions. It can also include scripts, reference material, templates, and other resources. I treat these skills like code: they are version controlled, reviewed, and improved whenever I discover a weakness in the process.

The important part is that the performance skill does not dictate exactly how to build every benchmark. It describes the approach and the evidence required.

For a frontend question, an agent may build a production browser journey and measure first useful paint, long tasks, and blocking time. For a database question, it may use real MySQL, inspect the query plan, and count rows examined. For a network question, it may measure round trips and bytes. For in-memory hydration, it may benchmark CPU work and allocations across several data shapes.

The implementation is flexible. The standards are not.

The output must remain correct. Permissions, ordering, errors, empty states, and side effects must be preserved. The baseline and candidate must use the same harness. Median and tail latency must be reported. Regressions and neutral results cannot be hidden. A microbenchmark cannot be presented as proof that the entire product became faster.

The skill is less like a recipe and more like an engineering constitution. It tells the agent how to reason about evidence without pretending that every layer of a modern application can be measured in the same way.

Running the work in parallel

I run the agents through a tool called Paseo on a separate server with 128GB of RAM. That server costs roughly $120 per month. Buying an equivalent high-memory development Mac would cost me around $8,000.

More importantly, the remote server allows me to run five or ten agents at the same time without tying the work to my laptop. Codex, Claude, and GLM-5.3 can all work in the same repository because the setup, scripts, skills, and engineering context live with the code rather than inside one particular model.

At first, running multiple agents made my brain melt. Then I learned to give each agent narrow, distinct work in its own environment and worktree. An agent can work independently for twenty minutes, an hour, or longer, and notify me when it has produced something worth reviewing.

Because the work runs remotely, I am not stuck at my desk. I can start several investigations, go to the gym or take a walk, and check their progress from the Paseo app on my phone.

When an agent opens a pull request, another advisory agent reviews and criticizes it. A subsequent pass can address that feedback and verify the result again. I still decide what ships, but much of the mechanical investigation, implementation, and first review is already complete when the work reaches me.

For this kind of engineering, that can create a ten- or twenty-fold improvement in my productivity. The deeper Paseo workflow deserves its own article. For this story, the important part is that parallelism only works because every agent follows the same evidence standard.

What improved

From August 18 to August 23, 29 performance-related pull requests landed on Blue’s main branch. They covered the browser, IndexedDB, Web Workers, API hydration, payload sizes, network delivery, database queries, virtualized rendering, and pagination.

Here are several representative results:

These numbers cannot be combined into one claim that “Blue is 99% faster.” They measure different layers with different harnesses.

That distinction matters. The custom-field result is remarkable, but it isolates one backend assembly step. The cold-board result is a smaller percentage, but it proves that a user saw the first card roughly half a second sooner in a full production-build browser journey.

Some optimizations save only a few hundred milliseconds, or even a few milliseconds. Blue’s databases handle more than a thousand queries per second on average. Work repeated thousands or millions of times compounds. Reducing a small amount of CPU or database work in a hot path can create meaningful capacity across the system.

Honest measurement changes what ships

Every optimization has a maintenance cost.

If a change makes one operation 10% faster but adds 10,000 lines of brittle code, I will probably reject it. If a critical path becomes five times faster, I may accept more complexity. The point of the process is not to maximize benchmark percentages. It is to make an informed engineering trade-off.

The performance skill explicitly requires agents to report neutral results, regressions, and new costs. One popup optimization deliberately changed one HTTP request into two parallel requests so core content no longer waited for activity. A record-limit index made a large read dramatically faster while adding a small amount of write overhead and consuming additional storage. Another hydration optimization introduced a regression of less than two microseconds for tiny batches while substantially improving large ones.

Those are not embarrassing footnotes. They are the information needed to make the decision.

AI agents are very capable of producing plausible optimization work. Without a disciplined harness, they are equally capable of making a function appear faster while moving the work elsewhere, changing behavior, or optimizing something irrelevant. A disproven hypothesis is more valuable than an impressive result produced by an invalid benchmark.

Turning judgment into a system

I am beginning to turn almost everything I do repeatedly into a skill.

As a solo founder, I cannot keep every operational lesson in my head. With a version-controlled skill, I can ask an agent to investigate a particular area and know that it is following a pattern I have already used thirty or fifty times. When an investigation exposes a weakness in the method, I improve the skill. That improvement can then apply across different models and for years into the future.

I have followed a similar journey in customer support. In January 2026, I was personally answering 150 to 200 emails per day. Roughly 90% of that workflow is now automated, while difficult cases still receive human judgment. That deserves a separate explanation of its own.

Performance may eventually work continuously too. I can imagine agents investigating the product around the clock, opening ten or fifteen narrowly measured performance pull requests overnight, and leaving me to review the evidence and confirm that behavior has not regressed.

The long-term target is simple even if it can never be reached perfectly: get as close as possible to the raw time required to retrieve the correct data and return it to the user. There will always be physical limits, including network distance and the speed of light. Everything above those limits is a candidate for understanding.

The point is still the product

All of this is technically interesting, but the objective is not to operate an impressive collection of AI agents.

The objective is to make Blue a fantastic product.

Most of Blue’s new revenue comes from existing customers upgrading and from word of mouth. Product quality is therefore inseparable from growth. Speed and reliability make customers more confident in placing more of their work inside Blue, recommending it, and paying for more advanced capabilities.

I believe AI has made software engineering ten, twenty, and sometimes even fifty times more productive. The opportunity is not merely to ship more software at the old price. It is to pass a meaningful part of that productivity gain on to customers while still building a highly profitable, durable software company.

The biggest leverage does not come from asking an agent to write code faster. It comes from turning good judgment into a system that can be reused, measured, criticized, and improved.

— Manny