illustrated characters of Shopify and Wordpress surrounded by other characters representing AI, WCAG, Bots, and Agents in a Selfie

Our Shift from Proprietary CMS to Shopify + Wordpress

David Gibson

For about 20 years, we built everything on our own CMS. We called it propCMS. It ran on a LAMP stack and we knew every line of it. When clients asked if we could do something, the answer was almost always yes. No platform constraints, no "sorry, we can't do that." We built what needed building, and maintaining all of it was on us too.

The honest case for propCMS

Proprietary CMSs got a bad rap, and the story wasn't entirely unfair. Open source platforms had a better narrative: community maintained, widely adopted, thousands of developers who knew them. "Proprietary" versus "open source" was an easy comparison to lose, even when your platform was more capable. And as WordPress and Drupal lowered the barrier to entry, developers with limited experience could spin up a site fast. The market filled up with mediocre builds on platforms with good reputations. The platform got the credit, not the developer.

Ours was solid, built specifically for clients with real operational complexity. Ski resorts were our sweet spot: conditions reporting, interactive trail maps, seasonal content management. Off-the-shelf platforms in the early 2000s weren't built for that. We were.

The tradeoff was that everything fell on us. Security patches, performance tuning, feature development. Updates that took a week on a commercial platform could take us a month. As the web got more complicated, mobile, responsive design, e-commerce, accessibility, the gap between what we could sustain on our own and what the major platforms offered started to close fast.

We also had a perception problem. We thought "proprietary CMS" signaled technical depth. Prospects heard vendor lock. And honestly, they weren't wrong to be cautious. The market had plenty of horror stories about agencies that built clients on homegrown platforms and then went dark, leaving them stranded on something nobody else could touch. We weren't that, but we were fighting that association just by using the word.

The shift to Shopify and WordPress

Around 2018-2019 we took a hard look at where things stood. WordPress had matured into something we couldn't dismiss. Shopify had become the clear standard for e-commerce. Both had massive developer communities, regular security releases, and ecosystems that would've taken us years to replicate.

They'd also solved most of the problems that used to make them a hard sell. Customization had gotten way less painful. Security was handled by teams far bigger than ours. Performance improvements kept coming whether we were working on them or not.

We also had to think about what was ahead. Mobile had already forced a full rethink of web design. WCAG compliance was no longer optional given federal law, state laws, and a wave of ADA litigation. And AI was starting to show up in ways that were hard to ignore. We needed platforms with active communities solving tomorrow's problems without us having to fund that work ourselves.

Starting in 2020, we made the shift.

We didn't have to compromise

The big fear was trading capability for convenience and eventually telling a client "sorry, this platform can't do that." It didn't play out that way. WordPress handled everything propCMS did, plus a lot it didn't. Shopify covered e-commerce without the maintenance weight we'd been carrying. And because we understood web development at a code level, not just how to configure a platform, we could customize both without hitting the walls that catch developers who've only ever worked inside commercial platforms.

Yes, there are plenty of bad WordPress builds out there. Bloated, slow, plugin-dependent messes that break on updates and fall apart under real traffic. We've inherited a few. But that's not a WordPress problem, it's an experience problem. Developers who've never had to architect a CMS from scratch, think through database structure, or debug a security vulnerability at 2am on their own platform approach WordPress differently than we do. We know what's happening under the hood because we built under the hood for two decades. That's not something you get from a theme marketplace.

Those 20 years with propCMS are exactly why we build the way we do on WordPress and Shopify now. We know what good structure looks like, which shortcuts bite you two years later, and how to build something a client can actually own and hand off if they ever need to.

SEO got better too

WordPress has a well-earned reputation as an SEO-friendly platform. Clean URLs, logical site architecture, strong schema support, solid load times when built right. Pair that with Yoast or Rank Math and you've got a technical SEO foundation that would've taken us real effort to replicate on propCMS. Shopify covers the e-commerce side well: product schema, structured data, mobile performance, all handled out of the box.

The piece that often gets overlooked is how much WCAG compliance and SEO share the same foundation. Semantic HTML, proper heading hierarchy, descriptive alt text, clear link labels. These are accessibility requirements, and they're also exactly what search engines reward. A well-built accessible site on either platform is, almost automatically, a well-optimized one.

The AI bonus of accessibility

We'd been building WCAG-compliant sites for years before the switch. Our sister team Accessibility.Works does deep WCAG auditing and remediation, so accessibility was already baked into how we worked: semantic HTML, proper heading structure, labeled form fields, descriptive alt text. Standard practice.

What we didn't anticipate was how directly that would connect to AI.

AI agents, the bots that crawl websites on behalf of users to gather information and take action, parse web content much the same way screen readers do. They rely on structured HTML, semantic markup, and clearly labeled content to understand what a page is about. The Accessibility Tree that screen readers use is the same structure AI agents depend on. All those years of building for people with disabilities turned out to produce sites that are also well-suited for the next generation of visitors. WCAG compliance became AI Optimization before anyone was calling it that. More on that here: WCAG: Beyond ADA Compliance & Into AI Website Optimization

Clean structure works for chatbots too

AI chatbots are quickly becoming a primary way users interact with a site, often without navigating past the homepage. They work better when the underlying content is well-structured. When a chatbot is trained on your site or crawling it to answer questions, pages with logical hierarchy and clear headings perform well. Bloated, keyword-stuffed pages don't. WordPress and Shopify, built properly, produce exactly that kind of content architecture. The same foundation ends up serving SEO, accessibility, and AI.

WordPress is becoming an AI-native platform

One more reason we're glad we made the shift: WordPress 7, due April 2026, is bringing native AI agent connectivity to self-hosted installs. The short version is that AI tools like Claude will soon be able to draft, schedule, and publish content directly to WordPress without anyone touching the dashboard. Automated content pipelines, human review, one-click publish. The efficiency gains are going to be significant, and we'll be writing more about this soon.

Nobody plans to design for robots

When I started building sites in 1997, I was thinking about people. I had no idea I'd eventually care about whether a page was readable for an AI agent crawling it on behalf of a user who might never actually visit.

The decisions we made in 2020, moving to platforms with strong accessibility frameworks and structured content standards, turned out to be exactly what AI is now demanding from websites. We didn't know that at the time. We just knew we needed to stop swimming upstream.


Propeller Media Works has been building websites since 1997. We specialize in custom WordPress and Shopify development, digital accessibility, and WCAG compliance, based in Vermont. If your site needs a solid foundation for whatever comes next, let's talk.