Startup Theatre and the Illusion of Progress

There is something increasingly strange about the way people start startups today. The barrier to producing software has fallen so dramatically that someone can have an idea in the morning, spend a few hours prompting an AI coding tool, have something that looks like a product by evening, buy a domain, generate a logo, put together a landing page, change their LinkedIn headline to “Founder & CEO,” and announce to the world that they have launched a startup. The announcement gets a few congratulations, someone asks whether they are raising, another person offers to make an introduction to an investor, and suddenly there is a feeling of momentum.

But what actually moved?

This is a phenomenon I eventually termed "startup theatre." It is the production of all the visible artifacts associated with entrepreneurship without necessarily doing the difficult work that makes those artifacts meaningful. The pitch deck exists. The MVP exists. The company name exists. The LinkedIn announcement exists. The architecture diagram exists. The landing page exists. What may not exist is a compelling problem, a validated customer, a viable business model, a defensible product, or sometimes even a clear explanation of what the product is supposed to do.

That distinction matters because activity and progress are not the same thing. You can spend weeks doing things that look like startup work without actually reducing much uncertainty about whether you have a business.

I am a software engineer, so I have no problem with the fact that AI has made software dramatically cheaper and faster to produce. In fact, I think it is fantastic. I can take an idea, form a mental model of how I want the system to behave, and turn that model into working software much faster than I could have done years ago. AI can accelerate that process even further. Someone with enough technical understanding can describe a feature, generate an implementation, inspect it, correct it and keep moving. Someone with much less technical experience can sometimes get surprisingly far by repeatedly prompting an AI coding system until something appears to work.

The problem starts when people confuse the ability to produce software with the ability to build a company.

The software is only one component of the company. Once real people start using it, reality starts asking much more uncomfortable questions. What legal entity is responsible for the product? Are the founders personally exposed? What contracts govern the relationship with customers? What data are we collecting and what obligations arise from collecting it? Is the product or any of its functions regulated? Does it require a license or a regulated partner? What happens when the software makes a consequential mistake? Who carries the liability? What happens when the company gets breached? What security controls do we actually need? What happens when a customer loses money? What happens when a regulator asks questions?

Then there are the commercial questions. Does a market actually exist? Who has the problem? How do they solve it today? Why would they switch? Why would they pay? How much would they pay? How do we reach them? What prevents someone else from copying the product? And now that AI has made software so cheap to reproduce, what prevents somebody who needs the same thing from simply vibe-coding their own version?

The questions are endless, and some of them require real professional depth to answer. A founder might need a lawyer, an accountant, a security professional, a regulatory specialist or someone with deep industry experience. Sometimes the founder can learn enough to handle the issue themselves. Sometimes they need to know when they have reached the boundary of their competence and bring somebody else in.

AI has dramatically reduced the cost of producing software. It has not dramatically reduced the cost of being responsible for software. That is the part I think gets lost in the current excitement around vibe coding.

The founder title can become the product

There is another phenomenon underneath all of this that I find even more interesting. Some people seem to want to become founders before they have found anything worth building.

The sequence becomes, “I want to start a startup,” followed by, “What can I build?” They then go looking for a problem that can justify the startup. Once they find something that sounds sufficiently important, they can construct a solution around it, generate some market research, produce a product specification, build an MVP and eventually announce themselves as a founder.

The problem should come first. The desire for a founder title should not.

When the identity comes first, it becomes very easy to manufacture problems. Someone decides they want to build a fintech company, so they start looking for a financial problem. Someone wants to build an AI startup, so every problem starts looking like an opportunity to put an LLM in the middle of it. Someone wants to become a SaaS founder, so they look for something that can be turned into a dashboard with a subscription plan.

At some point, the founder has built a solution looking for a problem.

One of the simplest tests I use for these things is embarrassingly basic: would I buy this if somebody else were selling it?

Not would my friends use it. Not would people say it sounds interesting. Not would somebody download it because I gave them the link. Not would an investor think the market is large. If I knew nothing about the founder and encountered this product from a random company tomorrow, would I actually take my own money and buy it?

That question removes a lot of the emotional noise around startup ideas. The customer does not care how difficult the product was to build. They do not care that the founder spent six months working nights on it. They care whether it solves a problem well enough to justify changing their current behavior and spending money.

Believe me, that is a very different and more harsh standard.

A case study in startup theatre

I saw a particularly instructive example recently. Someone I had known personally for years approached me about becoming a technical co-founder of a fintech startup focused on household finances. The proposal described something like a fractional multi-family office for ordinary high earners. It included a family constitution engine, automated income routing, a compliance engine, smart ledgers, rules engines, dual authorization and various forms of household financial governance.

