The Why

Over the past few months I've been doing a lot of thinking, talking with our team, and experimenting with new AI tools. This essay is the outcome of that reflection. My focus has been on how these technologies don't just change what we build, but how we build - and how our organisation itself needs to evolve.

This connects directly to the strategic choices we’ve been making at Calcs.com: building data advantages through partnerships, pushing our product to be faster and smarter, and ensuring we can scale before competitors catch up. We are in a race. Incumbents are slow and vulnerable right now, but new entrants are coming fast behind us. If we don't reconfigure how we work while we are still flexible enough to do so, we risk being overtaken.

I'm writing this for two reasons. First, because speed is not optional - it is the only way to stay ahead of the wave that is coming, whether it breaks this year or the next. Second, because if we want to build and productize these capabilities for our own customers, we need to embed them in our DNA. Otherwise it's lip service.

So I've been asking myself a simple question: if I were starting Calcs.com from scratch today, how would I build it? And as we prepare for our next wave of scale, how do we take a deep breath now, while we are still nimble enough, to reconfigure for that future?

This essay is my attempt to answer that.

What Small Teams Are Showing Us

Much has been said about the idea of a billion-dollar single-person startup. While no one has yet reached that milestone, it is no longer a fantasy. Teams of two or three are already generating millions in annual recurring revenue by weaving AI agents and automation into their workflows.

They are not succeeding because they've discovered the perfect tool. They are succeeding because they've adopted a new philosophy: think deeply once, codify the solution, and let the machine execute it endlessly.

It's the same principle as management delegation. A leader clarifies a problem, sets goals, and empowers others to execute. With AI, the "others" are no longer just people - they're agents. Every solution becomes reusable, scalable, and continuously refined, creating a compounding loop of productivity.

Learning Speed Is the New Advantage

In traditional organisations, product managers translate customer needs into requirements, which developers then execute. This process is slow and brittle, as anyone who has seen the classic "swing meme" knows: what the customer asked for rarely survives the long journey through layers of translation and documentation.

But AI collapses that distance. A subject matter expert can now describe a problem directly to a system like Lovable, test iterations instantly, and learn in hours what used to take weeks. It isn't that they are necessarily getting it right the first time, they're just seeing a swing with three rungs and iterating to a tyre swing before paying for the rollercoaster.

This is why we're seeing the explosion of multimillion-ARR startups built on Lovable: subject matter experts no longer need to wait for developers to prototype their ideas. They can execute themselves, and if they've explained it poorly, they find out in minutes, not weeks.

The same dynamic applies to engineering. This is the power of our Calcs Builder - by putting the ability to create calculators directly into engineers' hands without needing code, we give them the same leverage. Instead of waiting on software teams or building fragile spreadsheets, engineers can instantly codify their expertise into repeatable tools. If the logic isn't right the first time, they can fix it themselves and see the impact immediately.

Just like founders using Lovable, engineers can now iterate in hours instead of months - capturing their judgment once and letting agents or teammates reuse it at scale. That shift is what will separate the next generation of engineering firms from incumbents still trapped in slow cycles and manual workflows.

Here's the metaphor that matters: imagine if you could use ChatGPT, but were only allowed to send one prompt per week. It would be maddeningly slow, and neither you nor the model would ever improve in any meaningful way. Yet this is exactly how conventional software development still works: meeting customers infrequently, deploying once a week, and giving ourselves only a single "prompt" to learn from.

LLMs are powerful not because they get everything right the first time, but because they allow relentless iteration. Each prompt builds on the last, creating a compounding cycle of learning. That is the philosophy we must adopt as a business. Our systems (through continuous deployment) and our processes (through rapid feedback) must enable the same loop: constant prompting, constant correction, constant acceleration.

To illustrate: if we move from deploying once a week to once a day, we give ourselves 7x more learning cycles in a week, 30x in a month, and hundreds of times more in a year. This is how new companies are being built today. If we don't emulate that pace, the gap will quickly become unbridgeable.

Execution is now cheap. Learning speed is the real competitive advantage.

How Roles Must Change

If speed of learning is the true advantage, then anything that slows the loop becomes a liability. Historically, the product manager sat in the middle of the process, translating customer problems into requirements and protecting developers' time. That made sense when execution was expensive - you wanted to get it "right" on paper before investing weeks of engineering work.

But in today's world, translation is no longer a safeguard - it's a bottleneck. Re-explaining what a customer said to a developer creates lag and distortion, and room for error and misinterpretation. And when execution is nearly free, the cost of that lag is enormous.

Here's what changes:

1. SMEs and PMs can push right into technical execution. With tools like Lovable, the people closest to the problem can now test solutions directly.
2. Execution is cheap, so specs are counterproductive. It's faster to prototype and discuss than to write and translate.
3. The translator role becomes a blocker. Every re-explanation starves us of learning cycles.
4. Developers must move left, toward customers. With coding costs collapsing, the bottleneck is now judgment — what's feasible, what's MVP, what architectural decisions might create long-term performance issues and whether we are happy to accept that. Developers need firsthand context, not filtered requirements.
5. PMs move up to strategy. Their value is in setting direction: which customers and problems matter, and how to avoid becoming a feature factory.

