Pillars was founded in 2013 by investment bankers who were fed up with the quality of training their junior analysts received. Rather than complain about it, they quit banking and built their own training firm.

It worked. Pillars grew into a multi-channel training business spanning live corporate instruction, continuing education webinars and on-demand learning, sometimes reaching 500 simultaneous users logged at any one time.

But their technology was holding the business back from scaling.

Pillars' LMS was built on WordPress and managed internally by one of the founders. Over time, the system had become bloated with plugins, riddled with technical debt, and painfully slow — pages took 6 to 7 seconds to load. For a learner clicking through a course, that’s an engagement killer.

Pillars sold B2B, and their multi-tenancy tools were severely lacking. Data was delivered to corporate clients in raw formats rather than compelling dashboards that demonstrated the value Pillars was actually providing. They knew they couldn't confidently pitch to a client with 10,000 learners. The opportunity cost was enormous.

They tried to fix it. They worked with offshore development firms, but the experience was plagued by quality issues and back-and-forth communication that dragged across time zones. Each new agency inherited the spaghetti code left behind by the last, adding more patches to an already unstable foundation.

Meanwhile, the founder responsible for the platform was spending his days firefighting tech issues instead of growing the business. It became clear that no amount of patching would solve the underlying problem. 

The WordPress patchwork would always be inherently unstable without expensive, full-time support. And without a stable platform, the business couldn't scale.

Success starts with a Blueprint

Before writing a single line of code, we ran Pillars through our Blueprint process: a structured discovery phase designed to pressure-test the business model, map the technical requirements and surface risks before committing to a build.

Through workshops with the Pillars team, a few things became clear very quickly.

First, scalability was key. Pillars' loads were concentrated into short, intense windows, sometimes with 500+ simultaneous users hammering that generated a huge volume of server calls. The existing WordPress stack buckled under this kind of pressure, regularly throwing 404 errors during the periods that mattered most. Any new platform would need to handle these spikes reliably.

Second, the B2B data problem. Pillars' corporate clients needed to compare cohort performance, track completion, manage CE credits and understand whether their investment was paying off. But the data infrastructure was fragmented across multiple plugins and systems. Reports were either manual, inaccurate, or both. Building a compelling client dashboard was the difference between closing an annual renewal and losing one.

Third, the platform needed to support a business that was evolving. On-demand content was projected to grow into a dominant revenue source. That meant the system had to serve both the corporate buyer funnelling learners into live programmes and the individual retail customer discovering Pillars through organic search. Two very different journeys, one platform.

The Blueprint gave both teams the confidence to move forward with a clear scope, realistic budget and a shared understanding of what success looked like.

Designing for the buyer, the admin and the learner

One of the biggest design challenges with Pillars was that we weren't designing for one user. We were designing for several, each with fundamentally different needs.

First, the B2B buyer. These are decision-makers at banks, universities and non-profits evaluating whether Pillars is the right training partner. The marketing site needed to communicate credibility, make it effortless to understand the offering, and remove any hesitation about getting in touch.

Second, the B2B administrator. Once a corporate client has signed up, someone in their organisation is responsible for managing learners, tracking progress and reporting back on outcomes. These users needed a dashboard that made them look good at their jobs — clear data, easy enrolment tools, and a compelling view of the value Pillars was delivering. If the admin can't demonstrate ROI internally, the renewal conversation gets a lot harder.

Third, the learner. Some are employees assigned training by their employer. Others are retail customers investing in their own career development. Both need an experience that's intuitive, engaging and completely free of friction, because the moment a learner hits a technical barrier mid-course, you've lost them.

To design something that worked for all of them, we had to deeply understand each persona.

Start with what's broken

We started with a full audit of the existing system, including a review of session recordings, to see exactly how real users were interacting with the platform. Where were they getting stuck? Where were they dropping off? What was causing confusion? This gave us a grounded starting point and surfaced opportunities that Pillars hadn't previously considered.

Testing the experience on paper

From there, we moved into lo-fi wireframes. This is one of the most valuable stages of the process for our clients, because it lets you see the entire user journey mapped out before any visual design or development has started. Every screen, from landing on the marketing site, to discovering a course, to purchase, enrolment, completion and beyond. 

Changes at this stage are fast, cheap and collaborative. You're not reacting to a finished product and hoping it's not too late to change direction; you're shaping the experience in real time, while it's still made of boxes and arrows. It was essential that every journey was seamless, with zero friction and no technical barriers standing between a learner and completing their course.

This stage is deliberately collaborative. Pillars had multiple opportunities to feed back, challenge decisions and course-correct before a single pixel was designed or a line of code was written. That's the whole point. The earlier feedback happens, the less expensive it is to act on.

Bringing the platform to life

Then came the part where it all comes to life. Hi-fi design takes everything we'd validated in wireframes and turns it into a fully realised visual experience. 

Real branding, real content, real interactions. 

After months of workshops, wireframes and conversations, there's a moment where it stops feeling like a project and starts feeling like a product. 

For Pillars, that moment landed hard. This was no longer a patched-together WordPress site. It was a platform that looked and felt like it belonged alongside the best in the industry.

Development that doesn't repeat the past

Pillars had already experienced what happens when development lacks discipline. Spaghetti code, agency hand-offs, mounting technical debt. The whole reason they came to us was because previous builds had failed to deliver something stable and maintainable. So our approach to development needed to directly address that history.

We took a hybrid approach, combining proven, pre-tested components with custom development where it counted. Core functionality like course experiences, registration flows and payment integrations were built on components we'd already battle-tested across dozens of learning platforms. Custom work was reserved for the features that genuinely differentiated the product. For Pillars, that meant the multi-tenant dashboards, the B2B reporting tools and all of the user experience improvements that kept learners moving forward.

Development was run in two-week sprints. Each sprint delivered a working increment of the platform, and at the end of every sprint the client reviewed what had been built. This was a structured opportunity to test, challenge and request changes while the work was still fresh and easy to adjust. Pillars could see their platform taking shape in real time and course-correct as needed, rather than waiting months for a big reveal and hoping it matched expectations.

Every feature was tested by QA engineers who specialise in learning platform workflows before it reached the client. Automated monitoring ran alongside manual testing, and regression tests ensured that new features didn't break what was already working. Given Pillars' history of instability, this was the whole point.

The result was a platform the client owns. If Pillars ever want to bring development in-house or work with another team, the codebase is documented, maintainable and ready to hand over. That kind of long-term ownership was important to them, and it's built into everything we do.

A platform that gets better with age

Once development was complete, we migrated Pillars' existing users, content and data across to the new platform and launched without disruption to their business. But launch was never the finish line.

Over the following year, the platform continued to evolve. Some changes were proactive, suggested by our team as part of our ongoing commitment to improving the product. Others came directly from Pillars, informed by real feedback from their corporate clients and learners. Both are equally valuable, and both are a natural part of the process.

This is what separates a custom platform from an off-the-shelf solution. It's a living product. Every insight from users, every shift in the business, every new opportunity can be acted on. The platform doesn't sit still and it doesn't deteriorate. It improves with age, because there's a team behind it that's invested in making sure it does.

For Pillars, that meant a product that was better twelve months after launch than it was on day one. And it'll be better again twelve months from now.