Accessibility
WCAG 2.2 AA
Designed and tested against the AA criteria. Automated checks on every route; what a scanner cannot see is verified by hand.
axe-core on every route · keyboard-only passes · focus order and return · reduced-motion parity
Studio
How a project actually runs.
Hayes Labs is a digital systems studio, building websites, automation, and custom software for businesses where the result has to keep working rather than just look finished.
Strategy, design, and implementation are one engagement, accountable from the first conversation about the business to the system running in production.
It matters most where the site, the internal tool, or the automation is load-bearing — where the work depends on understanding the business and not only the brief.
01 — The engagement model
Four phases, and what you receive from each.
The same four phases on every engagement, each ending in something you can hold the work to.
- 01
Discover
What happens
Understand the business, goals, users, current systems, constraints, and what success needs to look like.
What you receive
A clear understanding of the opportunity, key requirements, and recommended next steps.
- 02
Define
What happens
Shape the strategy, architecture, experience, scope, technical approach, timeline, and implementation plan.
What you receive
An agreed project plan outlining scope, priorities, deliverables, milestones, and exclusions.
- 03
Build
What happens
Design, develop, integrate, test, and refine the solution through structured review cycles.
What you receive
Working previews and review checkpoints to see progress, provide feedback, and refine the solution.
- 04
Launch & Evolve
What happens
Deploy, verify production quality, support adoption and handoff, and identify future improvements where appropriate.
What you receive
A tested deployment, clear handoff, and an agreed plan for ongoing support or future improvements.
Held to at every phaseScope before buildReview the real thingTrade-offs surface firstOwnership survives launch
02 — In practice
How decisions get made.
- 01
The agreed picture is written down before anything is built, including what is not in it.
Most disputes are not about quality. They are about two pictures of what was agreed.
- 02
Progress is reviewed in working previews at clear checkpoints, never in a slide.
What you sign off is the thing itself, on the device you will use.
- 03
A decision that moves cost, timeline, or quality reaches you before it is taken, with a recommendation attached.
Not afterwards, as a line on an invoice. Where a request would make the system worse you will be told why — and then it is your call.
- 04
What you own, and how you will access it, is set out in the project agreement before development begins.
A build nobody can change without calling the person who wrote it is not finished.
03 — Standards
What every build is held to.
Targets we design and test against, and checks that run before anything ships. They are also the standards this site is built to, so the claim is checkable against the page you are reading it on.
Strict
Type safety
TypeScript with no escape hatches. A project that does not typecheck does not deploy.
Working previews
Review
Progress is reviewed in working previews at clear checkpoints, not in a slide.
Clear ownership
Handoff
Account setup, code ownership, and handoff are defined in the project agreement before development begins.
04 — Stack
What the work is built with.
The tools in the shipped work on this site, chosen per project.
- Next.js
- React
- TypeScript
- Tailwind CSS
- Supabase
- Resend
- Vercel
Start a project
Tell us what you need built or improved.
A short message is enough to start. We’ll come back with a clear read on scope and the right next step.