Our Practices
The standards, verification methods, and quality benchmarks behind every project.
Every project is evaluated against the same public standards, measurable quality criteria, and documented review process. This page explains the standards we follow, how we verify them, and how those practices shape the work we deliver.
We hold ourselves to the same bar. Run it yourself with Lighthouse if you want to verify.
Why Standards Matter
Best practices drift year to year and vendor to vendor. A public standard doesn't. It's the same document whether you read it or we do, which is the entire point of building against one.
Four bodies govern most of what we build across all disciplines, not just markup and CSS: WHATWG HTML, the living standard for markup and DOM behaviour, which governs what semantic and accessible actually mean; W3C CSS, tested against the same conformance suites browser vendors use; ECMAScript, the language behaviour a custom application is built on regardless of framework; and IETF protocols: HTTP, caching, the network layer everything from a CMS theme to a booking portal depends on.
Quality Benchmarks
Our baseline delivery target is a 100 on Lighthouse Accessibility, Best Practices, and SEO, and a realistic 95+ on Performance. Core Web Vitals and WCAG 2.2 AA compliance run alongside it, so the site is fully usable by screen reader and keyboard alone. These are the numbers the project is scoped against from day one, checked in CI on every deploy.
In practice that means resource hints scoped to what the page actually needs next, not sprayed across every route:
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> <link rel="preload" as="font" href="/fonts/plex-sans.woff2" crossorigin> <link rel="modulepreload" href="/js/checkout.js">
Beyond markup, we run edge caching at the CDN layer, inline critical CSS so first paint doesn't wait on a stylesheet round trip, and set explicit CI performance budgets so a regression fails the build, not the review.
What an Audit Includes
A written methodology document, typically 15 to 40 pages depending on complexity, structured to rigorously identify and plan for remediation:
Example Findings
The methodology is the same whether the engagement is a WordPress rebuild or a custom application, only the specifics change:
1. WordPress: redirect chain on the hero image
A product page loaded its hero image through a three-hop redirect (CDN alias to canonical host to final asset), adding roughly 400ms to Largest Contentful Paint before a single byte of the image arrived.
- <img src="https://cdn.old-host.example/img/hero.jpg"> + <img src="https://assets.example.com/hero-1200.avif" srcset="/hero-800.avif 800w, /hero-1200.avif 1200w" + width="1200" height="630" loading="eager" fetchpriority="high">
Fix: point the tag at the final host directly, serve AVIF with a JPEG fallback, and set explicit width and height so the browser reserves layout space before the image decodes, which also keeps Cumulative Layout Shift at zero.
2. Custom Applications: API over-fetching sensitive fields
A booking API's user endpoint returned every column in the table, including password hashes and internal admin flags, to any authenticated request.
- SELECT * FROM users WHERE id = ? + SELECT id, name, email FROM users WHERE id = ?
Fix: explicit column selection plus a Zod response schema, so the shape returned is guaranteed regardless of what the query later grows to include.
3. Technical SEO: canonical pointing at a tracked URL
Every ad click generated a unique tracking parameter, and the canonical tag echoed it back instead of pointing at the clean URL, splitting ranking signal across hundreds of near-duplicate addresses.
- <link rel="canonical" href="https://example.com/product?ref=ad930"> + <link rel="canonical" href="https://example.com/product">
Fix: generate the canonical server-side from the route, stripped of query parameters, and confirm it in Search Console rather than trusting the template.
4. AEO: FAQ content invisible without JavaScript
FAQ answers rendered entirely client-side into an empty div. Crawlers that don't execute JavaScript reliably, including most answer-engine crawlers, saw no question or answer text at all.
- <div id="faq-root"></div> + <dl><dt>Do you offer refunds?</dt><dd>Yes, within 30 days.</dd></dl> + <script type="application/ld+json">{ "@type": "FAQPage", ... }</script>
Fix: server-render the question and answer text as real HTML with FAQPage JSON-LD alongside it, keeping JavaScript only for the visual accordion toggle.
5. Content: one page competing with itself
A single 3,000-word page tried to rank for pricing, integrations, and competitor comparisons at once. Search Console showed it competing against the site's own dedicated pages for the same queries.
Fix: split into three focused pages, each targeting one intent, linked back to a single hub page so authority consolidates instead of splitting.
6. DevOps: migrations run straight against production
The deploy script applied database migrations directly to production with no staging pass and no manual gate, so a bad migration meant a bad migration in production.
Fix: a staging environment mirroring production schema, migrations tested there first, and a manual approval step in the pipeline before anything touches production data.
Independent Technical Reviews
Organizations sometimes ask us to apply these practices to their own websites, applications, and digital platforms.
When requested, we perform fixed-scope technical audits covering performance, accessibility, architecture, technical SEO, security, and related disciplines. Every audit documents the findings, supporting evidence, relevant standards, and recommended remediation.
Need an Independent Review?
If you'd like an independent assessment based on the practices described on this page, we offer fixed-scope technical audits for existing websites and applications.
Request an Independent Review →