The Porcelain Tech Studio Website

The challenge

Porcelain Tech Studio opened without a portfolio. A studio that sells websites, apps and WeChat Mini Programs cannot lead with promises, so the first build had to be our own site — and it had to hold up under the same scrutiny we ask clients to apply to us.

Three constraints shaped it. It had to work in English, Chinese and Spanish, with each language reading as if it were written first rather than translated last. It had to make our own service claims measurable: "we reply within one business day" means nothing unless the response time is a number somebody can query. And it had to be the first real implementation of the delivery foundation we intend to reuse — Next.js, FastAPI, PostgreSQL — not a throwaway marketing page.

What we built

Five tabs — Home, Work, Pricing, Team, Contact — fully localized across three locales from a single content model, so a new page or a new language is a content change, not a rebuild. The visual language is borderless and modern: type, spacing and color carry the structure instead of boxes and rules.

The lead pipeline treats the database as the source of truth. A submission is written to Postgres first and email is only a notification. If the mail provider is down, the lead still exists and still shows up in the inbox.

• Rate limiting lives in Postgres, not in process memory. Serverless instances share no memory, so an in-memory counter is a counter per instance — which is no limit at all.
• Spam is absorbed by a honeypot field instead of a CAPTCHA, so real visitors never have to prove they are human.
• An admin inbox stamps a first-response time on every enquiry, turning the 24-hour SLA into something we report on rather than assert.
• Analytics and error monitoring went live on day one, not after the first incident.

The backend exposes one API contract. The web client consumes it today; an iOS app, an Android app or a Mini Program can consume the same endpoints without a second backend.

Outcome

The site ships in three locales with parity across all five tabs. Performance was a build constraint rather than post-launch cleanup: an LCP budget under 2.5 seconds on mobile and a Lighthouse target of 95+, checked before merge instead of after complaints.

More usefully, it is now the reference implementation. Every stack decision here — the shared API contract, the database-backed rate limiting, the localization model, the monitoring setup — is the starting point for the next client build, already exercised in production on a site we own.