What if I vibe-code Jira in an afternoon?
I mean... I could, right? Seeing how all this has progressed lately, we know the capabilities of assistants for writing code. We've tested them and verified that this is only the beginning of establishing a platform on which to rely to build code faster and faster. I'm not exactly talking about vibe-coding—as an engineer, I've always rejected the notion of building something based on how you feel, as if it were some kind of automatic writing process, typical of a 19th-century circus troupe—but rather about accelerated spec-driven development with AI tools... but the question I'm asking myself is almost the same.
Is SaaS dead yet? And now? And now?
SaaS has been the application of outsourcing processes to software. To make our lives easier and reduce recurring costs, we decided to outsource software solutions, as we had done before with other areas of our businesses. This led us headlong into finding new ways to make our lives more difficult and increase recurring costs, but which looked better on certain PowerPoint slides. I'm not even going to address the issue of disruption as a driver for eliminating complexity, which could supposedly be brought about by a system of AI agents that aims to replace the monolithic SaaS platforms on which businesses run. Those are topics for another time. I am going to focus on what interests me: functionality and its delivery.
There is one version of this story in which SaaS was a rational response to a real problem, and there is another version in which it was an admission of defeat by the entire industry. Companies moved to SaaS not because it was a better solution to their problems (in any dimension of “better” we can think of), but because they had repeatedly and at great cost proven that they were not good at creating and owning software themselves. SaaS didn't win on its own merits, but because the alternative had a long history of failure. That context is important now, because vibe-coding implicitly asks us to explore the alternative again, and the question worth asking is whether anything has really changed in our ability to own what we create.
Creating something that works is not the same as creating something that is ready. The version of your Jira replacement that you built in an afternoon will perfectly manage the happy path: tickets are created, statuses change, someone is notified. What it won't manage are the decades of questions that Atlassian has already answered and buried in code that you will never read and that you probably won't ask yourself until it's too late. What you build in that afternoon is, with a lot of luck, 10% of the iceberg that you can discern about how the SaaS you want to surpass works.
Ownership all over again
The iceberg analogy is often used to defend SaaS, but it has two sides. Okay, mature SaaS products have undergone years of invisible strengthening beneath the surface: edge cases, compliance mechanisms, fault recovery, security patches. That's real, and it's neither free nor easy to replicate. But that same invisible mass is also the reason why SaaS can't adapt to your context: the iceberg is made up of the problems of thousands of other customers, not yours. You're not just buying their solutions, you're also buying their limitations. The question isn't whether the iceberg exists, but whether you'd rather inherit someone else's or slowly develop your own.
The problem, as usual, is ownership: hidden problems under the water are not announced in advance. Your tool will work fine for weeks, maybe months, until the moment it stops, and that moment will be specific, consequential, and completely different from anything you thought to test. Not because you were careless, but because edge cases are, by definition, things hard to think of. Atlassian thought about them because ten million users ended up doing something unexpected, and that feedback loop is a big chunk of what you're really paying for. If you don't do it consciously (and, by definition, it will be difficult to be aware of what is hidden), what you are building in an afternoon does not have that feedback loop.
SaaS products are, by design, a response to what most customers need most of the time. That's not a flaw in execution; it's the business model. A product that tries to be everything to everyone is a professional services company, not software (or it's SAP, which is basically both). But the consequence is structural and worth mentioning honestly: the more your context deviates from the average customer, the more you stop using the product and start fighting against it. You create alternative solutions, especially if you believe you have the necessary knowledge and tools to do so.
The honest version of the vibe-coding promise is not “now it's yours,” but “now you choose which set of assumptions to inherit.” SaaS incorporates the provider's understanding of your problem domain. AI-generated code incorporates the understanding of a language model, which has been trained on generic codebases, Stack Overflow answers, and documentation written for the average use case. You've changed the source of the generic, you haven't escaped it. The tool seems like yours (it runs in your environment, has your variable names, does more or less what you asked it to do), but the underlying logic reflects someone else's mental model of what your problem is likely to be. The difference is that with SaaS, you could call support. With your substitute, the gap between what you think the code does and what it actually does is a problem you must discover yourself or, with a lot of planning, anticipate.
Spec-driven AI assisted development changes the cost curve, not the calculation. The serious response to vibe-coding is not “don't build,” but “build with your eyes open.” When engineering discipline enters the picture, the conversation changes: specifications replace vibes, results are questioned, and architecture is decided rather than inherited. That's significantly better. But it doesn't change the fundamental economics of ownership; it just means that technical debt is accumulated more consciously, which is a worthwhile improvement without pretending to be a solution.
All tools that fall into a gray area eventually face their moment of truth. The question is not whether this will happen—it always does—but whether someone in the situation room knows what to do next (if such a room even exists) and feels responsible for doing it. Most vibe-coded tools fail this test, not because the code is bad, but because responsibility was never explicitly assigned. Creating something small and useful is the easy part. Backing it up when it fails is the real commitment.
Lower start-up costs, no changes in the costs of finishing
The gray areas are not going to disappear. They never have. The choice has always been between a visible, governable layer of contextual tools and an invisible, uncontrollable one, and most companies already have the latter without having chosen it. The argument for deliberately encouraging this is not that it is risk-free. It's that the risk of not doing so, of leaving those gaps permanently unfilled or filling them with shadow IT that no one talks about, is consistently underestimated. Start small. Take responsibility for the outcome. Involve the people who actually live with the problem. And when it works, treat it like a real product, not a weekend hack that has survived.
No one is going to give a clear answer because there isn't one. SaaS will not cover all contexts completely, and it never will. Building everything yourself is a story that has ended badly so many times that it deserves skepticism. AI assistance reduces the cost of getting started without changing the cost of finishing. What remains, after all the positioning and counter-positioning, is something unglamorous: the quality of your results depends on the quality of your judgment, your willingness to take responsibility for what you build, and your honesty about what you are truly capable of maintaining. The afternoon you spend programming Jira is neither the problem nor the solution. What you do the next morning is.
The truth is that filling in gray areas is a very strong temptation, and taking the step that transforms a small hack that makes your daily life easier into something on another level is something that transcends the merely quantitative. I find myself at that moment, and with every step I take, I struggle not to lose sight of what I have just tried to summarize (I apologize for the length, really).