SaaSpocalypse: Is SaaS Still Worth It?
by Time Cockpit
“SaaSpocalypse” is a deliberately dramatic label for a real shift. AI coding tools and vibe coding are dramatically lowering the cost of software prototypes. Features that once required companies to buy a SaaS product can sometimes be recreated in days or weeks.
That puts part of the SaaS market under justified pressure. A subscription is no longer defensible simply because an application runs in a browser and stores data. Vendors whose main value is an interchangeable interface will find it increasingly difficult to explain why customers should keep paying.
For time tracking, however, the conclusion “we can just build it ourselves” often points in the wrong direction. A data entry screen is easy to build. A reliable system for working time, billing, project controlling, permissions, privacy, and integrations is something else entirely.
From a management perspective, the cost comparison is often distorted. SaaS license fees are clearly visible in the budget. The cost of an internal product is distributed across product management, engineering, business alignment, operations, and support. A prototype quickly demonstrates what already works. The long-term obligations become visible only after people depend on the system and the first exceptions reach production.
That pattern is familiar in time tracking projects. An apparently simple requirement is soon followed by questions about roles, approvals, closed periods, corrections, billing, and reporting. This is not an argument against building software internally. It is an argument for evaluating the complete decision. A company that builds the system does not merely own the code. It assumes responsibility for a continuously operated internal product.
Our central thesis is:
The SaaSpocalypse will not end SaaS. It will end SaaS whose value lies mainly in implementing an interchangeable interface.
The fair comparison is not SaaS versus an AI prototype. It is a continuously operated SaaS product versus an internal product for which the company assumes full responsibility. That distinction matters for IT and professional services firms.
What the SaaSpocalypse argument gets right
Forrester describes a market in which AI agents change established software workflows, challenge seat-based pricing, and make it easier to recreate individual features through vibe coding. The pressure is expected to be greatest for horizontal point solutions with low switching costs and weak integration into business processes. Vertical and domain-specific vendors with deeper process knowledge are in a stronger position. At the same time, Forrester cautions against interpreting the change as the imminent disappearance of core enterprise SaaS (Forrester).
This distinction matters more than the headline. An isolated tool that captures a few fields and displays them again may indeed become interchangeable. The more deeply software connects rules, roles, data, and downstream processes, the less accurately its value can be judged from screenshots or a feature list.
For buyers, this is a healthy development. SaaS vendors need to explain the ongoing value they provide. Existing subscriptions also deserve a sober review: Which processes depend on the product? What responsibility does the vendor assume? Which risks does it reduce? And what would a realistic replacement cost, rather than a screen that merely looks similar?
The key insight: AI makes code cheaper, not responsibility
We find it useful to think about SaaS value in three layers.
Layer 1: The visible feature
This is what appears in a demo: forms, tables, filters, dashboards, and workflows. AI is particularly capable at this layer. It can design interfaces, generate data models, connect APIs, and produce a convincing first version.
This layer is becoming cheaper. Features that exist only here are easier to copy and therefore more economically interchangeable.
Layer 2: Domain logic
Below the interface is the knowledge of what data means and how edge cases interact. In time tracking, that includes the relationship between working time and project time, billable and non-billable work, approvals, corrections, part-time arrangements, absences, cut-off dates, and invoicing.
This logic does not appear merely because a model writes good code. It has to be specified, aligned across departments, tested, and refined over years. Much of a product’s real value lives not in the happy path but in the many exceptions that must behave reliably in daily operations.
Layer 3: Assumed responsibility
The third layer is barely visible in a product demo. Who keeps the system available? Who deploys security updates? Who restores data? Who responds when an integration changes? Who reviews permissions, records changes, and supports users?
This is where the make-or-buy decision is ultimately made. AI can accelerate tasks in all three layers. It does not assume responsibility for the outcome.
The cost curve for code is falling faster than the cost curve for responsibility. This creates a responsibility gap: a system can be built faster than an organization is prepared to own it over the long term.
In our view, this is the most important implication of the SaaSpocalypse. The value of reliable software does not disappear. It moves away from implementation alone and toward domain knowledge, governance, and dependable operations.
Why the distinction matters especially for time tracking
A basic time entry screen is easy to prototype: date, project, activity, duration, save. In a professional services business, however, that solves only a small part of the problem.
A simple correction reveals the hidden complexity
Consider an unremarkable event: an employee corrects a time entry from the previous month.
On the screen, this means changing two fields. The surrounding process immediately raises further questions:
- Has the month already been approved or closed?
- Has the work already been included in a customer invoice?
- Does the correction change the project margin or post-calculation?
- Must a manager approve it again?
- Who may see the original and corrected values?
- Can the organization determine when and why the change was made?
- Does the corrected entry need to be transferred to another system?
None of these questions is unusual. Together, they turn a data entry form into an operational system. A fast prototype easily obscures this chain because the happy path can look convincing long before the exceptions have been specified.
One record, many consequences
Recorded time can feed customer billing, post-calculation, capacity planning, and project management. It helps teams compare plan and actuals, identify overload, and allocate work fairly. Errors therefore rarely remain confined to the original entry. They reappear as questions from finance, implausible margins, or misleading management information.
Good time tracking should not be framed as employee surveillance. For IT services firms, it creates a shared and reasonably reliable information base. Employees can document their work, project managers can identify deviations earlier, and management does not have to rely exclusively on intuition.
Working time and privacy are not add-ons
In Case C-55/18, the Court of Justice of the European Union held that Member States must require employers to establish an objective, reliable, and accessible system that makes it possible to measure daily working time. The specific national implementation is a separate legal question. For system selection, however, the judgment illustrates the importance of reliability and accessibility (Court of Justice of the European Union).
Time records are also personal data. Article 25 GDPR requires data protection to be considered when the processing is designed and through privacy-friendly defaults. This includes appropriate technical and organizational measures and the principle of data minimization (EUR-Lex). This article is not legal advice, but the implication for product decisions is clear: permissions, visibility, retention, and purpose limitation belong in the specification, not on a future wish list.
What AI actually changes in software development
AI coding is neither empty hype nor an automatic replacement for software products. It changes where effort occurs.
McKinsey describes AI in software development as a profound productivity shift. The qualification is important: successful organizations do not merely distribute a coding tool. They redesign the development process. AI agents need structured requirements, clear acceptance criteria, architectural context, and non-functional expectations such as security and reliability. Humans set direction and boundaries, review outputs, and remain accountable for quality (McKinsey).
That aligns with our practical assessment. The faster code can be produced, the more important it becomes to decide what should be built, who reviews it, and how it will be operated. AI can accelerate implementation, tests, and documentation. It does not replace alignment among management, project delivery, HR, finance, privacy, and IT.
Productivity effects also depend strongly on context. In 2025, METR studied experienced open-source developers completing tasks in repositories they knew well. In that specific experimental setting, developers with access to AI tools took 19 percent longer on average. METR explicitly cautions that the result does not support a broad conclusion about all developers, tools, or scenarios (METR).
The management lesson is not that AI is slow. Productivity assumptions need to be tested in the organization’s actual context. A fast prototype proves neither lower total cost nor sufficient quality in production.
Secure software development also remains a process. The NIST Secure Software Development Framework covers preparing the organization, protecting software, producing well-secured software, and responding to remaining vulnerabilities. NIST describes these as practices that need to be integrated into the software development life cycle and improved continuously (NIST).
The fair comparison: product operations versus product operations
Comparing SaaS time tracking with an internally generated demo means comparing different levels of maturity. A sound make-or-buy decision has to place the same responsibilities on both sides.
| Area of responsibility | Question for both SaaS and in-house development |
|---|---|
| Domain logic | Are working time, project time, billing, approvals, and corrections handled consistently? |
| Operational reliability | Who monitors availability, backups, updates, and recovery? |
| Privacy | How are data minimization, access, deletion, and retention implemented? |
| Permissions | Who may view, change, approve, or analyze which data? |
| Traceability | Do changes, approvals, and corrections remain auditable? |
| Integrations | Who keeps connections to finance, HR, and project systems stable? |
| Maintenance | Who responds to new requirements, vulnerabilities, and aging dependencies? |
| Product ownership | Who prioritizes, tests, documents, trains, and supports users? |
SaaS does not guarantee that these responsibilities are handled well. It does make them visible as criteria in the vendor assessment. In an in-house product, they are often distributed across IT and business departments. Those ongoing efforts and opportunity costs belong in the business case. Our article on make or buy for time tracking systems explores this comparison in more detail.
A product responsibility test for management
Before deciding to build time tracking internally, we would answer seven questions in writing:
- Product ownership: Who owns the product internally and has authority to prioritize requirements?
- Capacity: What development and maintenance capacity remains available when customer projects demand attention?
- Operations: Who is accountable for availability, backups, recovery, and incidents?
- Governance: Who defines roles, privacy rules, approvals, and traceable correction processes?
- Quality: Which reviews, automated tests, and acceptance criteria apply to AI-generated and manually written code?
- Life cycle: Who updates dependencies and integrations in three, five, or eight years?
- Exit: How can all data be exported and transferred to a successor system?
If these questions have convincing answers, in-house development may be a sound choice. If the answers amount to “our IT team will handle it on the side,” coding is not the largest risk. Unresolved product responsibility is.
Opportunity costs also matter, especially for IT services firms. The same specialists could serve customers or improve the company’s own differentiated offering. An internal product should therefore be a deliberate strategic decision, not the accidental consequence of a surprisingly compelling prototype.
When building in-house can make sense
It would be misleading to claim that SaaS is always superior. An internal system can make sense when the process is tightly scoped, creates real differentiation, and the organization has lasting product ownership capability. A small application that consolidates data from existing systems or automates a specific step can also be highly economical with AI.
The important question is where to build. Does the entire core need to be recreated? Or is an extension, integration, or specialized report around an established system sufficient?
In our view, the second option is becoming more attractive. AI makes custom extensions cheaper while a standard product carries the responsible but less differentiating foundations. This is not a decision against AI. It is a more deliberate division of labor.
What future-ready SaaS time tracking needs to deliver
SaaS time tracking remains valuable when it combines three characteristics.
A stable, reliably operated core
Core functions and data need to remain consistent, secure, and maintainable. This concerns more than time entries. It also includes roles, correction processes, reporting, and ongoing technical operations. The vendor assumes product responsibility and should be able to explain how that responsibility is fulfilled.
Domain knowledge rather than feature volume
For professional services firms, the longest feature list is not the goal. What matters is whether a product understands the connections among work records, project control, invoicing, and working time. Domain logic is especially valuable when it prevents typical errors and supports consistent downstream processes.
Adaptability for the company’s operating model
Standardization should end where companies meaningfully differ. Project structures, approval processes, required fields, reports, and integrations vary. A rigid SaaS product can therefore be as problematic as a complete in-house development.
Our position for time cockpit is a customizable SaaS product with a stable core. Individual processes should not require customers to rebuild the entire foundation. At the same time, customization should not force every company to assume responsibility for operations, maintenance, and the fundamentals. We explain this principle in more detail in our experience report on customizability in SaaS software.
AI fits well into this model. It can help clarify requirements, design extensions faster, or implement specific automations. It then becomes a tool within an accountable system rather than a substitute for one. Readers evaluating the build option can continue with our article on building time tracking software with AI.
Conclusion: The value of SaaS is moving up the stack
The SaaSpocalypse argument asks a valid question: What lasting value does a SaaS vendor provide when AI can generate individual features faster and faster? For interchangeable horizontal tools, the answer may be uncomfortable.
In time tracking, however, the essential value does not reside in the entry form. It lies in domain logic, reliable data, privacy, permissions, integrations, traceability, adaptability, and continuous maintenance.
AI does not reduce this value. It makes it easier to distinguish which part of a product was merely implementation effort and which part represents genuine, continuously assumed responsibility.
The management question is therefore no longer simply “build or buy?” It is: Which product responsibilities do we deliberately want to assume ourselves, and which responsibilities are we consciously paying a SaaS vendor to carry?