DEV Community: Sarah Andrew

Why We're Building Vertical SaaS on WordPress Instead of Building Another SaaS Platform

Sarah Andrew — Sun, 09 Aug 2026 17:39:21 +0000

If you build WordPress websites for clients, you've probably encountered the same problem we kept running into.

The website itself is rarely the complicated part anymore. An agency can build a very good site with WordPress, Elementor, Bricks, Gutenberg or whatever stack they prefer. The real challenge starts when the client asks for software that sits behind the website.

A church doesn't just want pages about its ministries. It wants member management, giving, attendance, groups, events, communication and somewhere for people to log in.

A gym doesn't just need a homepage and timetable. It needs memberships, bookings, attendance and customer accounts.

A school needs something different again.

At that point, agencies usually have three options. Build the software themselves, assemble a collection of WordPress plugins and integrations, or send the client to an external SaaS product.

We've been exploring a fourth option with WPWaaS: give WordPress agencies finished, industry-specific software they can deploy alongside the websites they're already building.

That's the idea behind WPWaaS, and it's also why we're deliberately building it as infrastructure rather than trying to create another standalone SaaS platform.

The problem isn't WordPress

There's a common assumption that once a WordPress project needs serious application functionality, you should probably stop using WordPress.

I'm not convinced that's always true.

WordPress already gives agencies an enormous amount of useful infrastructure. It's familiar, flexible, widely supported, relatively easy to deploy, and there are millions of businesses whose websites are already running on it.

The problem comes when we try to turn a generic WordPress installation into a complete software product by assembling dozens of unrelated components.

A membership plugin handles members. Another plugin handles events. Another handles payments. Another handles forms. Another handles notifications. Then someone needs a dashboard, so another plugin gets added.

Individually, those plugins might be excellent. The problem is that the resulting product isn't necessarily designed as one product.

This is one of the reasons we started thinking about the difference between Website as a Service and traditional SaaS. If you're unfamiliar with the distinction, we recently put together a more detailed explanation of what Website as a Service actually means and how it differs from the more familiar SaaS model.

The distinction matters because WPWaaS isn't trying to turn WordPress agencies into SaaS developers overnight. We're trying to give them infrastructure they can use to deliver software as part of the work they're already doing.

Our first test case was a church

The first portal we built was for churches.

That wasn't because we intend WPWaaS to be a church software company. It was simply a particularly good place to test the idea because church websites expose the limitations of the traditional WordPress approach very quickly.

The public website might look relatively simple. Home, about, ministries, sermons, events, contact and giving.

Behind that website, however, is an organization with hundreds or thousands of people who need to interact with it.

Members need accounts. Administrators need to manage people. Groups need to exist. Attendance needs to be recorded. Events need to be managed. People need to be able to submit prayer requests. The organization needs online giving and communication tools. Members need access to resources.

You can build all of this with WordPress if you have enough time, technical expertise and patience.

But that's not the same thing as having a coherent software product.

We decided to build the latter.

The result is the WPWaaS Church Portal, which brings those workflows into one purpose-built dashboard rather than expecting an agency to stitch together a collection of unrelated plugins.

The important part for us wasn't simply getting the features working. It was designing the experience around the people who would actually use the software.

WordPress is great for developers. That doesn't mean it's great for everyone.

This became another important part of our thinking.

If you're a developer, WordPress's admin interface makes perfect sense. You understand Posts, Pages, Plugins, Users, Settings and all the other pieces that make up the system.

Now imagine you're a church member who just wants to see an upcoming event, check your group information, make a donation or submit a prayer request.

They don't care that the underlying system is WordPress.

They shouldn't have to understand WordPress either.

This is why the WPWaaS dashboard deliberately looks and behaves more like an application than a traditional WordPress administration panel. The objective is to give the end user an interface that feels like software built specifically for their organization.

That becomes even more important when you consider that these aren't necessarily people who spend their day inside WordPress.

A good software product should make people want to use it.

It shouldn't make them feel like they've accidentally wandered into the backend of a website.

Then we asked a much bigger question

Once the Church Portal started coming together, we kept asking ourselves why the same concept couldn't work for other industries.

The underlying problem isn't unique to churches.