This is why new companies are outpacing incumbents. They aren't shielding developers from customers - they're putting developers at the coalface of iteration. Customers can "prompt" developers directly, and developers bring the technical judgment to decide what's viable. The result is richer, faster learning loops, and compounding advantage.

This shift also reshapes the role of design. When execution is expensive, design's job is to anticipate every detail up front - every pixel, every state - because changes later are slow and costly. But when execution is cheap and fixes are immediate, the emphasis changes.

Design becomes about patterns, reusable systems, and the specifics of customer journeys that can support rapid iteration without chaos. It matters less if a single screen drifts slightly in one release, so long as the underlying patterns and design system keep the product coherent. Rather than obsessing over pixel-perfect designs upfront, designers become stewards of coherent systems (design systems, UI patterns) that enable rapid experimentation while developing deep understanding of our specific customers. Their value shifts from crafting perfect screens to creating frameworks that make ongoing iteration possible and beautiful.

Working With Agents As Teammates

The bigger opportunity is to treat agents as teammates. Imagine every repetitive task we face- summarising support requests, updating tracking plans, pulling analytics, drafting experiments -handled by an AI agent. Humans remain in the loop, but as supervisors: setting direction, reviewing outputs, and focusing energy on strategy and creativity.

The progression is simple:

1. Start small, with microtasks - the smallest 10-minute thing you can automate.
2. Move up to supervised workflows, where agents act as juniors you review.
3. Layer into autonomy, where agents manage full processes with guardrails.

Smaller agents (those tiny tasks), are initially reviewed and curated by you. Then you codify how you do that review (a supervisor), then you review those supervisors. Over time, you work out what regular steps you're taking, and you codify those too. Each time, you tweak a step or add a small layer. Over time, ironically, this can come to look like an org chart.

This mirrors the situational leadership model we already use with people: first directing, then coaching, then supporting, and finally delegating. Good managers know that it is a fools errand to go directly from directing to delegating ("your problem now, have fun!"). This isn't delegating, this is abandoning, and you should not be surprised with poor results if you failed to explain and build up capability over time (and iterations). These same principles should guide how we build confidence in agents.

Done right, this builds a flywheel: each solved problem becomes a reusable agent, freeing humans for higher-level thinking. Over time, the organisation compounds momentum instead of repeating effort.

Why Incumbents Will Fail

Here's the hard truth: incumbents are at enormous risk. They are weighed down by slow release cycles, rigid product trios, and ever-growing teams. Meanwhile, AI-first startups are scaling lean, keeping context tight, and compounding knowledge every single day.

That compounding creates a tsunami effect. These firms are not repeating yesterday's work - they are stacking progress into reproducible systems, accelerating daily, and building momentum that will sweep away slower competitors.

If we continue to operate as though people are our only lever of capability, we will remain capped by headcount. If we reconfigure around agents, we uncap that limit.

The same risk applies in consulting. A small firm with engineers using agents and shared calculators can deliver the output of a much larger team, while incumbents stuck in manual workflows and spreadsheets will be left behind. It is up to us to equip our customers with these tools and understanding.

Culture: Curiosity or Bust

This transformation is not optional. Every new hire, every leader, every team member must come with curiosity and a willingness to engage with AI. Dabbling is not enough - we need people who see agents as part of their daily toolkit.

We do not have time to drag along those who resist. Incumbents will die slow deaths because they are staffed with people who said no to change. We cannot afford to be among them.

The Call to Action: Iteration as Our DNA

This is not a moment for fear but for urgency. The companies that thrive in the next decade will be those that embrace agents and AI as core members of their workforce. For us, that means adopting the mindset that makes LLMs so powerful: relentless iteration.

Just as ChatGPT becomes useful only when it receives constant prompts, corrections, and refinements, our business must be designed the same way. Every deploy, every customer interaction, every documented process is another "prompt" in our loop of learning. The more cycles we run, the faster we improve, and the more unbridgeable the gap we create over slower competitors.

That requires:

• Thinking deeply once, codifying solutions, and letting machines repeat them.
• Hiring and growing people who are curious, adaptable, and eager to experiment.
• Treating agents as teammates, trained through directing → coaching → supporting → delegating.
• Embedding continuous deployment and rapid feedback loops so learning happens constantly, not occasionally.
• Reimagining roles: product managers as strategists, developers as product-minded executors, designers as workflow pattern builders.
• Building a culture that prizes iteration speed over perfection.

The future belongs to those who learn the fastest. Competitors are already shortening their loops to daily or even continuous cycles. If we blink, they will already be ahead. Our challenge, and our opportunity, is to reconfigure how we work today, so that tomorrow we are the ones setting the pace.

This is how we’re thinking about building Calcs.com for the AI era. If this way of working excites you - whether as a teammate, partner, or investor - I’d love to hear from you.