Most agencies sell features. The Service Site Standard sells a posture, which is a set of seven commitments about how the work gets done every time. The rest of the site is just evidence of those commitments in practice. If you have already read the technical approach, the service agreement, the owner's guide, and the changelog, then you have already seen the Standard at work, and this page simply gives it a name.
1. One owner, end to end.
The person who picks up the phone is the person who writes the code. There is no relay chain, no "let me loop in someone else," and no senior-on-the-call-with-a-junior-on-the-build pattern. The work survives launch because the relationship survives launch, with the same point of contact for as long as the engagement runs.
What this means in practice:
- Every email goes to me, not a ticket queue.
- The discovery call, the design, the build, the launch, and the post-launch support are all the same person.
- If you call at 8pm because the contact form just sent something weird, I am the one who replies.
- No sub-contracted offshore developers. No design-in-Figma-then-toss-to-junior. No account managers between you and the work.
2. Custom code over CMSes.
The site you receive is a folder of files, not a database. There is no WordPress underneath it, no page builder layered on top, and no template-marketplace component anywhere in the build. Every page is written from scratch in HTML and CSS, generated by a static-site pipeline, and served as flat files. The result is a site that does not break when a plugin updates, does not slow down as it grows, and does not have an admin panel that can be hacked in the first place.
What this means in practice:
- No plugin updates. No security patches. No database backups. No admin login.
- The site renders identically in 2026 and 2030 because the underlying technology does not move under it.
- If you want to leave, the entire site is a folder of HTML files. Portable to any host on the planet.
- Performance is a build-time property, not a runtime tweak. Page-speed scores stay 95–100 because the platform cannot regress them.
3. Posted prices, posted process.
The pricing lives on a public page, the service agreement lives on a public page, and the owner's guide lives on a public page. The whole process is documented in plain language rather than buried behind a sales call. There are no hidden quotes, no "contact us for pricing," and no "we will send you the contract after the call." When a prospect can read the entire engagement before the first conversation, the discovery call gets shorter and the alignment gets better.
What this means in practice:
- Pricing shows the actual numbers. Two plans, $0 down, no surprise add-ons.
- The service agreement is published in plain English. Read it before you sign.
- The owner's guide describes the post-launch experience for every site I build.
- The full operational playbook, how I onboard, design, build, launch, support, and offboard, is documented internally and reflected in the public pages above. Receipts, not promises.
4. Fast by construction, not by plugin.
A PageSpeed score in the ninety-five-to-one-hundred range on mobile is a build artifact, not a tweak applied later. It comes from the way the site is assembled in the first place: AVIF and WebP image variants generated at build, fonts preloaded, CSS concatenated, and JavaScript kept under ten kilobytes on a typical page. It does not come from a caching plugin bolted onto a slow runtime. The economic case for page speed is concrete: every additional second of mobile load time loses roughly seven to ten percent of mobile visitors before they ever read a word.
What this means in practice:
- Real-world Lighthouse runs on every demo site at 95–100 mobile. Not "in lab conditions", in actual visitor sessions.
- Time-to-interactive on a phone: under 1.5 seconds. Time-to-first-byte: under 100ms via Cloudflare's global edge.
- Every image is generated as AVIF + WebP + JPEG at multiple widths. The browser picks the smallest format and size that fits.
- Performance is verified on every deploy, not "set up at launch and forgotten."
5. Accessible by default.
I hold every site to WCAG 2.2 AA before launch, rather than waiting for a complaint to show up afterwards. Contrast ratios are verified with the TPGi Colour Contrast Analyser, every interactive element is reachable from the keyboard, focus indicators are visible, the HTML is semantic throughout, and a real screen reader is used before sign-off. Accessibility is not an upsell or a phase two on this stack. It is the same standard for every project, and it is written into the contract.
What this means in practice:
- Every text/background combination meets 4.5:1 (normal) or 3:1 (large text). Verified in light mode and dark mode.
- Every interactive element has at least a 44×44px touch target. Required for WCAG 2.2.
- Every page has a skip link, semantic heading hierarchy, real ARIA labels where needed, and visible focus rings.
- The accessibility statement is contractual, not aspirational.
6. Local before global.
Every site is wired to the local pack first. The Google Business Profile is the highest-leverage organic-traffic surface most service businesses have, and the job of the website is to amplify it: matching schema, NAP consistency on every page, and real per-metro service-area pages with locally rooted content rather than doorway templates. The 15-minute quarterly GBP checklist is the maintenance cadence I teach every client.
What this means in practice:
- LocalBusiness + Service + FAQPage schema on every relevant page, custom-coded, matched to your GBP entity.
- NAP (name, address, phone) identical between site and GBP, on every page, in the same format.
- Real city pages with photos of work in that city, not the same paragraph with the city name swapped in.
- Service-area maps embedded with Leaflet + OpenStreetMap. No Google Maps tracker, no API key, no cookies.
7. Boring infrastructure.
I pick boring tools that ship reliably and skip whatever framework happens to be trending. The stack underneath every site is intentionally unfashionable: Eleventy v3 for templating, vanilla CSS, vanilla JavaScript, Cloudflare Pages for hosting, Web3Forms for form submissions, and Pagefind for search. Nothing in that list is brand-new, nothing in that list is hyped, and nothing in that list has changed substantially in the last three years. That is the feature, not the limitation.
What this means in practice:
- The site you launch in 2026 still works in 2030 without "we need to migrate the framework."
- No npm-package-of-the-week. The dependency tree on a typical client site is under 20 packages, all pinned.
- If something breaks at 9pm, the diagnostic surface is small enough to actually diagnose. There is no React, no Next.js, no GraphQL, no Redis, nowhere for a bug to hide.
- The technical approach documents every tool by name and explains why it is on the stack. View source on any page to verify.
How the Standard shows up across the site
The Service Site Standard is not a separate document I will hand you on launch day. It is the operating posture every public page on this site already reflects, and the cross-references below show where each principle is doing the work.
- The changelog is principle #3 (posted process) in action. Every substantive change shipped, in public.
- The owner's guide is principle #1 (one owner) and principle #3 in plain language. The same guide goes to every client.
- The service agreement is principle #3 made contractual.
- The results page auto-derives the numbers behind principles #4, #5, and #6 on every build.
- The six demo sites are principle #2 (custom code) and principle #4 (fast by construction) you can audit yourself in PageSpeed Insights.
- The internal operating playbook is principle #1 and principle #3 made operational. Same checklist for every project, every time.
If a future page on this site does not visibly serve at least one of the seven principles, it should not exist. That is the test the Standard applies to itself.
Boring is the feature.