Project walkthrough: our own website
A marketing website is a publishing system, an interface, and a set of operating decisions. Here is how those pieces come together on this site.
Explore the DecisionsThe operating brief
This is our own public website. It needs to explain technical services, publish long-form writing, and give visitors a clear way to start a conversation. It also needs to keep those basics available when an optional interaction cannot run.
The rebuild brought the public pages and publishing formats into a static Astro build. The homepage pairs readable HTML with an optional Three.js particle field that gives each part of the work a visible shape.
Architecture in practice
Astro generates the pages as static HTML. Shared layouts carry navigation, metadata, and the page structure; the Canon articles are generated from a content collection. A Cloudflare Worker serves the built files and handles the form and assistant endpoints separately.
What that changesThe publishing pages have a defined build output. The systems that receive a submission remain explicit runtime dependencies.
Articles have flat canonical URLs under /canon/ and a corresponding plain Markdown endpoint. Explicit redirects carry retired article routes, including the old category paths, to their current destinations. The sitemap, RSS feed, and text indexes are generated from the publishing collection.
What that changesA content change can be reviewed across the page, its alternate format, and the indexes that help readers discover it.
Bai Jamjuree fonts are served from the site’s own files. The Boston skyline has locally generated desktop, tablet, and mobile image variants. The image template specifies dimensions and loading priority.
What that changesTypography and imagery are part of the release, with responsive versions the site can serve directly.
The interaction, before and after
The homepage explains the practice in plain HTML: a statement and five panels, one for each kind of work. The enhanced version adds a single particle field that forms a picture of each panel as it reaches the middle of the screen.
The statement and all five panels, with their descriptions, are in the HTML. Nothing depends on JavaScript to be read.
One set of particles reforms for each section: a crystal beside the statement, then a web page, an interactive knot, connected systems, agents in orbit, and an infrastructure lattice. The same field runs across the site: a link carries the particles to the next page, the assistant borrows them for a body, and the privacy policy uses them to draw its own network requests.
The particle script and Three.js load once the page has rendered. The simulation runs on the graphics card: WebGPU where the browser has it, WebGL 2 elsewhere. Under a reduced-motion preference, each shape is drawn once and never animates.
If neither WebGPU nor WebGL 2 is available, or the script fails to load, the panels stand on their own; no copy waits on the canvas. Software-rendered graphics get fewer particles, and a device that can’t keep up gets still frames.
The field draws only while one of its sections crosses the middle of the screen, and stops in background tabs. Phones and touch devices get 14,000 particles instead of 36,000, with a lower pixel-ratio cap.
Continuity is part of delivery
A visible page is one representation of the website. Article metadata, Markdown, feeds, redirects, and discovery files also carry information about the practice. They need to agree.
Article canonical URLs use one flat structure under /canon/. The configured redirects map older article paths to current destinations. Articles credit their author, Douglas Choate, whose profile is the one Person in the structured data; contact details and company links use the Choate Catalysts organization.
That is also why a rebuild needs a URL inventory and a release checklist. Our WordPress migration and website consolidation guide shows the planning questions, URL decisions, and integration checks behind that kind of work.
Inspect the output
These are working parts of the website. Follow the links to see the rendered experience and the publishing formats alongside it.
Verification and ownership
The rebuild has been checked with responsive browser tests, automated accessibility scans, and JavaScript-disabled browsing. Browser checks cover the particle field, its hand-off between pages, reduced motion, the assistant, and a privacy page that must count no requests to anyone else.
The build also checks types, generated HTML, and publishing output. The deployment workflow runs browser and accessibility checks before its deployment job can proceed. These checks verify specific behaviors; accessibility and reliability still need ongoing review as the site changes.
The work continues after the first release: content changes, dependencies change, and the system needs a clear owner. That ongoing relationship is part of Managed Web Infrastructure.
Learn more about our capabilities in depth.