When Bain announced that they are using “vibecoding” as a part of their due diligence, it raised questions about how well the classical consulting model understands software businesses. Software is fundamentally iterative, and just because you can build a first prototype does not tell you much about the overall tech and/or business fundamentals.
The litmus test
Before critiquing anything, let’s start with an example and try this out ourselves. We will do this for an easy to understand business, which does not rely on network effects to succeed. In our case, this will be Ramp. Using Lovable with the prompt: “Create an expense app, where I can upload a picture, it uses AI to recognise the amount and type and stores it in a database.” After 5 minutes, it created the below.
I was impressed by how well it worked. The result does exactly what I asked, but it is still missing a lot of features, which I could probably add with some effort. The thing is, Ramp is perfectly positioned as a business to understand and build those features. While you can copy their simplest feature set, they can keep scaling up with integrations, virtual credit cards, their own AI bots, and so on. So yes, you could build a simpler version of Ramp, but full feature parity would take a lot of resources just to end up as a fast follower. The real innovation would still sit with Ramp, and as a rule, fast followers rarely win. In what follows, I will lay out why this latest idea by Bain might not be the smartest.
Nothing new under the sun
Cloning software is nothing new. Developers have been doing it for a long time, sometimes to learn and sometimes as part of an interview, and there are thousands of YouTube videos showing how to build a working Instagram clone in under three hours. So why has no-one ever really managed to launch one successfully? Network effects are a big part of it, of course, but the deeper reason is that Instagram is far more than a front-end and a back-end connected over HTTP. It runs an entire infrastructure that can serve billions of users at the same time. It has one of the best recommendation engines ever built, the kind that keeps people on the screen for hours. And it monetises all of those users through an ad platform that actually works. Even if you somehow had a billion users, running that business would take thousands of engineers, data scientists and account managers. That is not something you copy with Lovable.
And it is not just startups that run into this. Even the largest companies struggle with it. Back in 2023, Meta itself tried to copy X with Threads, and at first it worked: the feature grew into a huge platform almost overnight. But it did not last. By 2026, most people have forgotten Threads even exists, and Meta has moved on to rolling out AI features across its products. Even with network effects and serious engineering capacity behind it, they could not make it stick. Products are much more than what they look like on the surface.
Building at scale
Building at scale has two parts: building the right things, and building them well. The first is product management: knowing which features your users actually want. Incumbents have the edge here, since they get constant feedback and know the business inside out. They get disrupted when they stop caring about the first part and only optimise the second.
For the second part, it helps to look at a company that has truly reached immense scale: Discord. Over the last decade, they have migrated their database not once but twice, first from MongoDB to Cassandra and then from Cassandra to ScyllaDB, going from billions of messages to trillions along the way. MongoDB was perfect for moving fast in the early days (they built Discord in just two months back in 2015, without any vibecoding), but they eventually outgrew it. Fortunately, they had planned for exactly that from the start, so when the time came the move went relatively smoothly. Six years later, they did the same thing again to reach Scylla, a migration they had actually named in the original Cassandra blog. The point is that different scales call for different technology with different trade-offs, and getting there takes real planning long before the scale actually arrives.
When you vibecode a quick copy, you are doing neither of these things. Your roadmap just reads “copy X.” You never stop to ask what customers actually care about, and you are not thinking about scale either, because you have no users yet anyway. Your structure is not built for it, so every new feature turns into the kind of migration that strikes fear into even the best engineers.
Great products connect both parts of scale with a structure that makes it easy to build the right things in the right way. When Discord wants a new feature, they can scope it, build it and run the migrations. They move fast without breaking too much.
Devil’s advocate
Let’s play devil’s advocate and argue that some software does not need to be built for billions of users or 1000s of organisations. Take Slack for example, the messaging platform owned by Salesforce. It is used by many organisations and has to account for this scale when it takes engineering decisions. Organisations could instead build a smaller alternative for just their organisation. This is perfectly doable (or at least that’s what you think) and would indeed be a significant threat for Slack.
Let’s list what they would be missing:
Availability across all platforms
Integration with Google, Zoom, Microsoft…
SSO; though this could be implemented
SOC2, ISO27001 compliance
Assurance of not leaking chat data
…
Many of these could be solved with engineering effort. But it comes back to an old product question: does it make the beer taste better? In other words, does the customer actually care? Customer don’t care that your run your own Slack, even though it might cut the SaaS bill. Some organisations will try, but they will be the minority. SMEs don’t have the expertise, and large enterprises can’t absorb the change (and would have to handle scaling to 100,000 users, see above).
Don’t believe me? In 2024, Klarna tried exactly that. As a software business, they certainly had the capability. A year later, they had scaled some of those decisions back. Being your own only customer means you never benefit from what everyone else has learned.
Software is hard (to understand)
Software is hard to understand because complex software looks deceptively like simple software. The principles look the same, the code you write looks the same, and the architecture can look the same too. The hard parts are simply invisible from the outside.
This is not the first time a large consulting firm has drawn criticism for voicing strong opinions on AI. Last time it was McKinsey (and to be fair, my “alma mater” BCG has had its own lapses). In what I would argue is one of the weaker pieces on software I have read, they argued that you can measure developer productivity by combining a set of metrics. Most likely, today they would add token consumption to that list. But the best developers are the ones who put the effort into simplifying things and cutting technical debt, not the ones who simply write the most code. Software has to last for a long time, and productivity is not the same as quality. Magic metrics don’t exist, and any metric you pick will just end up pushing people toward the wrong behaviour (see also Goodhart’s law). The responses on YouTube were telling. Once again, it shows that software is hard.
Staying relevant in the age of AI
This of course cuts deeper than Bain just vibecoding an app. Consulting organisations are struggling to find where to deliver value to their clients. Frontier models are becoming better, not only at software, but also making slides and advising on deals and business models. Especially for Bain, where due diligence has been one of their strongest areas it has been hard to compete. AI can read through millions of resources, even conduct interviews for a fraction of the cost. In a recent article from FT, many of the consulting companies indicated an end to the current model with McKinsey’s head of AI going as far as to say: “The nature of what is consulting . . . of course has to change.”
I don’t think though that these companies will lose their value. They are actually perfectly positioned to be an adviser: understanding where AI can work for companies, and being a critical force that challenges organisations to use these tools well. This move by Bain is not that. It points to a gap in understanding that is worth taking seriously.