The proposal contained a lot of impressive terminology. The problem was that when I actually asked what the product was supposed to do, the concept was remarkably difficult to pin down. That should have been the first warning.

A product does not need to be simple. Some of the most valuable software is extremely complicated under the hood. But the person responsible for the business should still be able to explain what the product does in plain language. I should be able to understand who uses it, what problem they have, what they do with the product and why they would want it before I start thinking about architecture.

Instead, the proposal kept leaning on terminology. “Behavioral fintech” sounded sophisticated. “Household governance” sounded sophisticated. “Compliance engine” sounded sophisticated. “Multi-family office” sounded like an established category.

But strip all of that away and ask a simple question: what does the user actually do with this?

I eventually found myself trying to translate the idea into things people already understand. Is this something like PiggyVest for couples? Is it Bamboo for couples? Is it a financial management system for two people? What happens after the couple connects their accounts? What does the product actually provide that their bank apps, spreadsheets, savings apps and other financial tools do not?

Those were not technical questions. I was trying to figure out what the product was.

You cannot architect your way out of an undefined product

At one point, instead of explaining the product more clearly, the response was essentially that ChatGPT would be used to generate a system architecture so that I could understand the idea better. That was probably the moment I became particularly irritated.

Architecture is downstream of product definition. If you are asking the technical co-founder to produce an architecture so that the technical co-founder can understand what the product is, something has gone badly wrong.

If I am the technical co-founder, architecture is my domain. Give me the problem, the product requirements, the constraints and the business objectives, and I can work through the engineering options. I can tell you that one architecture will take three weeks while another might take three months. I can explain the infrastructure cost, the technical debt, the scaling limitations, the security implications and the long-term consequences. I can tell you where we can move quickly and where we should not cut corners.

Then, the other stakeholders can participate in the business decision.  

Perhaps we choose the faster architecture because the immediate objective is market validation. Perhaps we spend more because a major customer requires something more robust. Perhaps we deliberately accept technical debt because the alternative is spending six months engineering something nobody has demonstrated a need for.

That is a perfectly reasonable founder conversation.

What I am not going to do is ask a non-technical founder to design the architecture with me, and I certainly should not need an architecture diagram from an AI model to understand what the founder thinks the product is supposed to accomplish.

The founder should be able to explain the product. The technical founder should be able to explain how to build it. That division does not mean the two founders operate in silos. It means each person has a domain in which they are expected to exercise actual competence.

The conversation that mattered was supposed to happen before the software

Since I had serious concerns about the product, I suggested something very simple: go and talk to people.

I did not mean send out a survey to friends and relatives. I explicitly suggested talking to around fifty couples and avoiding close acquaintances because they introduce a completely different kind of bias. I also explained that the conversations should not begin with the product idea. There was no point walking into someone's house and announcing that you were building a "financial operating system" (operating systems are buzzwords today, by the way) for couples, then asking whether they would use it. Of course, the conversation would be contaminated by the solution you had already invented.

What I wanted was much more ordinary. Talk to people about how they actually manage money together. Find out what happens when they have financial disagreements, how they handle shared expenses and savings, what they currently use, what they have tried, what frustrates them and what they wish worked differently. Let the problem emerge from the conversation instead of feeding the person a problem statement and asking them to confirm it.

The purpose was not to get fifty people to say, “Yes, I would use your app.” The purpose was to discover whether the problem existed in the first place, what the problem actually looked like, who experienced it most severely, what people already did to deal with it and whether the pain was strong enough to support a business.

Instead, an AI-generated questionnaire came back.

The questionnaire looked perfectly respectable. It had sections for demographics, current financial arrangements, friction points, behavior, solution testing and willingness to pay. It asked whether couples would be interested in automatically splitting income into savings, expenses and personal use, whether they would pay for such a tool and which features sounded most valuable.

That is exactly the sort of thing that can look like customer research while avoiding the difficult part of customer research.

There is a massive difference between asking somebody whether they would use an automated financial allocation system and getting them to tell you about the last time they and their partner had to figure out what to do with their money. The first question presents your solution and asks them to react to it. The second gives you an opportunity to discover how they actually behave when the product does not exist.

I wanted evidence about the problem. What came back was another artifact.

Then came the pitch deck

The situation became even more obvious when the next request was essentially to help design a pitch deck that could be presented to the couples. It was the opposite of what I had advised.

If I tell you to go and talk to fifty people because you need to understand whether there is a problem, the goal is not to persuade those fifty people that the solution is good. The goal is to find out whether your assumptions are wrong or probably right.

You want people to contradict you at that stage. You want someone to tell you that they have never experienced the problem. You want someone to explain that their existing bank app already solves it. You want someone to tell you that they tried something similar and abandoned it. You want someone to tell you that the problem exists but they would never pay for a solution. All of that is useful information.

