I Stopped Building Software. I Started Conducting It.

There is a strange feeling that comes with building a technology company today. For most of my career, building software meant sitting in front of a computer and turning an idea into something real, one decision, one feature, one frustrating technical problem at a time.

Today, I increasingly feel less like a software developer and more like the conductor of an orchestra. Except my orchestra doesn't sleep.

There are agents working on different parts of the business. Some are designing interfaces. Others are solving engineering problems, reviewing architecture, testing functionality, researching opportunities, or improving the product. Each has its own capabilities, context and responsibilities.

My job is becoming less about producing the individual notes and more about ensuring that everything comes together into something worth listening to. And that's an extraordinary shift.

I'm no longer just building a product. I'm growing one.

From writing code to conducting intelligence

The traditional image of a founder building a technology company is someone working ridiculous hours, writing code, hiring developers, raising money and trying to get something into customers' hands before the runway disappears. That model has shaped the startup world for decades.

But the economics of building software are changing so profoundly that I think we're still struggling to comprehend the implications.

When execution was expensive, a founder's primary constraint was the amount of work they could afford to have done. You had to prioritize ruthlessly. Every feature represented engineering hours, salaries and opportunity cost.

Today, with sufficiently capable AI agents, the constraint is moving somewhere else. I can have multiple agents working on different aspects of a product simultaneously. They can investigate problems, propose solutions, implement features, review one another's work and progressively improve what already exists.

My bottleneck is increasingly the amount of work I can meaningfully review, approve, redirect and absorb. I've started thinking about productivity in terms of completed, verified work per minute of human attention.

Not lines of code. Not commits. Not the number of agents running. Actual work, completed to an acceptable standard, relative to the human attention required to make it happen. That's a very different way to think about building a company. And it has changed almost everything about how I'm approaching Topolo.

The freedom to build in the dark

One of the most repeated pieces of startup advice is to build in public. Share your progress. Launch early. Find users. Listen to feedback. Iterate.

And, historically, there have been excellent reasons for doing that. When building software was expensive, you couldn't afford to spend two years creating something nobody wanted. The minimum viable product became a way of reducing risk. Build the smallest thing possible. Put it in front of customers. Find out whether anyone cares.

But what happens when the economics underlying that advice change? What happens when, in the time it once took to build a traditional MVP, you can now build something substantially more complete? Not just a prototype or a convincing interface. A real product, with the architecture, design language, workflows, integrations and operational capabilities you originally envisioned.

I've increasingly come to believe that launching early isn't always the right answer anymore. Sometimes, the most valuable thing you can do is give an idea enough room to become what it was supposed to be.

That's largely how I've approached Topolo. I've made a few admittedly half-hearted attempts to build in public. I've shared things here and there, talked about what we're doing and shown glimpses of the platform.

But the truth is that I've spent most of this journey building in the dark. Not because I don't want feedback. Not because I believe I know everything. But because I wanted the freedom to develop a coherent vision without having every decision influenced by the immediate demands of an external audience.

The MVP was a response to scarcity

There's an important distinction here. I'm not arguing that validating demand is unnecessary. You can build an extraordinary product that nobody wants, and AI doesn't magically solve that problem. I'm arguing that the MVP was, in large part, a response to the scarcity of execution capacity.

When you had six months of runway and three engineers, the sensible thing was to prove the essential hypothesis before attempting anything ambitious. But if the cost and time required to build the product fall dramatically, that calculation changes.

You can afford to explore more deeply. You can revisit architectural decisions. You can build the supporting systems that would previously have been postponed indefinitely. You can take design seriously from the beginning rather than promising yourself you'll fix it after the next funding round.

Most importantly, you can avoid having your product's fundamental direction shaped prematurely by a handful of early customers. Because customers don't necessarily see the product you're trying to build. They see the problems they're experiencing today. And understandably, they want you to solve those problems.

That feedback is valuable. But it can also pull a company in a hundred directions before its underlying vision has had the opportunity to mature. The result is often a product that becomes increasingly useful to its earliest customers while becoming less coherent as a whole. I've wanted to avoid that.

Picasso didn't invite the world to review every brushstroke

I sometimes think about how strange it would be if we applied contemporary startup advice to an artist. Imagine Picasso stopping every few hours to publish an unfinished painting, asking an audience what they thought, and making changes based on whichever comments received the most engagement.

Perhaps the painting would become more commercially appealing. Perhaps it would become something nobody disliked. But would it still be the painting he intended to create?

Of course, software isn't a painting. Software evolves. It interacts with the world. It has to function. And unlike a finished canvas, a software product is never truly complete. But I think there's something important in the analogy.

A product needs an underlying point of view. An architecture. A design philosophy. A coherent understanding of the world it intends to serve. And sometimes those things require a period of concentrated development before they're ready to withstand the influence of the market.

For Topolo, I wanted to reach the point where the core architecture, experience and worldview had become sufficiently mature that customers could help us improve the product without fundamentally redefining what it was. Not finished. Just unmistakably itself.

