If You Want to Build the Next Workday, Don’t Build the Next Workday

I remember when Workday first started showing up in conversations. It was in 2008, and I was working at an SAP partner. Back then, enterprise HR was largely running in a client-server model, heavily customized, and often painful to operate in-house. SAP HR and PeopleSoft had dominated the space for years. That changed when Oracle managed to acquire PeopleSoft in 2005 (after a painful process). And then Dave Duffield and Aneel Bhusri, the people who built PeopleSoft, quietly started over.

But they didn’t just build a better architecture. They had two decades of credibility and a great reputation in the industry. They were connected to every enterprise HR leader. When they called a CHRO, the call got answered. When they promised a cleaner, cloud-native experience, people believed them. That combination of the right technology, the right timing, and the right founders landed in a market that was ripe for change. Large enterprises wanted to move away from capex-based license models with expensive annual support and maintenance. The SaaS model, where you pay per seat, promised to deliver something better. Companies also wanted to manage HCM at the global level, instead of country by country. And that market was, in real terms, a greenfield.

That greenfield doesn’t exist anymore.

What “AI-Native” Is Actually Doing Here

Two days ago I read “Workday’s Last Workday?” It‘s a compelling piece by Joe Schmidt. The author argues that Workday is finally vulnerable and that AI-native challengers are about to do to Workday what Workday did to PeopleSoft. Workday does have architectural debt (incumbents always have) and the implementation timelines are genuinely painful. Bolting AI onto a 2008 platform is not the same as building for AI from scratch. The piece has sparked a broader conversation and Thomas Otter’s response is worth reading alongside it.

But there’s a significant gap between identifying the problem and understanding what it actually takes to solve it.

I’ve spent more than two decades in the HR Tech industry. I’ve worked with enterprises on complex, global HR & payroll implementations. I advise tech vendors and work closely with startups trying to build the next generation of HR and payroll solutions. My inbox is full of AI-native, API-powered pitches. And what founders are building is often genuinely impressive from a technology point of view. But when I start asking the hard questions, the functional depth, the understanding of what it means to run HCM and payroll in an enterprise situation, is often missing.

The Architecture Is Not the Hard Part

Let’s start with what “AI-native” actually means in this context, because the term is doing a lot of heavy lifting.

The argument is essentially this: a system built from scratch in 2026, designed around agents and large language models rather than workflows and approvals, would be architecturally superior to Workday and could therefore be implemented faster, configured more flexibly, and maintained more cheaply. I think that logic is sound: clean architecture does beat legacy architecture, all else being equal.

But all else is not equal. Because it’s not the architecture that makes HCM hard.

What makes HCM hard is that it is regulated infrastructure. When you want to deliver HCM and payroll in a country, it means not just knowing the rules but understanding how they interact. This includes local labor laws, social contribution structures, collective agreements, and the jurisprudence that has built up around edge cases over decades. A coding agent can absolutely ingest configuration logic, and increasingly, it can assist in interpreting regulatory frameworks and surfacing inconsistencies. That already has real value: even partial automation of compliance interpretation can reduce manual effort and shorten implementation cycles significantly.

But the hard boundary is whether AI can be held accountable. Payroll and HR decisions require explainability, auditability, and ultimately someone who is responsible when things go wrong. That is where current AI systems still run into both technical and regulatory limits. So, while AI will meaningfully compress the work, it doesn’t eliminate the need for deep domain ownership.

And even where AI can help, the legacy ecosystem does not disappear. The world an HRIS connects to is not being rebuilt alongside it. Benefits and pension providers expect specific file formats that haven’t changed in decades. Tax authorities in most jurisdictions still operate on batch submissions, not real-time APIs. Banks run payroll disbursements through payment rails that were designed long before anyone used the word “agentic.” None of that is changing because a new HCM vendor built an AI-native architecture. The system must still integrate in the format and on the schedule those institutions dictate. That should not hold a startup back, but it’s a reality that must be faced.

