Building Something We Could Share (CC-0002)

The Next Site Was Always Better

At the end of my first Code Commit, I asked a practical question: What do most websites actually have in common? I had actually been working on that problem long before Base 4 Designs had a name. Like most developers, I didn't want to build the same thing over and over again. When I created something useful for one website, I wanted to be able to use it again. That led me to build a component library where I could collect the different pieces I had created and use them across future projects. It worked. But it created another problem. The next website was always better than the last one.

Every project taught me something. I would find a better way to build a component, improve its accessibility, simplify the code, add a feature, or rethink how it should behave. The component library meant the next project could benefit from everything I had learned. The sites I had already built couldn't. They stayed where I left them. There is something strange about accepting that in software because we don't expect it anywhere else. If you knew me years ago, you might not have liked me as much as you do today. We all grow. We learn from mistakes. We gain experience. We find better ways to do things. Hopefully, the person you meet today benefits from everything I've learned along the way. I wanted the same thing for the websites I built. I didn't want every site to become a snapshot of how well I could build something on the day it launched. I wanted the work I did yesterday to benefit from what I learned tomorrow. Base 4 Designs gave me an opportunity to do that. Each day we get better. Each day you get a better us. I had created reusable components, but I hadn't yet created a system for sharing their continued improvement.

Reusable Wasn't Reusable Enough

The goal wasn't simply to save myself some development time on the next website. If that were the only problem, the component library was already doing its job. I wanted improvements made for one organization to become improvements available to everyone. If I built a better photo gallery, I didn't want five slightly different copies of that gallery spread across five websites. I wanted one capability that could continue improving. Fix a problem once. Improve accessibility once. Add a feature once. Make it faster once. Then let everyone benefit. That meant I needed to stop thinking about reuse as copying something I'd already built and start thinking about sharing the thing being built. That was a much bigger change.

Different Sites, Same Foundation

Sharing components creates an obvious problem. Organizations don't want identical websites. A church doesn't want to look like a veteran's portfolio. A small business doesn't want to look like either of them. Each organization has its own identity, colors, typography, content, priorities, and way of communicating. The answer couldn't be to make every website the same. The answer was to separate the part that could be the same from the part that shouldn't be. The core component could be shared. The configuration could belong to the organization. Instead of creating another version of a component every time someone wanted it to look or behave differently, I could make the component configurable and store those decisions in the CMS. One gallery. Different presentations. One navigation system. Different structures. One collection of capabilities. Different websites. That changed the economics of the idea too. Repeated work costs time, and time costs money. If I could stop rebuilding things that had already been solved, the cost of providing a capable website could come down without removing the things that made each organization unique. Better yet, the relationship didn't end when the website launched. The shared foundation could continue improving.

Bringing the Pieces Together

I wasn't starting from scratch. Before Base 4 Designs became a multi-tenant platform, I already had several pieces of the system operating independently. I had a headless CMS for managing content. I had a Svelte frontend for presenting that content. And I had the component library I had built to reuse the visual pieces that went into the sites. There were good reasons for those separations. I wanted the public-facing site separated from the systems responsible for managing its content. I liked Svelte as a frontend framework, and server-side rendering gave me greater control over what work and information remained on the server. The component library gave me a place to develop reusable visual capabilities independently of any one site. Those pieces worked.

The problem was that I now wanted them to solve a problem together. On March 19, 2026, those existing systems began coming together into a unified system. The first Base4Mono commit wasn't the beginning of Base 4 Designs. It was a restructuring of things that already existed. That distinction matters because the decision wasn't, "Just smoosh it together." The decision was, These systems need to evolve together. The CMS needed to understand the capabilities available to a site. The components needed to accept configuration instead of being repeatedly customized. The frontend needed to render those shared capabilities using each organization's content and identity. They still had different responsibilities, but developing them as completely independent projects was beginning to work against what I was trying to accomplish. So I brought them together.

More Than a Component Library

The original component library wasn't only about reusing code. It also gave me a way to show clients individual pieces of a website before their entire site had been built. They could see what was available, understand how it looked, and make design decisions without waiting for everything else to be finished. When those components became part of Base 4 Designs, I wanted to preserve and expand that idea. That was where Storybook became useful. Storybook provided a visual library of the components available to a site. Instead of simply knowing that a component existed, someone could see it. They could explore how it was presented, understand the options available to them, and see how it could be used as they added, removed, or reorganized content on their site.

It also provided something else I knew would become increasingly important: documentation. A reusable component isn't very useful if nobody understands what it does or how to use it. Storybook gave the visual component library a place to carry its own presentation documentation alongside the component itself. It could support the initial design conversation, but it could also remain useful afterward as a reference for the people actually managing the site. That fit the larger direction of Base 4 Designs. I didn't want to deliver a website that depended on me every time someone wanted to change something. I wanted to provide the tools, show how they could be used, and let organizations continue telling their own stories. Like many decisions documented in Code Commits, Storybook wouldn't be the final answer. But it solved the problem I had at the time.

Lessons Learned

I started this part of the journey thinking reusable components were the answer. They were only part of it. A component library made it easier to reuse what I had already built. A shared platform offered something more valuable: the opportunity to share what I would build next. Reuse saves work. Shared improvement compounds it. Every improvement to the common foundation could make every site better. At the same time, moving organization-specific configuration into the CMS allowed each site to remain its own. That combination, shared capability with individual identity, became one of the foundational ideas behind Base 4 Designs. More importantly, it changed what happened after launch. A website didn't have to represent the best work I could do when I built it. It could continue benefiting from the best work I could do today. Each day we get better. Each day you get a better us.

Looking Forward

Bringing the pieces together solved one problem and immediately exposed another. If Base 4 Designs was going to contain a growing library of shared capabilities, simply having those capabilities wasn't enough. Not every organization needed every component. Different organizations needed different configurations. And giving someone access to a component didn't mean they should have to configure every detail from scratch. The question was changing again. How do I separate what the platform can do from what each organization is offered and how it should work for them? Answering that question would begin turning a collection of shared components into a configurable platform.

Repository Status

• Epic: Base 4 Designs
• Story: Building Something We Could Share
• Branch: feature/shared-foundation
• Status: Merged to main