A pitch deck reverses the direction of the conversation. Now you are presenting a story and asking the customer to react to your interpretation of the problem.

That can be useful later, when you actually have something to sell. It is a poor substitute for discovery.

The irony is that the revised proposal eventually contained a much more sensible validation strategy. It talked about interviewing couples, mapping their financial friction, testing willingness to use automated allocation and even running a manual MVP before full engineering. The underlying idea became more coherent.

But the process had already revealed the problem I was concerned about. The instinct was repeatedly to create the artifacts of a startup before establishing the evidence that justified creating them.

Then the company wanted to exist

After all of that, the conversation moved toward registering a company with the Corporate Affairs Commission and setting up Google Workspace.

That was another immediate turn-off for me because I had never consented to becoming a co-founder.

There is nothing wrong with registering a company. There is nothing wrong with setting up Google Workspace. There is nothing wrong with a pitch deck. There is nothing wrong with an architecture document. All of these things can be perfectly reasonable when the time is right.

The problem is the sequence.

We had not established that the product was worth building. We had not established that customers wanted it. We had not established the business model. I had not agreed to join the company. Yet suddenly there were organizational tasks being assigned as though the partnership already existed.

That is another characteristic of startup theatre. The company starts acquiring all the external signs of existence before the underlying business has earned them.

You register the company. You buy the domain. You create the corporate email addresses. You make the decks. You create the company page. You announce the founders. You build the MVP.

At the end of it, you can have an impressive amount of artifacts surrounding a business that has never established why it should exist.

A founder does not need to know everything

I want to make an important distinction here because I do not think lack of experience disqualifies anybody from starting a company.

I did not know most of what I know now when I started building Monesize. I learned because actually doing things forced me to understand what was necessary.

You deploy production software and discover that infrastructure matters. You acquire customers and discover that sales and positioning matter. You handle payments and discover that financial operations matter. You collect customer data and discover that security and privacy matter. You operate long enough and discover that compliance, contracts, taxes, governance, insurance and a dozen other things matter.

Reality keeps presenting you with questions. You then have to figure out which questions you can answer yourself, which ones require deeper research and which ones require somebody with professional expertise.

That is what I mean when I say that actually doing things forces you to realize what is necessary to figure out.

A first-time founder can absolutely do this. In fact, every experienced founder was once a first-time founder.

The problem is not that you don't know. The problem is refusing to recognize that there is something you need to know. A very different failure mode.

The company is bigger than the application

This is why I find the current obsession with vibe coding slightly misleading. The ability to produce an application has never been the same thing as the ability to operate a business, but the gap is becoming more visible because the software itself can now appear so quickly.

You can build an interface for a financial product without understanding financial regulation. You can build a healthcare application without understanding the consequences of handling sensitive health information. You can build something that moves money without understanding the liability created when the system gets something wrong. You can build an AI application without understanding how its failure modes affect customers.

The code can work perfectly and the business can still be fundamentally broken.

There are legal questions, regulatory questions, security questions, operational questions, financial questions, commercial questions and human questions surrounding the software.

Some of those questions are boring. Some are expensive. Some are extremely technical. Some require professional advice. None of them disappear because an AI model helped you write the code.

That is the part of entrepreneurship that does not look glamorous on LinkedIn.

I learned this by actually using my own software

One of the simplest ways I have always thought about product quality is to use the product yourself.

When we announced the shutdown of the old Monesize application in March, I commented out the signup route in the backend and scaled the deployment down to a single instance. I kept the application running because I was still using it for my own bookkeeping. The same virtual machine hosted other applications, so keeping it alive cost essentially nothing extra.

Commercially, the product was shut down. Personally, I still found it useful.

That distinction mattered because I continued using the software after the shutdown. I was not keeping it alive because I needed to pretend that the product was still active. I was using it because it solved a real problem for me.

When we originally launched the old Monesize mobile application, I was not the person who built the mobile app, but I caught an enormous proportion of the errors before release because I was actually using it. I was not simply reading tickets and checking whether somebody had implemented the acceptance criteria. I was trying to use the product as a person who depended on it.

That exposes a different class of problems.

You notice that a workflow makes no sense. You notice that a button appears at the wrong point. You discover an impossible state. You encounter an error that nobody thought to test because the test case assumed that users would behave predictably. You discover that something technically works but is irritating enough that you would never want to use it.

There is a fundamental difference between saying, “We tested the application,” and saying, “We actually use the application.”

What happens when everybody can build the same thing?

There is another question I think every AI-first startup should ask itself.

Suppose you can build your product in two weeks. Great.

What happens when someone else can build the same product in two weeks?

This is not a hypothetical problem. If your primary achievement is that you were able to prompt an AI system into producing a particular workflow, somebody else may be able to reproduce the workflow with the same tools.

