Lawfty D2C

Content lives in a Pages collection. An editor writes a title, stacks the modules they need, and the slug is generated per locale. Everything goes through a draft and published state, so a page can be worked on and previewed without touching what's live.

The site is bilingual. English and Spanish live in the same document, each with its own slug, so the Español switch in the navigation is a language toggle on one page and not a second site to keep in sync.

Beyond free-form pages, the site is modelled around what the business actually publishes: attorneys, practice areas, locations and their landing pages, blog posts, FAQs and legal pages. Each has its own route. Adding an attorney means filling in a document, and the profile page appears. Redirects and vanity URLs are managed in the CMS too, plus an SEO fallback so a page missing its own metadata still ships with something sensible.

Blocks that repeat across pages are handled by a shared content type. An editor writes one once and reuses it everywhere, and the Studio offers a preset per module type, so you start from a real module and not an empty object.

These are some of the modules as they render on lawfty.com. Each one is a block an editor adds to a page in the Studio: the practice areas carousel, the numbered how it works steps, the settlements slider and the image with text block.

Typography is a set of tokens, so H1 through H6, subtitle, body, disclaimer and caption all come off one scale. An editor picks a level and it looks the same wherever that module ends up. Here is the whole scale, from the display headings down to captions.

The D2C components live in Storybook next to the CMS modules. The base layer is kept small: buttons, cards, inputs, selects, radios, checkboxes, a phone number input, text styles and icons, all built on the same tokens as the type scale above.

Icons come in two sets, a mono set for the interface and a duo tone set for practice areas. Each practice area has its own duo icon, picked by case type, and that is what the practice areas carousel renders.

Every CMS module has its own stories as well. The Hero has one for each variant an editor can pick, like a colour background with one or two CTAs, or a full width image with an anchor or chat CTA. The controls take the same block shape Sanity sends, so a story renders exactly what a page would.

Each module also has a story at every breakpoint we design for: 1920, 1440, 1280, 1024, 768 and 390. Checking a change across every width is a matter of clicking down the list, and the same stories are what the visual tests run against.

Navigation is driven from the CMS too, including the Practice Areas dropdown. Adding a practice area is a content change, not a deploy.

The legal pages are long and change often, so the table of contents builds itself from the headings in the document instead of being maintained by hand. The last updated date comes from the CMS as well.

The contact and attorney enquiry forms post to route handlers on our side, so Zod validates the same shape on the client and the server, and every submission is logged before it leaves the app.

D2C shares a monorepo with the firm sites. The Apollo client, the Redis cache layer, middleware, logging and env handling all come from one shared workspace, so a fix in either app benefits both. Sanity responses are cached in Redis and cleared through an authenticated refresh endpoint when content is published, with New Relic on the browser and server side.