PeopleSoft Isn't Dying. But Its UI Model Needs a New Strategy.

PeopleSoft isn’t going to “die” quickly. ERP replacements take years; sometimes they fail, and a lot of institutions will still be running PeopleSoft a decade from now.

But I’m increasingly convinced of something more specific:

PeopleSoft, as a user-experience development platform, has hit a ceiling.

Not because PeopleSoft has no value—it still does. It’s durable. It’s a reliable system of record and data hub with real business logic. The problem is that expectations for modern software delivery and UX have changed faster than the PeopleSoft development model can keep pace.

And in late 2025, we hit an inflection point: AI-assisted coding became good enough that the speed gap between “modern app development” and “ERP UI customization” stopped being a rounding error. It became a strategic issue.

The approach I’d advocate is what most people call an API-first strategy: keep PeopleSoft as your system of record, expose its data and business logic through a governed API layer, and build your user-facing experiences outside the ERP using modern tools and frameworks. You’re not replacing PeopleSoft—you’re building on top of it and letting each layer do what it’s best at.

Here’s what that looks like in practice.

Before You Build Anything: Pick a Platform You Can Staff

An API-first strategy only works if you can actually deliver the apps that sit on top of those APIs.

So before you debate frameworks or architecture diagrams, make one practical decision:

Pick a small, standard internal platform that you’re happy investing in for the next 2-3 years.

Use whatever your organization already has strong skills in—.NET, Node, Java, Go—as long as it’s not a legacy dead end. The goal is not novelty. The goal is throughput:

• A stack you can hire for and train on.
• A stack you can standardize across multiple internal apps.
• A stack that works well with AI coding tools and modern CI/CD. This is critical!

If I were starting from scratch today, my bias would be a hypermedia-first approach, with Go, Postgres, and (when needed) NATS for messaging and Temporal for orchestration. That combination is fast to build with, operationally boring, and scales from “one workflow app” to a real internal platform without painting you into a corner.

Staff It With Builders, Not Just Architects

You also need a small team of the right people. Not a large staff—a handful of key resources dedicated to building internal apps.

What you want is a mix of a few senior developers who understand technology fundamentals and a few junior people who are hungry to learn. The important thing is that these are people who have actually built things—not just drawn diagrams. The title “architect” sometimes describes someone who can design systems on a whiteboard but can’t ship working software. That’s not what you need here. You need people who love experimenting with new technology, who aren’t afraid to sit down with stakeholders, understand business requirements, and then go build the solution.

With AI-assisted coding tools and cloud infrastructure, a small team with this profile can now deliver internal apps at a pace that previously required much larger teams. But it only works if you invest in people who know how to leverage those tools—and who genuinely enjoy the work of building. The build-versus-buy decision remains important, but the “build” side has become much more accessible with the right team and tools.

All of these team members need a license for AI coding tools. This is not optional. If you want to compete on delivery speed and quality, you need to leverage these tools effectively.

This shift began around November 2025. If you are not listening to the internet chatter of People who are seriously using AI tools to build internal apps, you may not be aware of how quickly the landscape has changed. The tools have matured to the point where a small, focused team can now deliver high-quality internal applications that integrate with PeopleSoft and other systems much faster than before. This is a game-changer for organizations that have been hesitant to invest in custom development due to resource constraints. It is also breaking down the traditional barriers between “build” and “buy” decisions, as the “build” option has become much more viable for a wider range of organizations. Your internal project management and governance processes will need to adapt to this new reality, but the potential for delivering value quickly is significant. Many organizations’ internal project management processes will likely hinder this new approach, so be prepared to advocate for a more agile, iterative development process that can keep pace with modern software delivery.

The Gap Isn’t Just UX — It’s Delivery

Let me be concrete about where PeopleSoft struggles as a development platform:

• Experimentation and branching. There isn’t a clean, modern workflow for “try a thing, measure it, roll it back” without putting your environment at risk.
• Modern interaction patterns. Real-time updates (Server-Sent Events/WebSockets), responsive dashboards, infinite scroll/lazy loading—these are table stakes in many user experiences now.
• Stitching multiple systems into one workflow. You can do it, but PeopleSoft wasn’t designed for it, and the friction adds up. Most orgs aren’t running just PeopleSoft anymore.

Fluid was a meaningful step toward modern UX. But in practice, many teams find that it increases delivery time and reduces flexibility compared to what they expected. Classic was ugly but fast: consistent patterns, lots of “magic,” and predictable dev workflows. Fluid made the UI prettier, but the developer experience (and iteration speed) often declined.

Meanwhile, outside the ERP, a small team with modern frameworks—and AI assistance—can prototype and iterate at a pace PeopleSoft development can’t realistically match. Additionally, you can adopt modern development practices: feature branches, code reviews, automated testing, and continuous deployment. The gap isn’t just about the final user experience; it’s about how quickly and safely you can get there.

What I’d Do as CTO: Keep PeopleSoft, Move the UI

If I owned a major PeopleSoft footprint, I wouldn’t lead with a rip-and-replace. I’d lead with a change in architecture:

1. Treat PeopleSoft as a system of record. Keep the data and business rules where they belong.
2. Make “Everything is an API” a real operating principle. Every meaningful read/write becomes an API capability with a documented contract.
   • Your PeopleSoft team needs to create and maintain a stable API layer. This is the foundation of everything else.
3. Build net-new user experiences outside PeopleSoft. Use your standard internal platform to build workflow apps that stitch together PeopleSoft and other systems. Keep the stack boring and consistent. (Personally, I’m partial to a hypermedia approach because it reduces client-side complexity and plays well with AI-assisted code generation.)
4. Use AI coding tools to accelerate delivery—but keep your normal engineering discipline. AI is a force multiplier, not a waiver of code review, testing, and security.

This is not a new idea. It’s basically the portal-era vision, upgraded:

• Not iFrames and XML.
• Stable API contracts and small, purpose-built apps.

The Hard Part: Building a Real API Layer on PeopleSoft

This strategy immediately runs into a problem: PeopleSoft is not designed to be an API-first platform.

Yes, you can use Integration Broker. Yes, Component Interfaces exist. Yes, you can make it work.

But most PeopleSoft teams know the reality:

• It’s easy to build something that technically works.
• It’s hard to build something that’s consistent, maintainable, documented, and safe to scale across dozens of downstream apps.

The architecture assumes the PeopleSoft page is the primary consumer of most transactions, not clean external API consumption. Retrofitting that can be clunky.

In practice, an API-first approach requires an intentional API-layer strategy and the right PeopleSoft expertise to execute it. It’s not just about exposing existing transactions; it’s about designing a coherent API surface that abstracts away PeopleSoft’s quirks and provides a stable contract for your external apps.

A quick disclosure

I’m biased: I built a product called SWS (Secure Web Services) that solves many of these problems—exposing PeopleSoft data and business logic through a more modern, predictable API surface. Whether you use SWS, custom middleware, or another tool, the broader point remains:

You need a coherent, governed API layer before you can realistically move UX outside the ERP.

What This Looks Like When It’s Working

When you get the API layer right, you unlock a different delivery model.

Example 1: Operational dashboards that aren’t painful

PeopleSoft operations teams often want real-time visibility into:

• process scheduler status,
• long-running batch processes,
• dependency bottlenecks,
• environmental health.

You can build some of this in PeopleSoft, but it’s rarely pleasant, and it’s rarely truly real-time.

With an API surface available, building an external dashboard becomes straightforward: prototype quickly, then harden it with the same steps you’d apply to any production tool (auth, logging, tests, deployment).

Example 2: “One screen” workflows across SaaS sprawl

This is the pattern I see everywhere now (especially in higher ed):

