Case study · Beringia Marine
A consulting site, named plainly.
Sales engineering and consulting for marine-technology companies in San Luis Obispo. The earlier site let people get the firm wrong. The refactor made that impossible.
The job
Beringia Marine Technologies is a sales engineering and consulting firm. They work with marine-technology manufacturers — autonomous underwater vehicles, hydrography, subsea robotics — and end users across research, defense, and ocean exploration. They are not a survey company. They are not a manufacturer. They are not a product company. The earlier version of the site let people get those three wrong. The refactor’s first job was to make that impossible.
Constraints
The audience is split across three verticals — research, defense, ocean exploration — and three buyer types: manufacturer founders, end-user program managers, distribution partners. The same page has to read as competent to a Navy program manager and a startup CEO. No vertical-specific landing pages — the firm is one entity working across all of them.
The previous site was built on a template that had bolted on a class-booking widget, of all things, plus a layer of agency SEO debris. The refactor stripped that down and started over with a content model the team could edit without re-engaging me.
San Luis Obispo, not Santa Barbara — a detail the legacy data had crossed at one point. Get the location right and keep it right by sourcing it from a single constants file that the rest of the site reads from.
What I built
pnpm + Turborepo monorepo. Apps for the public site and the Sanity Studio. Shared packages for business config (the single source of truth for address, services, social links), UI components, transactional email templates, and test utilities.
Next.js 16 App Router, React 19, TypeScript. Sanity 4 for editable content: insights (articles, white papers, case studies, field reports, research summaries — five categories), partner solution pages, team bios, and a singleton `siteSettings` document for business identity, social links, OG defaults, and analytics IDs.
The static-vs-CMS split is deliberate. The five engagement phases — Validate, Execute, Grow, Productize, Scale — and the contribution timeline (ten items since 1998) live in code. They are positioning, not content. The team should not be able to silently rewrite the company’s brand by editing a CMS field. Insights, solutions, and team bios are editable; the firm’s identity is not.
The home page has a scroll-driven depth treatment. CSS custom properties shift the palette and typography as the page descends through five named oceanic zones — Epipelagic, Mesopelagic, Bathypelagic, Abyssal, Hadal. The effect suits a firm whose work happens in the ocean.
What I deliberately did not build
The previous site tried to be three things at once. The refactor removed two of them.
- No public class-booking widget — the legacy template carried one. The firm does not run classes; the widget had been carrying the brand into the wrong category.
- No survey-services pages — they are not a survey company, and pretending otherwise would have been the wrong kind of SEO lift.
- No manufacturer claims — they work with manufacturers, not as one.
- No pricing tiers — engagement is sized to the program, not a band.
What the team does without me
Sanity Studio for the editorial side: new insights, partner solution pages, team bios as the firm grows, `siteSettings` as social links or default OG images need to change. ISR revalidates within an hour of an edit.
The static positioning — phases, contributions, the address in San Luis Obispo — lives in `packages/config`. Changing it is a code change with review. That is the right friction for company identity.
Sentry tags errors by route and form, so a submit failure on `/contact` reads as “contact form, SMTP step” rather than “form broke.”
The site does one job: when someone lands on it, they know what kind of firm Beringia is by the end of the first scroll.