Skip to content

Websites & Platforms

A website your organization can grow into.

Websites with a structure people can find their way through, on a platform your team can run.

Solutions · Digital Product

Organizations replacing a website have often outgrown its structure before its design. We plan the content, design the experience and build on a modern platform, currently Sanity and Next.js for most projects.

Your team gets an editing studio set up around what they publish.

Why sites stop working

At launch

A website usually fails slowly. It starts well organized. Then a new program gets a page, a department gets a section, a campaign gets a microsite, and each addition makes sense on its own.

A few years later

There are thousands of pages, several audiences, and a navigation that reflects the org chart from two reorganizations ago. People can’t find what they need, so they search, and search returns five versions of the same thing because editors copied content instead of finding the original.

The platform

Plugin-heavy sites age badly. Every update carries risk, performance drifts, and each feature adds code nobody fully reviews. The team starts avoiding changes, which is the opposite of what a website is for.

A redesign

New templates on the old structure give you the same confusion with better typography.

Content architecture comes first

  1. People

    We start with two groups of people: the ones who use the site and the ones who keep it running. Visitors want to find their answer quickly. Editors want to publish without breaking anything.

  2. Inventory

    A content inventory covers every page that exists: what it’s for, who owns it, and whether it’s still true. Each one gets a decision to keep, merge, rewrite or retire.

    This is slow, unglamorous work, and it’s where most of the value of a rebuild is decided.

    • Keep
    • Merge
    • Rewrite
    • Retire

  3. Structure

    From there we design the structure: a sitemap and audience pathways built around what people come to do, and a content model that describes your content as structured types (programs, locations, people, events, services, answers) with the fields each one needs. We test navigation and labels with real users before the build, using simple prototypes, because structural problems are far cheaper to fix on paper. That structure is the foundation for the CMS, whichever platform it’s built on.

What headless changes

Where does your content live?

  • In an older CMS

    Content lives inside the website.

    It’s written into pages, wrapped in that site’s layout, and it only exists as those pages.

  • Headless

    Headless separates the two.

    Your content is stored as content, and the website is one thing that reads it. So can a mobile app, a screen in a lobby, a partner’s site, an email, or an AI assistant answering a question about you. Change it once and it changes everywhere.

Structure also shapes how people find you now

A good content model is now part of how your organization is described in places you’ll never see.

Search assistants and AI tools increasingly answer questions before anyone visits a site. They read structured, well-labelled content accurately. A tangled site gets summarized badly, or skipped.

How we build it

Sanity and Next.js, for now

Our current default is Sanity for content and Next.js for the front end, on a modern host like Vercel. We choose it because it’s fast, secure and flexible in design, and because AI coding tools work well with it, so later changes stay quick to make. When a project’s budget, team or content calls for something else, such as Storyblok, Webflow or WordPress, we say so and use that, as part of a larger piece of work. Recent Sanity builds include Veterans Walkway and AI for All.

An editing studio built around your team

We configure the editing studio around what your team actually publishes, with previews, sensible defaults and guardrails, so a program manager can add a program without learning the whole system. The front end is built with AI-assisted development and reviewed by people who know what good code looks like. Accessibility is part of the build, along with performance and security.

All of it, or alongside your developers

We can build the whole thing, or design the product and build the front end while your developers own the back end. Both work well when roles are clear from the start.

What gets easier

  1. Answers people can find

    With a clear structure, and search where the content needs it, visitors could find their answer without wading through five versions of it.

  2. Publishing without a developer

    Trained on a studio built around their work, editors could add a program or a page themselves.

  3. A clean switchover

    Old links could still land, and your numbers could carry on from launch day.

  4. Room to grow

    New programs could slot into the structure without a microsite of their own, on a design system later hires can build on.

The platform choice should follow from your content, your team and how long the site needs to last.

Headlessornot?

A team or partner that works in code

Go headless.

Content you can reuse across channels, and a site your team isn’t afraid to change.

A simple site, a team happy with its platform and no plans to add channels

Stay where you are, for now.

If that’s where you are, we’ll say so. The structural work still pays off on any platform.

Related

The expertise behind it

All expertise