A gym has customers, memberships, payments, bookings and attendance.

A real estate business has clients, properties, agents, enquiries and documents.

A school has students, parents, attendance, communication and events.

A clinic has appointments, patients and communication.

The workflows are different, but the pattern is remarkably similar: the website is the public-facing layer, while the business increasingly needs software behind it.

That's where the idea of vertical SaaS became particularly interesting.

Rather than building one giant generic dashboard and asking every business to configure it themselves, we're building a common platform that can support different industry-specific products.

One platform, different verticals

This is probably the most interesting technical direction for us.

We don't want to build ten completely unrelated applications.

We want common infrastructure underneath the different portals, while allowing the actual user experience and business logic to change significantly from one vertical to another.

Authentication, user management, roles, tenant management, branding, deployment and other infrastructure can be shared.

The actual application layer can then be specialized.

A church needs members, groups, giving and attendance.

A gym needs memberships, classes, bookings and trainers.

A school needs students, parents, attendance and communication.

A real estate business needs properties, agents, leads and client interactions.

That gives us an interesting engineering tradeoff. We get the efficiency of shared infrastructure without pretending that every industry has the same workflow.

It's also why we don't see WPWaaS as simply another collection of WordPress plugins.

The goal is to create industry-specific software that happens to use WordPress as part of its infrastructure.

Why not just build another SaaS?

This is probably the question developers will ask.

Why build on WordPress at all?

Why not build a completely independent application using Laravel, Next.js, Rails, Django or whatever stack we'd choose for a conventional SaaS product?

There are certainly situations where that would make more sense.

But we're specifically building for WordPress agencies.

Those agencies already know WordPress. They already have hosting infrastructure. They already have clients on WordPress. They already know how to build and maintain WordPress websites.

Asking them to completely change their development workflow isn't necessarily solving their problem.

Our agency model starts from a different assumption: the agency should be able to keep doing what it already does well.

Build the frontend however you like.

Then, when the client needs more than a website, deploy the relevant WPWaaS portal alongside it.

That's a much smaller change to an agency's workflow.

The agency is actually the customer

This is another part of WPWaaS that is easy to misunderstand.

We're not primarily selling these portals directly to churches, gyms, schools or clinics.

We're building infrastructure for the agencies that already serve those organizations.

That changes the entire business model.

Imagine an agency is hired to build a church website. The agency still designs and develops that website as a normal WordPress project.

But instead of sending the church to another company when it needs member management or online giving, the agency can offer a branded portal as an additional service.

The agency can set its own client pricing and retain the revenue from that subscription. WPWaaS doesn't take a percentage of the agency's client revenue.

We've written more about this model in our guide to recurring revenue for web agencies, because that's ultimately where the commercial opportunity becomes interesting.

The website project doesn't disappear.

It becomes the starting point for a longer software relationship.

This is different from simply reselling a SaaS product

There are already plenty of platforms that allow agencies to resell software.

There are also plenty of church management platforms, membership systems and client portals.

Some are excellent products.

The problem we're trying to solve is slightly different.

Take a church agency as an example. The agency might build the church's WordPress website and then recommend a platform such as Tithe.ly or Subsplash for everything that happens behind the scenes.

That works, but the agency has effectively handed that part of the client relationship to another company.

We explored that exact distinction when comparing WPWaaS with Tithe.ly and WPWaaS with Subsplash.

The WPWaaS model is much more interesting to us because the agency can remain the provider.

The client gets a branded portal.

The agency owns the relationship and controls its pricing.

And the portal lives much closer to the WordPress ecosystem the agency already understands.

It's also more than WordPress Multisite

Technically, someone familiar with WordPress might look at WPWaaS and think, "Isn't this just WordPress Multisite with some plugins?"

That's a reasonable question.

Multisite is certainly part of the infrastructure story, but simply creating a network of WordPress sites doesn't solve the product problem.

Tools such as WP Ultimo and Ultimate Multisite are useful examples of the infrastructure layer that already exists around WordPress Multisite.

WPWaaS is approaching the problem from a different direction.

We're not primarily trying to give an agency a blank multisite platform and tell them to build the product themselves. We're building the industry-specific product itself, then giving the agency the infrastructure to deploy and resell it.

