CASE RECORD 01
Building SITEBORNE: a client-owned web system with optional AI and documented failure paths.
Ahead of its first published customer case study, SITEBORNE is sharing its own production system, built under the same rules it sells: client-owned infrastructure, optional AI, visible limits, and a documented exit. This record uses evidence that already exists in the repository, the build output, and the test suite.
Executive summary
SITEBORNE was created because the categories available to a buyer choosing a web provider are each missing something specific: conventional agencies rarely publish inspectable technical evidence; AI-forward shops rarely document what happens when the AI is wrong or unavailable; platform-based builders rarely give the client full account ownership; and solo providers often look either technically narrow or commercially incomplete. SITEBORNE's own site was built to demonstrate the category it intends to sell—client-owned web systems for expert businesses—rather than simply describe it.
This record proves that SITEBORNE applies its stated standards to its own build: measured performance, automated accessibility checks, a real (not promised) data-retention job, corrected claims found during self-review, and a documented ownership model. It does not prove customer satisfaction, revenue impact, or delivery capacity at scale—those require real client engagements, which is exactly what the project brief exists to start.
INITIAL PROBLEM
The strategic problem SITEBORNE was built to answer.
Buyers evaluating a web provider are commonly asked to trust adjectives: "fast," "AI-powered," "enterprise-grade." Separately, an AI-forward provider may promote a capability without documenting what happens when it fails or is turned off, and a client may not actually control the domain, production account, or data the finished system runs on. None of this describes every agency—it describes a gap SITEBORNE was built to close for itself first.
Design constraints
- Low operating cost on documented, verifiable provider allowances
- Client-owned production account and billing from day one
- Static-first public delivery with isolated dynamic routes
- Accessible interaction, including a JavaScript-disabled critical path
- AI present only where retrieval or a bounded task earns its place—never required
- Every provider allowance documented with its fallback and upgrade trigger
- Public proof without exposing a single production secret
- No fabricated customer evidence, ever, including under commercial pressure to add some
STRATEGIC DECISIONS
Decisions made against a stated alternative, with a named tradeoff.
| Problem | Alternative considered | Decision | Tradeoff introduced |
|---|---|---|---|
| Six services read as six unrelated businesses | Keep a flat, equally-weighted service menu | Reframe Web Systems as the foundation, everything else as an extension | Some visitors who want Creative Systems or Care first have to click one level deeper |
| The most common competitor lead magnet is an email-gated "free audit" that crawls a submitted URL | Copy that pattern with SITEBORNE's own crawler | Build a private, client-side System Review: eight questions, scored in-browser, no email, no URL fetch | Cannot claim to have "audited" a specific visitor's live site—only their self-reported answers |
| Retention policy was described in prose but not enforced by any code | Leave it as a documented policy, enforced only by manual review | Add a database column and a scheduled deletion job, and publish the job's own status | Adds a migration, a cron dependency, and one more thing that can itself fail and need monitoring |
| A generic "provider-neutral architecture" claim in the footer did not match a Cloudflare-concentrated stack | Leave the phrase—it is common industry language | Replace it with "Cloudflare-first with replaceable provider boundaries" | Less impressive-sounding; more accurate |
Evidence for each row is a specific file or page state, not a general impression—listed in the source notes below each decision during internal review.
Architecture Lens
The system is organized so a visitor gets a fast, understandable page by default, and every optional capability—search, AI, agent tools—degrades to a conventional path instead of breaking the primary experience when it's unavailable.
Presentation is static Astro with isolated interactive islands. Content is typed collections and structured config. Application routes are narrow Cloudflare Workers. Durable records live in D1; expiring state and rate limits live in KV; approved files live in R2. Retrieval runs through Vectorize with a keyword fallback; generation runs through a provider-neutral Model Gateway with hard caps and an off switch. Agent tools are typed MCP contracts with human-approval boundaries. Monitoring is a scheduled Worker writing status to D1 and R2.
VERIFIED EVIDENCE
Only measurements with a method attached.
| Metric | Verified value | Method |
|---|---|---|
| Compressed CSS | 16.7 KB Measured | Repository build output, measured at build time |
| Compressed JavaScript | 91.4 KB Measured | Repository build output, measured at build time |
| Conservative payload composition | 303.4 KB Measured | Largest HTML + browser assets + largest production image, summed |
| Automated accessibility runs | 28/28 Measured | Axe automated checks across critical routes, desktop and mobile |
| Unit tests | 59/59 across 30 files Measured | Vitest, run on every change described in this record |
| Public routes | 61 Measured | Enumerated by scripts/verify-routes.mjs against the live route tree |
| Signal Modules | 12 Measured | Count of entries in the authoritative module configuration |
| Field Guide entries | 12 Measured | Count of published entries in the resources content collection |
Verified August 3, 2026. Full machine-readable output: /proof.json. Automated testing supports verification; it does not establish complete accessibility conformance or certification.
WHAT CHANGED DURING DEVELOPMENT
A system that responds to evidence, improvement documented as it happens.
Every SITEBORNE page has been through at least one round of self-directed review, and each resulting improvement is listed here rather than folded quietly into a first version—because a system that shows its own progress is easier to trust than one that only shows a finished result.
Category and funnel rebuilt
Homepage rewritten around "client-owned web systems for expert businesses," a three-step funnel (System Review → Composer → Project Brief) replaced a single email-gated form, and the primary nav was refined during internal review so every step carries its own distinct number.
Module allowance data aligned to one authoritative record
An internal audit brought the module catalog, Module Lab, and detail pages into agreement on the real operating constraint for three modules: SiteSentinel now leads with Browser Run minutes, ProofVault with R2 storage, and LeadBrief with D1—matching what each module actually depends on first.
Retention policy built, not just described
A 90-day automatic deletion policy for unqualified inquiries was written into the Privacy page and then actually built: a database migration added a retention-hold column, and a scheduled Cloudflare Worker now runs the deletion daily and records its own outcome.
Privacy hash strengthened with daily rotation
While documenting the Signal Strategist rate limiter for the Privacy page, the per-visitor identifier was strengthened to rotate automatically: the date is now part of the hash input, so the stored value changes every day instead of staying fixed.
Architecture language made more precise
Two broad claims in the architecture scenarios were rewritten to describe exactly what the system delivers: a reduced failure surface and an evaluated provider swap, giving readers a precise, verifiable picture rather than a general promise.
Field Guide expanded from 2 to 12 entries
Ten new entries were researched and written to the same disclosure format used from the start—including one that documents a real limitation of the site's own monitoring setup alongside the more flattering topics, keeping the format consistent either way.
Sourced competitor pricing published on the Proof page
Before publishing any comparison, each competitor's current pricing page was independently fetched and read rather than copied from secondary sources. Only figures that could be verified directly were published.
Design-tooling addition measured and optimized
Two animated components were added using their original library implementation. Measured directly at roughly 44 KB gzipped, the same visual result was then rebuilt on native CSS instead—identical experience, zero framework cost. The original components stayed available for projects that want them: see /design-lab/.
OWNERSHIP AND EXIT
What a client keeps if this were their system.
- Domain, once connected to a client-owned registrar
- The Cloudflare production account, billing, and recovery credentials
- All source code, in a repository the client controls
- All content, structured and typed rather than locked in a proprietary format
- Documented operating and migration procedures
What stays separate
- SITEBORNE's own reusable methods and internal tooling
- Open-source software, under its own license
- Third-party provider services, under their own terms
- Any licensed component, disclosed at the point of use
WHAT THIS CASE PROVES
- The architecture SITEBORNE sells is the architecture SITEBORNE runs
- Performance and accessibility claims are backed by a measurement, not an adjective
- A stated policy (retention) was actually implemented, not just written down
- Self-review drives continuous improvement, tracked in the open
- Competitive claims are checked at the source before publication
WHAT THIS CASE DOES NOT PROVE
- Customer satisfaction—there is no customer yet
- Revenue, lead, or conversion impact for any business
- Delivery capacity across multiple simultaneous engagements
- Performance under real, unpredictable visitor traffic
- Legal or regulatory compliance for any specific industry
Need the same ownership, verification, and fallback discipline applied to a real system?
Start with a private System Review or a scoped project brief—neither requires trusting an adjective first.