Product-facing applications
TanStack Start pages, strict messages, semantic UI states, typed API clients, and persistent non-sensitive preferences.
Tanplate
Build the product. Keep the platform coherent.
Ship a user app, an operations console, and documentation on Cloudflare with authentication, data, content, consent, jobs, and observability already aligned.
Technology chosen to work as one system.
Each layer has a clear responsibility, from interface primitives to durable data and production operations.
React 19, TanStack Start, TypeScript, and Vite form the typed application layer across Web, Admin, and Docs.
A broad surface with deliberately narrow contracts.
- Independent product applications
- 3
- Optional product modules
- 12+
- Validated environments
- 3
- Auth tokens stored in client state
- 0
Platform architecture
From product interface to reliable operations.
Each layer owns a clear responsibility and reuses the same product contracts.
Trusted server core
Server routes, internal runtimes, domain packages, D1, and R2 stay behind typed service boundaries.
Asynchronous operations
Typed queues, cron retention, webhook verification, lease recovery, fencing, retries, and DLQ workflows.
Core capabilities
A coherent system, not a collection of demos.
The shared packages cover the boundaries that are expensive to retrofit after launch.
Authentication with explicit policy
Better Auth, provider intent, account linking, Turnstile, rate limits, and delivery policy share one security boundary.
Durable product data
Projects and user assets pair authoritative D1 state with isolated private R2 storage and repair workflows.
Git-managed publishing
Blog, changelog, and legal content are validated and indexed at build time with consistent SEO contracts.
Operational visibility
Restricted correlation IDs connect requests, queues, webhooks, jobs, delivery, and admin audit without leaking payload data.
Move from architecture decisions to product delivery.
Start with a working product surface, then enable only the modules your roadmap actually needs.
Progressive adoption
Add capability without hiding complexity.
Optional capabilities remain explicit, testable, and removable from the build.
Intent lives in configuration
A committed, validated Manifest describes brand, providers, environments, and enabled product surfaces.
Consent before side effects
Analytics and marketing stay off until a versioned consent snapshot allows the corresponding effect.
Disabled means absent
Enabled and disabled profiles preserve stable imports while preventing accidental runtime reachability.
Runtime flow
Trace the work without exposing the data.
One correlation path follows work from the browser to policy, asynchronous execution, and restricted observations.
request.trace200 · 184ms
- 1Validate the typed request
- 2Apply auth, consent, and rate policy
- 3Queue or execute typed domain work
- 4Record allowlisted outcomes
Ecosystem
Integrated where it matters. Replaceable where it counts.
Use proven infrastructure behind narrow adapters so providers can evolve without reshaping the product.
Cloudflare
Workers, D1, private R2, Queues, Cron, Turnstile, and Workers AI.
Better Auth
Shared sessions, social providers, account linking, delivery, and token policy.
Drizzle + D1
Typed schemas, migrations, local recovery tools, and shared domain adapters.
Workers AI
Constrained text rewriting with streaming, quota, cancellation, and provider isolation.
Deployment paths
Own the application and its operating model.
The application does not add a platform fee. Your operational cost follows the infrastructure and providers you enable.
Starter
Included
Use the core applications, shared packages, and local development workflow.
- Web, Admin, and Docs applications
- Manifest and environment preflight
Production
Usage based
Deploy enabled modules to your Cloudflare account and scale with actual usage.
- D1, R2, Workers, Queues, and Cron
- Recovery, retention, and audit workflows
Extension
Bring your own
Connect product-specific providers and workflows behind the existing contracts.
- Provider adapter boundaries
- Domain-specific extension points
Questions
Designed to be understood before it is extended.
Direct answers about configuration, deployment, data, and operational boundaries.
01How are optional modules turned on?
The public Manifest selects product intent. Build profiles keep disabled routes and runtimes out of the application.
02Where does application data live?
D1 stores authoritative records while private R2 buckets serve project media and user assets through controlled handlers.
03Can each application deploy independently?
Yes. Web, Admin, and Docs are separate applications with shared domain packages and independent deployment boundaries.
04What privacy controls are included?
Consent categories, strict analytics events, hash-only tokens, correlated audit records, and retention jobs are part of the platform contracts.
Team outcomes
Clarity for every team touching the system.
Representative outcomes for the roles that build, operate, and govern the product.
“The feature gates are visible in configuration and in the build, so product scope stays reviewable.”
“Domain packages let the admin and user applications share rules without sharing presentation concerns.”
“Recovery, retention, and audit workflows are treated as product infrastructure from the beginning.”
Stay current
Follow the work behind the product.
Occasional notes on architecture, product delivery, and maintaining a dependable platform.
Read the build notes
Email delivery is currently disabled; published updates remain available on the Blog.