That's a pretty important distinction.

The agency shouldn't have to become the software company.

Deployment needs to be boring

From an engineering perspective, this is one of the areas we're paying a lot of attention to.

If an agency has to spend hours manually configuring every new portal, we've failed.

The whole point is that deploying the software should become predictable.

The agency should be able to select the appropriate portal, deploy it, configure the branding and domain, set up the client and get on with the actual project.

That's why self-service deployment, tenant management, white-labeling and repeatable provisioning are such important parts of the platform.

We've documented the basic workflow in How WPWaaS Works, but there's a lot more engineering behind making something like this feel simple from the user's perspective.

The best infrastructure is often the infrastructure you barely notice.

Where we're going next

Church is only the beginning.

We're working toward more industry-specific portals, including areas such as fitness, real estate, clinics and dental, schools and tutoring, and other categories where WordPress agencies already have a substantial client base.

That's an important part of our strategy.

We don't want an agency to sign up for WPWaaS because it has one church client.

We want an agency to look at the growing portal library and think:

"I already have clients who could use three of these."

That's where this becomes much more interesting.

A generalist WordPress agency might work with churches, gyms, property businesses, schools, consultants and professional services companies. If the agency can access specialized software for several of those verticals through the same underlying platform, WPWaaS becomes much more useful than a single-purpose plugin.

The long-term vision is effectively a library of vertical SaaS products for WordPress agencies.

We're still figuring out the hard parts

We're deliberately building this in public to some extent because we're still early.

There are plenty of technical problems we're working through.

How much functionality should live in the shared platform versus individual verticals? How do we keep updates safe across multiple agency deployments? How much should agencies be able to customize? Where should the boundary between WordPress and application functionality sit? How do we keep each portal feeling genuinely native to its industry without creating ten completely separate codebases?

Those are much more interesting questions to us than simply building another WordPress plugin.

We're also continuing to expand the platform itself, including things such as mobile-first experiences, PWA capabilities and notifications. The reason is simple: if we're asking end users to use these portals regularly, the experience needs to feel like modern software rather than a website that happens to have a login screen.

The bigger idea behind WPWaaS

The more we work on this, the less interested we become in the idea of WPWaaS being "a WordPress plugin."

That's technically what part of the product is, but it doesn't really describe what we're trying to build.

The bigger idea is a layer between WordPress agencies and vertical SaaS.

Agencies already know how to build websites.

Businesses increasingly need software.

There is a gap between those two things.

We want to give agencies a way to fill that gap without forcing them to build and maintain every piece of software themselves.

That's why the WPWaaS pricing model is built around agency deployments rather than taking a cut from the agency's customers. The more useful the portal becomes to an agency's clients, the more opportunity the agency has to build recurring revenue around the projects it is already winning.

And that's ultimately the bet we're making.

Don't replace the WordPress website. Build what comes after it.

If you're a WordPress developer or agency owner, I'd genuinely be interested in your take. Would you build vertical SaaS on top of WordPress, or would you start from a completely separate application stack? Where do you think the line between "WordPress website" and "WordPress application" should actually be?

We're still working that out ourselves.

You can follow what we're building at WPWaaS, or dig into the WPWaaS story and the thinking behind the platform if you want to see where this started.

I Fixed My WooCommerce Store's Embarrassing Account Page (Without Writing a Single Line of Code)

Sarah Andrew — Fri, 28 Nov 2025 22:18:08 +0000

Last week, a customer emailed asking if my store was "still in business" because the account dashboard looked "kind of abandoned." That stung. I'd spent $2,000 on a custom theme and countless hours perfecting the product pages, but the moment customers logged into their account, they saw what basically looked like a WordPress admin panel from 2012.

The worst part? I knew it was bad. I'd been ignoring it for months.

If you're running a WooCommerce store and feeling that same embarrassment every time you think about your account dashboard, this tutorial is for you. I'm going to show you exactly how I transformed mine in under 30 minutes without writing any PHP, editing any template files, or risking a single "white screen of death."

Why the Default WooCommerce Account Page is Actually a Problem

Before we get into the fix, let's talk about why this matters beyond aesthetics.

