Most websites are built around pages. A database-driven website is built around connections — and that difference changes everything about how you write, how you organize, and how visitors find their way.
What is a database-driven website?
Most websites are a stack of pages. Each one is written, laid out and updated on its own. A database-driven website works differently. It stores your content as individual pieces of information, like a staff member, an event, an action or a resource. Then it builds the pages from those pieces automatically. You don’t write a page about each thing. You describe each thing once, and the site works out where it should appear.
Think about a staff directory. Each person is one entry with a name, title, photo, bio, and department. That one entry can show up on the team page, on their department’s page, next to the blog posts they wrote, and alongside the projects they led. Events work the same way. Add a date, a location, and a topic, and the event appears on the calendar, on the related program page, and in “upcoming” lists across the site. When the event is over, it moves to the archive without anyone touching it. Resources, such as guides, downloads, and videos, can be tagged by audience or subject and show up wherever a reader needs them. Actions are concrete next steps, like “call your representative” or “sign up to volunteer.” They can be linked to every topic they relate to, so the next step is always one click away.
database examples
Here are a few examples of content a database can manage.
Staff
Every team member profiled with title, department, and a short bio — pulled from a single custom post type so editors can add or retire staff without touching code. New hires appear across the site (team page, program pages, event hosts) the moment they're published.
start with the data, not the pages
When you think about a database-driven website, you think about the data first — and almost immediately, something loosens up. You stop asking “what goes on this page?” and start asking “what connects to what?” That shift is genuinely liberating. It means you can build a process around who manages the content, how much of it needs to change, and what triggers those changes — without constantly worrying about the connective tissue that holds it all together. Build the connections first. The pages follow.
That’s exactly how we approached Circle of Change, Barbara Clarke’s site about American healthcare reform. Barbara was working with a vast topic — one of the most contested, emotionally charged subjects in public life — and the first instinct, the obvious instinct, would have been to build a blog. A series of posts explaining the problem. The scope of it. The history. The villains. Most advocacy sites are built this way: spend enormous energy convincing you the problem is real before they ever ask you to do anything about it.
the pivot
The aha moment came when we realized the site shouldn’t talk about problems at all. It should talk about solutions. Simple, prioritized, specific things people can actually do — what to do, who to talk to, what to say. That single realization pivoted the entire database architecture. Instead of organizing content around healthcare issues, we organized it around actions.
Someone who thinks the healthcare crisis is driven by Big Pharma and someone who thinks it’s a Congress problem can still agree on a concrete next step: call your representative, learn about food and farming, partner with your physician.
Barbara designed Circle of Change around a belief worth pausing on: you don’t have to share a villain to share an action. Solutions are more unified than diagnoses. It’s not important to build consensus about the problem — it’s okay for people to have different takes on it. What matters is the next move, and the database architecture makes that philosophy structural.
how the pieces connect
At the core of the site are sixteen interconnected domains — areas where change needs to happen, like Big Pharma, Congress, and Nurses — grouped under three roots: Health, Business, and Government. Actions are the “ideas for change”: concrete steps linked to one or more domains, each tagged with a priority. A visitor exploring the Food / Farming domain automatically sees every related action, sorted by priority and then by title. No manual curation. No page-by-page updating. When Barbara adds a new action and connects it to a domain, it appears everywhere it belongs.
The blog works the same way. Each post can link to any number of actions, so a piece about a food-industry monopoly can end with a direct path to doing something about it — and that path leads back into the larger framework. Tags and categories appear more than once on a page on purpose, giving readers several ways to jump to related topics. Posts bring people in through timely stories; the linked actions and domains keep them exploring once they arrive.
This structure lets the site serve very different readers from a single set of content. A newcomer can start with the Circle introduction and browse by domain. A reader who is already engaged can go straight to “Get Engaged!” for the full prioritized action list. A subscriber who follows the blog meets new ideas each week and finds each post pointing back into the larger framework. Barbara’s own philosophy fits this design exactly: you can begin anywhere in the circle, focus on one element, and let one success build momentum toward the rest. The database makes that literal — every entry point leads to the rest of the circle.
the misstep that became a method
One of the more satisfying discoveries along the way was also one of the accidental ones. We realized that the relationship between actions and domains could mirror itself: map an action to a domain, and the domain maps back to the action automatically. What started as a technical observation became a whole way of thinking about the work. Building connections started to feel like making a little spider web — each new thread pulling everything tighter, the structure strengthening itself as it grew. Once we saw it, we couldn’t unsee it. The divide-and-conquer approach — breaking actions down into their simplest, most specific form — made everything flow.
The database makes that literal — every entry point leads to the rest of the circle.
Barbara put it this way: “All I had when I partnered with Shew Design was an idea and the hope that they could translate my mission into a brand and a multi-faceted website. The Shews applied their talents and created a way to reach subscribers while providing easy navigation of interconnected topics. Shew Design created more than I could have imagined, and my subscribers are loving it.”
That’s what a database-driven website can do when the architecture starts with the right question — not “what goes on this page?” but “what belongs together, and why?”