Building a business platform, not another collection of tools

My vision for Topolo has never been to build another CRM, another task manager or another AI chatbot. There are already plenty of those.

I've wanted to build an environment where the applications a business needs can work as parts of a coherent whole. Where identity, permissions, data, workflows and communication aren't endlessly recreated or awkwardly stitched together. Where businesses can move from an idea to an operational system without spending months assembling disconnected software.

And increasingly, where AI agents can do meaningful work across that environment rather than simply offer suggestions from the sidelines.

That's a much more ambitious undertaking than building a narrow SaaS application. It also requires a level of architectural consistency that is difficult to preserve if every early customer request becomes an immediate priority.

So I've given myself permission to build differently. To establish the foundations. To experiment. To discard things that don't meet the standard. To revisit decisions that felt right six months earlier but no longer make sense. And to keep pushing towards the version of Topolo that I've had in my head, even as that vision continues to evolve.

The product has become my own operating environment

Perhaps the most interesting development is that Topolo is becoming an increasingly useful asset for running Topolo itself. That might sound circular, but I think it's one of the strongest ways to develop business software.

We use the platform to organize objectives, manage commercial activity, create documents, develop customer experiences, coordinate work and review outcomes. As the capabilities improve, I find myself able to delegate increasingly complex pieces of work to AI agents operating across those applications.

That changes my relationship with the product. I'm no longer simply asking, "What feature should we build next?" I'm asking, "What could this platform accomplish for the business if I gave it an objective and the necessary context?"

That question exposes very different problems. It's no longer enough for an application to look good in a demonstration. It has to produce useful results. An agent creating ten mediocre assets isn't ten times more productive than someone creating one excellent asset. An automation reporting that it checked something isn't the same as an automation accomplishing something.

And a system that requires constant human intervention to make progress isn't particularly autonomous. These are the kinds of lessons that become obvious when you're genuinely trying to operate your own company through the software you're building.

It's also why I'm increasingly interested in long-running objectives rather than isolated tasks. Give an agent a meaningful goal. Let it break that goal into milestones. Allow it to work across multiple sessions, preserving context and evidence. Have it verify what it has accomplished and continue until the outcome meets the required standard.

Then imagine ten, twenty or a hundred such workstreams progressing in parallel. That's when the conductor analogy starts to become particularly interesting.

The orchestra is getting bigger

I don't think the future belongs to the founder who can personally write the most code. Nor necessarily to the company with the largest engineering team.

I think an increasingly important advantage will be the ability to direct, coordinate and evaluate enormous amounts of intelligent execution. A founder with a clear vision, good judgment and the right systems may be able to accomplish things that previously required an organization of considerable size.

But that doesn't mean the human becomes irrelevant. Quite the opposite. Taste matters more. Judgment matters more. Knowing what is worth building matters more.

The ability to recognize when something is mediocre, even when an AI system confidently declares it complete, matters enormously. An orchestra of exceptionally talented musicians can still produce a terrible performance without a shared interpretation of the music. The same is true of agents.

More agents don't automatically produce a better company. They amplify the quality of the direction they're given.

What happens when we finally open the doors?

I don't believe Topolo needs to be perfect before people start using it. It won't be perfect. And I'm certain that customers will reveal weaknesses, assumptions and opportunities I haven't anticipated.

But I wanted the people who eventually invest their time in Topolo to encounter something that feels like a considered product rather than a collection of experiments.

I use the word invest deliberately. Even when software is inexpensive, adopting a new platform is an investment. Customers invest time learning it. They invest attention configuring it. They may invest operational trust, business processes and important data.

In return, the platform needs to earn that investment by producing meaningful results. Not merely by having an impressive feature list. Not by promising that AI will somehow solve everything. But by helping people and businesses achieve things they couldn't previously achieve as effectively.

That's the standard I want Topolo to meet.

From vibe coding to vibe business

We've spent the last few years watching people discover that they can build software by describing what they want. It's extraordinary, but I think it's only the beginning.

The more interesting question is what happens when that same capability extends beyond writing code. When you can describe the business outcome you want, and intelligent systems can organize and execute the work required to achieve it. When the software isn't simply something you build. It's something you operate alongside. When the platform becomes capable of helping to grow the company using it.

That's the direction I see things moving. From vibe coding to vibe business.

And perhaps that's why I've become comfortable spending so much time building in the dark. I'm not particularly interested in winning a race to launch the smallest possible version of my idea. I'm interested in finding out how far the idea can go when execution is no longer the constraint it once was.

I still have an enormous amount to learn, and there's a difference between what I believe this model can achieve and what we've actually demonstrated. But for the first time in my career, the distance between an ambitious idea and a working system feels dramatically smaller.

I'm conducting an orchestra that keeps getting more capable. I'm growing a product that is increasingly helping me grow the business around it. And somewhere in the middle of all that, I think we're discovering a fundamentally different way to build companies.

Not by removing humans from the process. But by making human imagination, judgment and attention go further than they ever could before.