The new unit of company creation is one expert plus AI

The traditional shape of an early-stage software company is well understood. To get a real product from zero to a credible v1, you need: a product person, two or three engineers, a designer, someone who can do infrastructure, someone who can do basic security, and someone — often the founder — wearing the QA hat in their spare time. Six to nine months and most of a seed round later, you have something to show paying customers.

This shape is no longer mandatory. For a meaningful and growing class of products, the same scope of work is now being shipped by one operator working with an AI co-developer, in a fraction of the time, at a fraction of the cost. Not as a thought experiment. In production, with real users.

The interesting question is not whether this is possible. It demonstrably is — there are working examples shipping every week. The interesting question is what kind of operator it requires, what the new economics look like, and where the limits genuinely are.

What collapses, and why

The traditional team structure exists because no single human can hold all the necessary skills at production quality. You need a frontend specialist because frontends are deep; you need a security person because security is deep; you need a designer because design is its own discipline. The team exists to compose these specialisms into a coherent product.

AI co-development changes this in a specific way. It does not turn a generalist into a specialist. It turns a specialist into a coherent generalist — one who can produce specialist-quality output across adjacent disciplines, provided they retain the judgement to know what good looks like in each.

A senior engineer with a strong product instinct can now ship the design system. A senior product person with a working knowledge of architecture can now ship the database schema. A founder with good visual taste can now ship the brand identity. The AI does the labour of producing specialist-grade artifacts; the human supplies the judgement that decides what to ship and what to throw away.

The work that collapses under this pattern, when done by an experienced operator with AI assistance:

Brand and design system creation — days, not weeks

• Frontend development — perhaps 5x faster, more if the engineer has good taste in code
• Backend and database — similar compression, often more for boilerplate-heavy work
• Infrastructure and deployment — the gnarly bits (Vercel config, Android signing, Stripe webhooks) that used to take days now take hours
• Documentation — close to free
• Test infrastructure — written first, maintained throughout, no longer the thing that gets cut when shipping
• Release notes and changelog discipline — also close to free, which means it now actually happens

The compression is not uniform across these. Some are 2x, some are 10x, some are essentially infinite (documentation that previously didn't exist now exists routinely). But the cumulative effect of compressing every part of the build at once is not additive. It is multiplicative. A team of ten people doing each part 5x faster is not a tenable comparison, because the team of ten still has the coordination overhead of being ten people. One operator doing everything 5x faster does not.

What does not collapse

Some things are not faster. They may, in fact, be more expensive.

Judgement does not scale. Knowing whether the design system is good, whether the architecture is right, whether the security audit found everything, whether the product actually solves the problem — these still require an experienced human. AI accelerates the production of artifacts; it does not improve the taste required to evaluate them. An operator with good judgement and AI assistance can build a remarkable product. An operator with poor judgement and the same AI assistance will build a remarkable mess, faster.

Domain knowledge does not collapse. The reason a mushroom identification app needs a real mycologist to design the dataset, or an art marketplace needs a real understanding of how galleries actually work, has not changed. The AI compresses the engineering around the domain knowledge. The domain knowledge itself is still expensive to acquire, and remains the moat.

The willingness to throw work away. This is the underrated skill. AI-assisted development makes it possible to build something properly twice as easily as it used to be possible to build it once. The operators who get the most out of this are the ones who, on day three, are willing to delete the day-one work and start again because they now know what they should have built. This is psychologically difficult and almost no one does it well in a traditional team setting, because the sunk cost of team time is too high. With one operator and AI, the sunk cost is low and the right move is therefore available.

The discipline to test what matters. The temptation, when shipping is cheap, is to ship without testing. You actually have to test more, and more frequently. The operators who do this well treat testing as a non-negotiable contract — TDD where it makes sense, E2E coverage of the things that actually break, safety-critical regression tests that run on every change. The discipline is what separates products that ship fast and last from products that ship fast and collapse.

The economic implication

For investors, the implication is uncomfortable. The cost structure of early-stage software has been rebuilt and the conventional capital model is, in many cases, financing a team that is no longer required. A £1m seed round in 2024 paid for a team of seven for a year. The same product, in 2026, can plausibly be built by one operator over three months on a few tens of thousands of pounds of compute and tooling.

The pattern is not universal. Some products genuinely need a team — anything with serious enterprise-sales motion, anything with regulated complexity, anything where the brand is built through human relationships at scale. But for a meaningful slice of the SaaS, prosumer, and consumer software market, the team is now optional, and the operators who recognise this are getting to product-market fit on a fraction of the capital.

For operators, the implication is the inverse. The strategic value of being the single expert with judgement on a build has gone up dramatically. Companies are now buildable by one person that previously required ten. The constraint is no longer access to engineering capacity. It is access to operators who combine deep enough domain knowledge, broad enough taste across disciplines, and the discipline to apply both consistently over months.

This is a different shape of person to optimise for. Universities do not produce them. Most large companies actively select against them, because the same instinct to do everything yourself reads as "doesn't play well with others" in a corporate review process. They tend to emerge from a mix of engineering depth, operating experience, and a high tolerance for working alone.

What this changes for incumbents

The companies most exposed to this shift are the ones whose product moats are made of engineering effort that used to be expensive. A product whose value proposition is "we built this thing, and it is hard to build" is structurally vulnerable when one operator can now plausibly build the same thing in a quarter.

The companies least exposed are the ones whose moats are made of customer relationships, regulated trust, network effects, or proprietary data. None of those have been collapsed by AI co-development. The reverse: as the cost of building software falls, the relative value of non-engineering moats goes up.

The strategic question for any software incumbent is therefore not "how do we use AI internally" — though that matters — but "what fraction of our moat is engineering effort that has just become cheap, and what fraction is something else?" For many companies, that audit will be uncomfortable. It is, however, better to do it now than to discover the answer through competition.

Where to start, if this is the strategy

The temptation is to read this and conclude that the next product should be built by an operator-plus-AI team of one. For some products that is correct. For others it is not, and the failure mode of misapplying the pattern is severe — a six-month, one-person death march that produces an incoherent product because the operator did not have the right combination of skills.

The honest test is small and concrete. Pick something specific you have been wanting to build — a tool, an internal product, a small commercial product. Try to build it solo with AI assistance over a few weekends. The first attempt will tell you, accurately, where your taste is good enough and where it is not. Where it is not, you have just learned a high-value piece of information about your own capabilities. Where it is good enough, you have just discovered a genuinely new lever.

This is the work Magilium increasingly does with clients: helping operators and investors think clearly about what the new unit of company creation means for their specific business. The implications are large, the timing is now, and the answers are not in the conference talks yet — they are in the products being shipped this quarter by people who have stopped waiting for permission.