Studio Site Rebuild

The problem

The existing studio site had inherited the assumptions of a SaaS starter rather than the needs of a small software studio. The public site mixed old positioning with template pages and technical SEO defects, while the runtime carried more framework and deployment surface than the website required.

What existed before

The old production site was based on a ShipAny / Next.js / OpenNext lineage. Public evidence included placeholder Blog and Showcases pages, duplicate canonical output, a sitemap pointing at your-domain.com, and metadata tied to an outdated creator-economy positioning.

The hypothesis

A content-first studio site should be simpler and more trustworthy if its architecture follows the product: static HTML for public pages, Markdown/MDX for evidence and writing, bilingual URLs, and dynamic services kept outside the site until a real need appears.

The first test

Freeze the old site's observable URL and SEO behavior, create a clean repo with no compatibility burden, build the bilingual information architecture in Astro, deploy it to an isolated Cloudflare Workers Static Assets hostname, and test status codes, canonical/hreflang output, raw HTML, crawler eligibility, and responsive behavior before touching production.

What we built

A static Astro 7 site with English and Simplified Chinese routes, Projects and Journal content collections, one canonical per indexable page, reciprocal hreflang plus x-default, generated sitemap, environment-aware robots policy, true 404 behavior, trailing-slash normalization, and an isolated Cloudflare staging deployment. The homepage was then rebuilt as a reversible Opening → Focus → Release → Expanded scroll narrative while keeping the underlying content as a single semantic DOM and preserving no-JS, reduced-motion, tablet, and mobile fallbacks.

Evidence from use

The accepted build passes Astro checks with zero errors, warnings, or hints. Isolated Cloudflare acceptance reproduced the reversible homepage narrative at 1440×900, confirmed normal-flow fallbacks at 375px mobile and 1024px tablet, preserved reduced-motion and raw-HTML usability, kept document scroll width equal to viewport width, and returned a true 404. The production cutover then moved the same apex Custom Domain object to a dedicated Static Assets Worker while temporarily preserving the legacy Worker as a rollback boundary. Immediate live crawl and Chrome regression confirmed the bilingual routes, canonical/hreflang, redirects, sitemap/robots, Email + X contact state, true 404, and no horizontal overflow. After post-launch acceptance stabilized the new production path, the unused legacy Worker and its dedicated D1 database were retired.

Where it stands

V1 is now live at inkblocklab.com on a dedicated Cloudflare Workers Static Assets service. English and Chinese ship together with the accepted SEO, redirect, responsive, accessibility, and Email + X contact contracts. The old ShipAny/OpenNext production Worker and its dedicated D1 database have been retired; current production has no dependency on that legacy runtime. Inkblock Lab remains the provisional V1 public identity, and the optional locale suggestion is still deferred.

What we learned

• A starter template is useful only when its assumptions match the product; otherwise its included features become architecture debt.
• Migration should preserve useful URL and search equity, not runtime compatibility for its own sake.
• Technical visibility is easiest to verify before production: status codes, canonical URLs, hreflang, raw HTML, crawler access, and 404 behavior can all be acceptance tests.
• Responsive screenshots are evidence only when the test viewport is real; a headless browser's minimum window size can create false overflow signals.

Capabilities

Web engineering · Cloudflare · Technical SEO · Internationalization · Product architecture

Why this project belongs here

The studio website is not a portfolio decoration. It is part of the product system: it explains what the studio does, stores evidence, publishes decisions, and provides the entry point for future client work and products.

That made it a useful first test of the studio’s own operating rule: start with the real job, remove assumptions that do not serve it, and make the smallest architecture that can be tested honestly.

What we deliberately did not migrate

The previous codebase had already been deleted, and recovering it was not a requirement. More importantly, the new site does not need authentication, subscriptions, credits, dashboards, RBAC, a database, or a server-rendered application runtime.

The migration therefore kept the things that can carry business value — domain history, observable URLs, potential redirect equity, and public evidence — while dropping the old implementation contract.

Why release stayed separate from build work

By the pre-cutover checkpoint, the homepage, English and Chinese localization, contact surface, production build, and crawl rehearsal had all passed their own acceptance. The long-term brand name still remained intentionally unfrozen, while Inkblock Lab was authorized for V1 public use.

Production cutover was therefore treated as a different kind of task: identify the exact legacy Cloudflare binding, make rollback deterministic for the cutover window, freeze redirects from real search/backlink evidence, then verify the live site after switching. The cutover completed with the new Static Assets Worker on the apex while the old Worker was initially preserved unchanged as a temporary rollback boundary. After subsequent production releases and regression checks established the new path as the operating baseline, the unused legacy Worker and its dedicated D1 database were retired. That separation prevented content or interface work from quietly becoming a production infrastructure change.

The conditional locale suggestion remains optional and deferred; its absence is not a reason to keep polishing the already-shipped V1 homepage.