The “deploy in one month” claim is actually the one that resonated most with me. I see a growing number of vendors (mostly focused on payroll) using AI to eliminate the traditional implementation model entirely. Rather than spending months mapping processes and configuring the system before the first pay run, they use AI to ingest current payslips and run payroll immediately, while continuously identifying differences and resolving them. It’s a fundamentally different approach that seem to work. In practice, it might be three months rather than one, but it’s still a massive improvement over the current implementation timelines. It does not mean that the complexity disappears. It just gets surfaced earlier and resolved quicker, when it’s cheaper to fix, rather than buried in a configuration that nobody fully understands by go-live. But notice that this approach benefits incumbents just as much as new entrants. And ironically, it might even increase incumbent satisfaction because it will finally eliminate the customer complaint that implementations and changes take too long and are too expensive.

Enterprises Aren’t Ready

There is a deeper problem that the AI-native framing glosses over entirely, and it is arguably more important than the architecture question. Even if a perfect AI-native HCM system existed tomorrow, most enterprises could not use it.

To run the kind of intelligent, agent-driven workflows that the vision describes, where agents reconcile headcount costs against AI spend, monitor regulatory changes across jurisdictions, and generate configuration updates automatically, you need workforce data you actually trust, processes that are documented well enough to measure, and clear decision ownership. Most organizations don’t have that today.

That said, enterprise systems have never been perfect. In practice, new platforms often force operating model changes rather than depend on them. The difference in HCM and payroll is that the tolerance for disruption is extremely low. You can evolve your processes while implementing a CRM. You have far less room to do so when payroll accuracy is on the line.

So yes, the operating model and the system will evolve. But in this category, that evolution is slower, more constrained, and significantly more risk-sensitive than most disruption narratives assume.

It also connects to something I’ve watched play out in many of our sales cycles. The real competition in an enterprise HR procurement process is rarely another vendor. We mostly feared the “do nothing” decision at the end of a long RFP, after months of evaluation, after everyone had acknowledged that the current system was unsatisfactory. At some point in the process, the buyer realizes that every vendor has its problems, and that a new system might solve their current problems but also introduce new ones. That migrating data to a new system is risky, and that it might lead to a disrupted payroll cycle. And that a new implementation costs real money. The question then becomes: how much pain do we really have?

People are always unhappy with their HR and payroll systems. Just not unhappy enough to switch.

The risk of getting it wrong

And that matters because of what HCM actually is, beyond the product roadmaps and architectural diagrams.

Payroll and HR administration are not software in the way people mean when they talk about disruption. They are the regulated foundation of the employment relationship. These systems touch everyone in the company, from the CEO down to the last worker. When you make an error, employees will notice immediately and be dissatisfied. When you make enough of them, you might end up in the newspaper or be fined. And for listed companies, if the compliance breaches are serious enough, leadership can find themselves in front of regulators. This is a category where ‘good enough’ does not work. Paying people accurately and on time is the baseline expectation. Achieving a 100% KPI is the only outcome. In payroll, you can’t exceed expectations: payroll is either complete or it isn’t.

That reality shapes buyer behavior in ways that don’t appear in disruption theses. Most startups that go after HCM and payroll don’t fully comprehend this. When a system works well enough, when the mistakes aren’t too severe, the risk of switching to a new solution is always larger than the reward. A new architecture, on its own, is just not enough. What changes the situation is either a catastrophic failure of the incumbent, or a challenger that has spent years proving itself in production across jurisdictions at scale, until the risk of switching finally feels smaller than the risk of staying. It took Workday years to earn that trust at scale, even with Duffield and Bhusri’s reputations behind it. A well-funded startup with a clean codebase and an impressive demo starts from zero. Trying to replace an enterprise incumbent and onboard their clients is a great goal, but also much harder to achieve than most startups think.

The Real Opportunity

So where does the real opportunity sit?

Not in replicating Workday for a new architectural era. The conditions that made Workday possible, the greenfield enterprise market, founder credibility that opened doors, a regulatory environment that was demanding but not yet as complex as today’s, and buyers willing to take a bet on a new platform don’t exist today in the enterprise market. Legislation is more stringent, more complex and increasingly more local. Procurement functions can tie up a startup for months without a single dollar of revenue to show for it. And the structural advantages that come with an incumbent installed base of 10,000 customers and 10,500 certified consultants don’t dissolve because someone built an AI-native infrastructure.

