Page Builder

Pinpoint's LMS let clients build standalone resource pages for things like product highlights, directories, training hubs, and internal campaigns. Useful feature, rigid process.

Every resource page needed its own custom template. A client had to define what the page was for, specify the exact fields they wanted to edit, and then wait for an engineer to build a dedicated template for that one use case. That template only worked for that client, and it only took the exact shape it was designed for. If the client later wanted a different structure, or another client wanted something similar, that was usually more custom work and another engineering ticket.

So the feature was useful but expensive, and clients bought it sparingly. Every new page type carried real cost and pulled engineering time, which kept a genuinely useful capability out of reach for most of the people who could have used it.

Enterprise LMS clients, specifically the administrators responsible for building and maintaining their organization's content pages. They had real content they wanted to publish but kept hitting the cost and the wait time of the custom-template process.

The backend already had part of a template system in place. It wasn't perfect, but it was enough to build on, and any solution had to use it rather than propose a platform rewrite. Whatever I designed also had to be operable by non-technical client admins with no training, and constrained enough to keep the resulting pages consistent and supportable.

I started by looking at how the existing resource-page templates were actually put together. The pattern jumped out fast: the same kind of request, over and over, from different clients. A product launch page. A compliance campaign page. An onboarding page. Each one became its own engineering ticket, and each one was functionally similar to the last. The backend already had an admin-facing template system doing this work, even though it still needed an engineer to create the view files. The real question was whether that system could be used differently.

At first I entertained the idea of just making custom templates faster to build, but quickly realized that it solved the wrong problem. A better solution would be to remove the engineering bottleneck entirely.

So I asked an engineer whether a single page could support multiple templates, where each template was a section instead of a whole page. From his side it was an easy wire-up. That one answer turned a large platform rewrite into a realistic product improvement, because the thing I needed already mostly existed. I just wanted to use it at a different scale.

Reframe templates as sections. A template used to control one full page. By turning templates into reusable sections, the same underlying system got dramatically more flexible. Clients could assemble a page out of parts instead of commissioning a brand-new layout every time they had a new idea.

Build on what was already there. Rather than pitch a rebuild, I worked with engineering to understand what the existing system could already do. That made the idea cheaper to build, easier to justify, and much faster to get into clients' hands than anything that started with "first we rewrite the platform."

Give clients control without inviting chaos. A fully open canvas would have produced inconsistent, unsupportable pages and endless edge cases. Instead the builder used predefined section types with controlled fields. Clients could choose, combine, edit, and reorder sections freely, but every section kept a reliable internal structure.

Make the upsell repeatable. Because the builder was section-based, new capability could ship as expansion packs: new section types, new layouts, new variants. A feature that used to be one-off custom service work became something with a real product roadmap and a way to keep selling into it.

A modular page builder built on about twelve out-of-the-box section templates: banners, card groups, text blocks, training blocks, media sections, text and image combinations, document directories, event promotion blocks, and variants for different layouts and emphasis.

Clients and internal admins could add sections, edit their fields, reorder them, and build whatever page type they needed without commissioning a new template. The same builder covered training pages, product launches, personnel directories, sales enablement, events, and other internal hubs. I designed the section-based experience and built the CSS presentation layer.

A costly feature that clients bought sparingly turned into a flexible system they could actually use and keep expanding.

The custom-template bottleneck went away. New resource pages no longer needed an engineering ticket each, which freed engineering time and gave clients and their admins direct control over how their pages came together. The builder became a popular client-facing feature across several enterprise accounts, and a number of those clients later bought the expansion packs I designed, which added new section types and variants on top of the original set.

The part I'd point to isn't any single page it produced. It's that spotting one repeated pattern, and asking whether the existing system could be pointed at it differently, converted an expensive bespoke service into a product that scaled and kept generating revenue after it shipped.