The phrase "SaaS is dead" has been trending lately. The argument is that since we are in an era where AI can write code, we should stop paying monthly fees for SaaS and just build what we need in-house.
At my company, Emooove, we have spent the last few months fully committed to building our internal systems in-house. Having actually done it, I have experienced both the successes and the painful lessons. Today, I want to share my perspective on the "SaaS is dead" narrative based on that real-world experience.
To be clear, I am writing this from the perspective of a user/builder of systems, not a SaaS provider.
An Amazing Era Where Anyone Can Build Systems
First, as a premise, the arrival of Claude Code has truly brought about an era where "anyone can build a system." This is no exaggeration.
At Emooove, a recruitment lead who had only been with us for two months built an in-house ATS (Applicant Tracking System). She is a non-engineer with zero engineering experience. Despite that, she created a functional system that handles everything from importing applicants to selection management and dashboards.
Furthermore, we are currently developing an internal system to improve the operational efficiency and quality of our core business, sales agency services. I am personally committed to this daily, and less than two weeks since we started, I feel we are on the verge of creating something quite good.
It is understandable why people want to say "SaaS is dead" when you can build something in-house that would otherwise cost tens or hundreds of thousands of yen per month in SaaS fees.
However, It Is Not All Smooth Sailing
This is the main point. When we actually tried it, it wasn't all sunshine and roses.
1. Maintenance is Incredibly Difficult
For better or worse, you can build things "on the fly," so they take shape quickly. However, because the requirements aren't fully fleshed out, there are many rough edges.
In the case of our ATS, we saw things like:
- Entries that were supposed to be imported weren't.
- Dashboard numbers were somehow bugged.
- Critical buttons were missing, causing operations to grind to a halt.
We encountered many "omissions we only noticed after we started using it." With our internal sales support system, there was even a morning where we suddenly couldn't access it and the screen wouldn't open.
Of course, these can be fixed to some extent by defining requirements more carefully or making improvements as you go. However, during that time, normal business operations are disrupted. If you start building with the expectation that it will be "easy and fast," you'll end up in a tough spot. I realized that you shouldn't start with the mindset of "build and finish," but rather "build and keep fixing."
Since our recruitment scale is small, we can manage even if the ATS stops for a bit. But I shudder to think if this were a system with many stakeholders. As the number of users and the scope of impact increase, the loss from a single failure grows, and the difficulty level skyrockets.
While you might tolerate this for internal systems, you should be extremely cautious about building anything for external sale or anything that faces the outside world, like an inquiry form.
2. UI/UX Never Gets Polished
I realized this while building the system myself: the finish is somewhat mediocre.
The screens AI first generates look "decent," but when you actually use them, the details are clunky. While you can eventually make it look good by giving instructions over and over, that requires intense obsession and time. Most people will likely compromise halfway through.
SaaS interfaces are polished because professional designers have spent years reflecting user feedback; that is not something you get for free.
3. The Security Issue
This is the scariest part.
Even non-engineers can use Claude Code to build functions and UI/UX with a "just wing it" attitude. But is it possible to catch up on security the same way? At least for me, it isn't. Authentication, permission management, vulnerability response—"working" and "being secure" are two completely different things.
In our case, we fortunately have someone with experience as a security engineer, so we make sure to have them handle this part. Even then, a bit of anxiety remains. The thought of an organization without experts putting customer information on a system built on a whim and making it public makes me break out in a cold sweat.
The Binary "Live or Die" Logic is Wrong
I've listed the negative points of in-house development, but honestly, there are many good things too.
- You can build something that fits your business perfectly.
- If you want to fix something, you can do it the next day.
- There are almost no monthly costs.
- The company gains know-how and confidence that "we can build systems ourselves."
The problem is trying to simplify it into "Will SaaS live or die?" Whether to adopt SaaS or build in-house depends on the company's situation. Based on my experience, here are the five points to consider:
Point 1: Do you have engineers in-house?
If not, you will fail in areas like security that non-engineers cannot handle on a whim. The scariest part is being able to build the functions without realizing the dangers. The turning point is whether you can secure an experienced person to review key areas.
Point 2: Number of stakeholders
If there are too many, the loss when a failure occurs is huge, and the difficulty level rises sharply. Conversely, small organizations can experiment more easily because they can just apologize if things stop. It's realistic to start with operations that have a small scope of impact.
Point 3: External vs. Internal systems
With internal systems, the risk is limited if something happens. However, for anything external, a single information leak can be irreversible. While SaaS allows you to offload some responsibility to the vendor, with in-house development, everything is your responsibility. The value of the "proven peace of mind" of SaaS grows for anything facing the outside.
Point 4: Can you allocate man-hours for maintenance?
Maintenance happens more than you imagine. In-house development is not "build and finish" but "keep fixing." Can you start with that foresight? If you start with a half-hearted attitude, you'll be buried in fixing flaws and it will pressure your core business.
Point 5: Do you like/want to do AI development?
In the end, it comes down to this. It's more tedious and difficult than you'd think, and it's frustrating when the AI doesn't listen (laughs). Can you see it through regardless? It's a great era for those who enjoy it, but I don't think it's something that can be sustained by a sense of duty alone.
Summary: SaaS is Not Dead. There are Just More Options.
I used the word "failed" in the title, but more accurately, it was "almost failed many times." We continue in-house development because we have experienced engineers, our organization is still small, it's mainly for internal use, we are prepared to commit to maintenance, and above all, I want to do it. You could say we are doing it because we are in a privileged environment where all five points are met.
Conversely, if a company that doesn't meet these conditions takes "SaaS is dead" literally and tries to build its core operations in-house, it will truly fail.
SaaS is not dead. It's just that the option to "build" is now open to everyone. Calmly assess your company's situation and use both SaaS and in-house development. Isn't that the right way to deal with this convenient yet precarious era?