• PeopleSoft for core records.
• LMS for learning.
• CRM for recruiting/engagement.
• Student success/case management / early alert tools.
• And an endless number of point solutions.

Advisors and staff live in tab hell.

An API-first UI approach lets you build a “single screen” experience that pulls the most relevant data from each system, in the order the user needs it.

That kind of stitching is exactly the kind of integration-and-UX work modern stacks are good at—and it’s increasingly the kind of work AI coding tools accelerate.

The AI Shift: “Low-code Without Low-code”

Traditional low-code platforms promised faster delivery by constraining you to a vendor’s model. PeopleTools shares some DNA with low-code platforms — it abstracts away infrastructure and provides a structured development model. But that model was designed for a different era of UX expectations and development workflows.

AI-assisted coding plus mainstream frameworks create a new reality:

• A small team can generate solid first drafts quickly.
• Senior engineers can review, harden, and ship.
• You aren’t locked into proprietary tooling.

This doesn’t eliminate SaaS or low-code, but it changes the economics of internal tools—especially the long tail of “we should build this someday” ideas that never cleared the ROI bar.

The Risks (and How to Handle Them Like an Adult)

If you’re reading this as a CTO/CIO, you’re probably already thinking about the objections. You’re right to.

• “Is AI-generated code safe?” Treat it like any other code: review it, test it, scan it, and deploy it through your normal pipelines. The workflow is: AI drafts, engineers validate.
• “Will we create a mess of internal apps?” Not if you govern the API layer and standardize your app stack. Unmanaged sprawl is a risk; good platform discipline is the mitigation. If you let inexperienced teams deploy “vibe-coded” apps on random stacks, you will have a mess. But if you have a small, focused team following clear standards, you can maintain quality and consistency. (Focus on hiring and deciding on a small set of tools that your team can master.)
• “What about PeopleSoft upgrades?” This is exactly why the API contract matters. Your API layer should be a firewall: PeopleSoft changes behind it, downstream apps keep working.
• “Aren’t we just moving technical debt?” You might be—but moving debt from niche ERP UI tooling into mainstream codebases can actually be a win if it improves hiring, maintainability, and iteration speed.

A CTO-Level 90-Day Plan to Prove It

You don’t need a multi-year program to validate this strategy. You need one journey and a clean comparison.

Phase 1 (0–90 days): Prove it on one workflow

• Pick one painful, high-frequency workflow (advisor view, HR manager dashboard, finance approvals, ops console).
• Stand up an API surface for only what that workflow needs.
• Build a small external app that consumes those APIs (and optionally 1–2 key SaaS APIs).
• Use AI coding assistants aggressively for scaffolding and UI iterations.
• Hold the quality bar: senior review, security review, logging, and a sane deployment path.

Outcome: you get a side-by-side comparison of delivery speed, UX quality, and maintainability.

Phase 2 (3–12 months): Standardize the pattern

• Make the API layer the default interface for net-new work that touches PeopleSoft.
• Standardize a small, boring app stack your team can staff.
• Evaluate whether net-new Fluid development is the best path for each project, and default to external apps where the workflow fits.
• Create a small internal “product” capability focused on workflow apps.

Phase 3 (12+ months): Make PeopleSoft boring (in a good way)

• Gradually bypass the highest-friction PeopleSoft UIs.
• Treat PeopleSoft as stable core infrastructure.
• Measure results: time-to-deliver, user satisfaction, reduced vendor purchases.

Bottom Line

PeopleSoft will be around for a long time.

But your organization’s ability to deliver modern user experiences should not be trapped inside PeopleSoft tooling.

The winning strategy I see emerging is simple:

• Keep PeopleSoft as the system of record.
• Invest in a governed API layer.
• Build modern workflow apps outside the ERP.
• Use AI to accelerate delivery—without lowering your engineering standards.

Once you’ve shipped the first good “outside PeopleSoft” workflow, it becomes very hard to justify going back.