The default WooCommerce "My Account" page shows customers a greeting and a vertical list of text links. That's it. No order statistics. No visual hierarchy. No indication of order status. Nothing that makes customers feel informed or in control.

This creates three real problems:

1. Professional credibility gap

You're competing against Shopify stores that show beautiful, modern account dashboards by default. When your customers log in and see bare-bones navigation, they're making comparisons. Not favorable ones.

2. Support ticket factory

I analyzed my support tickets for the past 90 days. Roughly 20% were customers asking questions like "Where's my order?" or "What's my order status?" The information was technically available in their account, but buried behind clicks and presented in ugly tables.

3. Mobile experience disaster

The default account page is a desktop list crammed onto mobile screens. Since 58% of my traffic comes from mobile, that's more than half my customers getting a subpar experience.

What We're Building

Here's what we want the account dashboard to show:

Order statistics at a glance (total orders, processing, completed, pending)
Recent activity log (order updates, shipments, account changes)
Visual charts showing order history and trends
Mobile-responsive card layout
Customizable colors and text to match our brand

And here's the constraint: we need to do this without writing custom code, because most of us don't have the time or budget for custom development.

Prerequisites

Before we start, you'll need:

A WordPress site running WooCommerce (tested on WooCommerce 8.0+)
Access to your WordPress admin dashboard
About 30 minutes

That's literally it. No PHP knowledge required. No child theme setup. No template file editing.

Step 1: Understanding the Problem Architecturally

The default WooCommerce account page fails on information architecture, not just aesthetics.

Everything has equal visual weight. There's no guidance about what matters or where to look first. Customers have to click "Orders" to see order status, then click individual orders to see details. It's functional in the same way a command line is functional—it works if you know exactly what you're looking for.

Compare this to what customers actually need:

Immediate visibility of current order status
Quick access to tracking information
Clear indication if action is needed (failed payment, address needed, etc.)
Historical context about their relationship with your store

None of this exists by default.

Step 2: Choosing the Right Solution

I tested three approaches:

Custom Development

Hire a developer to build a custom dashboard. This works but costs $3,000-6,000, requires ongoing maintenance, and takes 3-6 weeks. I wasn't ready for that investment.

Page Builder Approach

Use Elementor or similar to rebuild the account page. Problem: most page builders don't play nice with WooCommerce's account endpoints, and you lose functionality trying to force it.

Purpose-Built Plugin

Find a plugin specifically designed to enhance the WooCommerce account dashboard. This seemed like the pragmatic middle ground.

I went with option three. After testing several plugins, I settled on the WooCommerce Custom My Account Dashboard plugin for a couple of reasons:

Actually adds functionality (statistics, charts, activity logs) instead of just restyling links
No-code customization through settings panel
HPOS compatible (High-Performance Order Storage)
Mobile responsive by default
One-time payment, no subscription

Step 3: Installation

The installation is standard WordPress plugin procedure.

First, purchase the plugin from the developer's site. You'll get a ZIP file.

In your WordPress admin, go to: Plugins > Add New > Upload Plugin, Install, and click "Activate."

Step 4: Initial Configuration

After activation, you'll find new settings under:

WooCommerce > Settings > Enhanced Dashboard

The settings are organized into three tabs:

General Settings

Configure welcome text, button labels, and basic functionality. This is where you customize the greeting message and navigation.

Appearance Settings

Control colors, chart styles, and visual elements. This is where you'll match your brand colors.

Content Display

Choose which sections appear and set content limits. This controls the layout structure.

Step 5: Configuring Statistics Cards

The statistics cards are the first thing customers see. They provide immediate context without requiring clicks.

In the Appearance tab, you'll see color pickers for:

Total Orders card
Processing Orders card
Completed Orders card
Pending Orders card

I matched these to my brand colors. The key is maintaining sufficient contrast for readability. Don't use light text on light backgrounds just because it matches your aesthetic.

For my store (selling outdoor gear), I used:

