Standards you can hold us to.

What it is

The Web Content Accessibility Guidelines are the W3C's standard for accessible digital content. Version 2.2 became a W3C Recommendation on October 5, 2023, and the current edition is dated December 12, 2024. It has three conformance levels, A, AA, and AAA. We build to AA.

WCAG 2.2 added nine success criteria to 2.1, including a minimum target size of 24 by 24 CSS pixels, focus that is not hidden behind sticky headers, an alternative to dragging, and sign-in that does not depend on memory tests.

What we do

• Semantic HTML, with every feature reachable by keyboard and a visible focus state
• Text contrast of at least 4.5:1, or 3:1 for large text, and 3:1 for controls and graphics
• Layouts that reflow at 320 CSS pixels wide and text that resizes to 200 percent
• Labeled form fields and error messages that say how to fix the problem
• A single-pointer alternative for anything that uses dragging

How we check

• Automated accessibility rules run in the build pipeline
• A keyboard-only pass through every flow before release
• Screen reader checks with VoiceOver on Apple devices and TalkBack or NVDA elsewhere
• Zoom, reflow, and contrast measurements on real pages

What it is

Core Web Vitals are Google's measures of loading, responsiveness, and visual stability. A page is rated good when Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less.

Each is assessed at the 75th percentile of page loads, segmented across mobile and desktop. INP replaced First Input Delay as a Core Web Vital on March 12, 2024.

What we do

• A performance budget for each key page, agreed in design
• Images sized and compressed for each screen, with dimensions set so nothing jumps
• Only the code a page needs, loaded when it needs it
• Long tasks broken up so taps and clicks answer quickly
• Caching and a content delivery network in front of the app

How we check

• Lab tests on throttled mobile settings for every release
• Field data from real users once traffic allows it
• Performance results included in the release checklist

What it is

The OWASP Application Security Verification Standard is an open list of security requirements for web applications and services. Version 5.0.0 was released on May 30, 2025, with around 350 requirements in 17 chapters, sorted into three levels: Level 1 is the minimum starting point, Level 2 is the level most applications should aim for, and Level 3 is for the highest assurance.

For passwords we follow NIST SP 800-63B-4 (July 2025): at least 15 characters when a password is the only factor, no forced composition rules, and a check against known compromised passwords.

What we do

• Level 1 as the floor for every app; Level 2 for apps that handle personal, financial, or health data
• A short threat model during discovery
• Least-privilege access, multi-factor sign-in for admins, and secrets kept out of code
• Encryption in transit and at rest, logging, and tested backups
• Dependencies kept current and scanned for known vulnerabilities

How we check

• The ASVS requirements for the chosen level, reviewed before release
• Dependency and vulnerability scans on every build
• Security questions built into code review
• An independent penetration test recommended for high-risk apps

What it means

The repository, cloud hosting, domain, and app store accounts belong to you from the start, and we work in them as collaborators. Nothing important lives on our laptops or in our accounts.

What we do

• Everything in version control, including infrastructure settings where practical
• Secrets stored in a secrets manager, never in the code
• Releases tagged with Semantic Versioning 2.0.0
• Licenses of third-party libraries listed

How we check

• A handover checklist covering access, credentials, and billing
• A fresh-clone test: someone who did not write the code builds and deploys it from the README alone

What we write

• A README that gets a new developer running in an afternoon
• Architecture decision records: short notes on each significant choice, its context, and its consequences, a format described by Michael Nygard in 2011
• An API reference written as an OpenAPI description
• A runbook for deploys, backups, and incidents

Why it matters

Documentation is what lets your team, or another studio, maintain the software without us. It is part of the definition of done for every feature, so it is never a separate phase that gets cut.

How we check

• Docs reviewed in the same pull request as the code they describe
• The API description validated in the build

What it is

Privacy by design means building privacy in from the start rather than adding it later. Ann Cavoukian set out seven foundational principles for it, including privacy as the default setting and end-to-end security across the data's whole life. The EU's GDPR writes the idea into law as data protection by design and by default.

US state laws are moving the same way. Kentucky's Consumer Data Protection Act took effect on January 1, 2026, for businesses that handle personal data of at least 100,000 Kentucky consumers in a year, or 25,000 consumers if over half their gross revenue comes from selling personal data.

What we do

• Collect only the data a feature needs, and say why
• Privacy-friendly defaults, with tracking off until someone opts in
• Retention periods, with old data deleted on a schedule
• Access limited to the people and services that need it
• Export and deletion built in when a law or your policy requires it

How we check

• A data inventory in discovery: what is collected, where it lives, who can see it
• A privacy review before launch, with your legal advisor where the law applies