That does not mean AI startups cannot be defensible. It means the defensibility has to come from somewhere deeper than the fact that you produced an MVP.

It could come from proprietary data, distribution, network effects, customer relationships, regulatory approvals, difficult operational capabilities, genuine technical innovation, brand, domain expertise or simply exceptional execution. There are many possible sources of defensibility.

But, "we built it with AI" is not a moat. Neither is being first to put an AI wrapper around an existing problem.

If your product can be recreated by another person who has the same tools and enough time, then the interesting question becomes what your company accumulates that the other person does not have.

Progress is not always visible

This is probably the biggest problem with startup theatre. The activities that make a startup look impressive from the outside are often not the activities that create the most value at the beginning.

A founder can spend a day making a beautiful pitch deck. Another founder can spend that same day talking to potential customers and discover that the original product idea is wrong.

The first founder has something tangible to show at the end of the day. The second founder might have nothing except a notebook full of uncomfortable observations.

The second founder may have made considerably more progress.

That is because early-stage progress is often about removing uncertainty. Discovering that customers do not care about your proposed feature is progress. Discovering that your assumed customer is not actually the person with the problem is progress. Discovering that customers love the idea but will not pay enough for it is progress. Discovering that the business model runs into a regulatory wall is painful, but it is still valuable information.

None of those discoveries necessarily produces a screenshot. They may not make a good LinkedIn post. But, they can save you months or years.

The pitch deck does not necessarily reduce uncertainty. The customer conversation can. The architecture diagram does not necessarily reduce uncertainty. The prototype can. The company registration does not necessarily reduce uncertainty. The first paying customer can. The LinkedIn announcement does not necessarily reduce uncertainty at all.

That is why I think the distinction between artifacts and evidence is so useful. Startup theatre produces artifacts. Actual startup building produces evidence.

I don't think startup theatre comes from laziness

I actually think the phenomenon is understandable.

Starting a company is intimidating. There is no syllabus, there is no guaranteed path and nobody gives you a complete checklist. You are constantly making decisions with incomplete information, and some of those decisions have serious consequences.

So it is natural to gravitate toward things that feel concrete.

Registering the company feels like progress. Building the website feels like progress. Creating the pitch deck feels like progress. Getting the domain feels like progress. Building the MVP feels like progress. Updating LinkedIn feels like progress.

All of those things are tangible. The uncomfortable alternative is admitting that you do not yet know whether anybody wants what you are building.

You might spend a month talking to customers and discover that the idea is bad. You might discover that the market is smaller than you thought. You might discover that customers already have a perfectly adequate workaround. You might discover that the problem exists but nobody will pay enough to make the business work.

Those are painful discoveries, but they are exactly the discoveries a founder needs to make. Startup theatre gives you something to do while avoiding them.

The founder title is not particularly glamorous

I have never been particularly interested in putting "Founder" all over my professional identity. My LinkedIn bio and summary do not revolve around announcing that I am a founder.

That is not because I do not value what I have built. It is because after actually spending years dealing with the responsibilities of running a company, the title itself becomes much less interesting.

Being a founder means worrying about things that nobody sees. It means thinking about revenue, customers, infrastructure, security, compliance, product decisions, hiring, sales, operations and the next problem that has not appeared yet but probably will.

It means discovering that there is always another thing you need to understand.

The glamorous version of entrepreneurship is mostly visible from the outside. From the inside, it is a long sequence of problems.

I suspect that is why I am not particularly impressed by someone adding "Founder & CEO" to a LinkedIn profile. The title does not tell me much.

Show me what they built. Show me who uses it. Show me why those people care. Show me what changed exactly because the company exists.

Build the thing, not the costume

I am not against AI-generated software. I am not against pitch decks. I am not against company registration, branding, landing pages or LinkedIn announcements. All of these things have legitimate places in building a company.

What I am against is confusing those things with the company itself.

The easiest startup to build today might be the appearance of a startup. You can manufacture the software, the brand, the deck, the website and the announcement with astonishing speed.

The harder thing is finding a problem that matters, understanding it properly, building something people genuinely want, getting strangers to pay for it, keeping their trust, securing the system, dealing with the legal and regulatory consequences, surviving the competition and continuing to operate when the excitement of the launch has disappeared.

And you do not need to know all of it before you begin. I certainly did not. You need to be willing to let reality tell you what you need to learn. That is the part startup theatre cannot manufacture.

You can generate a pitch deck. You can generate an architecture diagram. You can generate an MVP. You can generate a LinkedIn announcement. You cannot generate evidence that your business deserves to exist.

That evidence has to come from reality.

And if you cared enough to read this epistle of mine all the way to this last part, I am leaving you with a question: are you actually building a startup or the mere appearance of it?