Total Orders: Dark green (#2d5016)
Processing: Orange (#ff6b35)
Completed: Green (#4caf50)
Pending: Red (#f44336)

The color coding provides instant visual feedback. Customers can see at a glance if they have pending or processing orders that need attention.

Step 6: Setting Up Activity Logs

The activity log shows recent account events chronologically:

Nov 28, 2025 - Order #4891 shipped
Nov 26, 2025 - Payment received for Order #4891  
Nov 26, 2025 - Order #4891 placed
Nov 20, 2025 - Address updated

This eliminates the "what happened?" confusion that generates support tickets.

In Content Display settings, set the activity log limit. I use 10 items—enough to provide context without overwhelming the interface.

Step 7: Configuring Analytics Charts

The plugin includes two chart types:

Orders Over Time

Line chart showing order frequency over the past 6 months. Customers can see their purchase patterns.

Order Status Breakdown

Pie chart showing the distribution of completed vs pending vs processing orders.

These charts aren't just pretty—they provide context that reduces anxiety. Customers can see their complete relationship with your store, not just their most recent order.

Configure chart colors in the Appearance tab. I kept these simple:

Completed orders: Green
Processing orders: Blue
Pending orders: Orange

Step 8: Mobile Optimization Check

Here's the critical step most people skip: actually test the mobile experience.

Open your account page on your phone (or use Chrome DevTools device emulation).

The statistics cards should stack vertically on mobile. Text should be readable without zooming. Buttons should be large enough to tap without precision.

If anything looks cramped, adjust padding in the Appearance settings. The plugin provides responsive controls, but every theme is different.

Step 9: Testing the Customer Experience

Before declaring victory, test the complete customer journey:

Log out of your admin account
Log in as a test customer (or create a new test account)
Place a test order
Check how the dashboard displays with actual data
Test all interactive elements (reorder buttons, tracking links)

I found several issues during testing:

My welcome message was too long on mobile (fixed by shortening it)
The chart colors didn't have enough contrast (adjusted opacity)
Activity log timestamps weren't in my timezone (fixed in WooCommerce settings, not the plugin)

The Results

After implementation, here's what changed:

Support tickets dropped by 60%

The most common questions ("Where's my order?" "When will it ship?") disappeared almost entirely. Customers could see order status immediately.

Mobile bounce rate decreased

Before: 45% of mobile users bounced from the account page. After: 18%. The mobile-responsive cards made a massive difference.

Customer feedback improved

I started getting unsolicited compliments about the "professional look" of my store. One customer specifically mentioned the account dashboard feeling "like a real business."

Time investment: 28 minutes

From installation to final tweaks, the entire process took under half an hour.

Common Mistakes to Avoid

After helping a few other store owners implement similar solutions, here are the pitfalls I've seen:

Mistake 1: Overcomplicating the color scheme

Your account dashboard doesn't need 12 different colors. Stick to 3-4 colors maximum, ensuring sufficient contrast for accessibility.

Mistake 2: Ignoring mobile testing

Desktop looks great, mobile looks cramped. Always test on actual devices, not just browser emulation.

Mistake 3: Forgetting about HPOS compatibility

If you're using WooCommerce's High-Performance Order Storage (and you should be), make sure any solution you implement is HPOS compatible. Otherwise, you'll have performance issues.

Mistake 4: Setting activity log limits too high

Showing 50 activity items creates visual clutter. 8-12 items is the sweet spot.

Alternative Approaches

If the plugin route doesn't work for your situation, here are alternatives:

Custom Development

If you have budget and specific requirements, custom development gives you complete control. Expect to pay $4,000-7,000 and plan for 4-6 weeks of development time.

Headless Commerce

For stores rebuilding their entire frontend, going headless (Strapi + Next.js, for example) lets you build completely custom account experiences. This is overkill for most stores.

Accept the Default

If your customers never complain and your support tickets are manageable, maybe the default dashboard is fine. Not every problem needs solving.

Conclusion

The WooCommerce account dashboard is one of those problems that's easy to ignore until a customer points it out. Then it becomes impossible to unsee.

Fixing it doesn't require hiring a developer or learning PHP. It requires acknowledging that the default experience isn't good enough and spending 30 minutes implementing a better solution.

Your customers will notice. Your support queue will thank you. And you'll stop cringing every time someone logs into their account.

Resources

What's your biggest WooCommerce UX pain point? Drop a comment—I'm always looking for new problems to solve.