The greenfield today are companies that serve the frontline workforce. Hourly workers, shift-based employees, local labor markets. This segment has been genuinely underserved for years. Even though people saw the opportunity, serving this segment is hard. When you build for hourly workers, you run payroll at thin margins, navigate local labor law complexity, and manage the compliance requirements of industries like logistics, retail, and healthcare. The Employer of Record companies that built impressively global solutions for white-collar distributed workforces deliberately avoided this market. Managing employment across 140 countries for knowledge workers is, paradoxically, simpler than running compliant hourly payroll in a single country with a unionized workforce. That’s where the white space genuinely is.

More broadly: the question worth building towards is not who replicates Workday, but what the 2035 workforce actually needs from its HR infrastructure. A workforce that is more distributed, more varied in employment type (permanent, contingent, freelance, and yes, increasingly agent-assisted) and more locally regulated than anything Workday was designed for. The interesting problems are in outcome-based performance, workforce planning and coordination, skills intelligence, and the economic model for blended human-and-AI teams. Those are messy, dynamic problems where conventional technology has always struggled and where AI could genuinely change the model rather than optimize it.

That’s a different ambition than building a modern version of what already exists. Because the goal should not be a better payroll engine or a faster implementation of HCM system. A more plausible starting point is something incumbents were never designed to handle: coordinating work across blended teams of employees, contractors, and AI agents.

Imagine a platform that manages outcomes rather than employment relationships: allocating work, tracking contribution across humans and agents, and continuously recalculating cost, capacity, and performance in real time. That system doesn’t sit on top of the HR stack. It defines an entirely new layer of workforce coordination.

This does not mean the regulated layer disappears. Payroll, tax reporting, and employment compliance will remain constrained by local legislation and institutional requirements. What changes is where decisions are made. Instead of being embedded in static workflows inside the system of record, decisions about work allocation, cost, and performance move into a separate coordination layer. The system of record becomes an execution engine, not the center of gravity.

Existing HCM systems can’t easily follow as they are built around fixed records, predefined processes, and a business model tied to managing employees as units of record. A coordination layer that operates in real time across humans and agents challenges both their architecture and their economics.

The incumbent’s system of record doesn’t get replaced because it was outperformed on features or architecture. It gets sidelined because the center of value has moved elsewhere. That is what disruption can look like in a category where nobody easily switches. You won’t achieve that by going after the incumbent, but by enabling the shift towards how the future works.

Stop Looking at Workday

Here’s what I’d say to anyone seriously thinking about building in this space: stop anchoring your thinking on Workday (or any other incumbent). Understanding how these systems work, where they struggle, and why buyers choose them is useful. But if your product roadmap is defined by their feature set, you’re solving for a world of work that is already gone.

Instead, start with the workforce of 2035. Don’t treat it as an extrapolation of today, because it will be different. Design for a workforce where the boundary between employee, temp worker and contractor has blurred further and where AI agents handle entire categories of work that humans do today. But also, where the frontline worker in a warehouse in Berlin or a care home in Manila finally has native support built to serve them rather than self service added to software that was designed for a corporate HR function. And where the employment relationship will look different in duration, in structure, in what it means to be “on payroll” at all.

That workforce doesn’t need a cleaner or better version of today’s system of record. It needs an infrastructure that can handle fluid employment structures, that supports financial wellness across roles and can account for the economic contribution of humans and agents working side by side. It needs compliant operations across jurisdictions that are writing new rules and labor laws faster than you can track. And it needs something that was never built before, because this workforce never existed before.

That is the product worth building. The founders who build it won’t be the ones who studied Workday’s org chart. They’ll be the ones who deeply understand what the future of work actually looks like and have the courage to build towards that new model instead.

And that means the next great workforce platform will not announce itself as Workday’s replacement. It will emerge from a corner of the market that Workday was never designed to serve, solving problems that didn’t exist in the 2000s, when the current generation of systems was created. By the time the incumbents notice, it will already be too late to catch up.

That is how platform shifts actually happen. It is also, not coincidentally, how Workday happened.