galenry.Products that still work well on the hundredth visit
People judge a product on the hundredth visit. We build the screens and the system underneath them, with the design system, speed limits and accessibility as requirements from the start rather than polish at the end.
The shape of the work
Agreed before we start. You own everything we produce, whether or not you continue with us.
- Starts with
- An audit, or a fresh start
- You get
- Design system + live product
You are probably here because of one of these. Each one points to where we’d start.
- 01
What you are seeing
Four different button styles across the same product
The question it raises
How do we stop every new page drifting from the last one?
Where we’d start
- Tokens and components every page reads from
- 02
What you are seeing
Speed scores that drop with every release
The question it raises
Why does the site test well but feel slow on a real phone?
Where we’d start
- A speed budget checked before each release
- 03
What you are seeing
Copy changes queued behind a release
The question it raises
Can marketing change copy without booking engineering time?
Where we’d start
- A CMS your team can edit without a deploy
- 04
What you are seeing
An accessibility audit you are not sure you would pass
The question it raises
Will this pass an accessibility audit if a client asks for one?
Where we’d start
- Accessibility checks on every change
None of these sound right? Tell us what is actually happening.
Describe the problemHow we keep a product from drifting. Not all four land in every engagement.
One design system behind every page
Colour, type and spacing are defined once and every surface reads them, so a brand change is one update rather than a month of find-and-replace.
A speed limit on every release
We set limits for how fast pages must load and check them before each release. A slower build is stopped, rather than discovered at launch.
Accessibility checked before release
Automated checks and a keyboard pass on every change. WCAG AA is the minimum we build to.
Content your team can change
Your team edits copy without a deploy, and the CMS keeps each field to what the layout can hold.
How the engagement runs. The shape holds; the depth of each phase moves with the problem.
Audit
We list what exists: components, page weight, contrast failures and the pages people actually use, and put numbers against what is hurting.
You get
Findings + a prioritised list
Foundations
The colours, type and layout rules everything else is built from, with accessibility and speed checks running before the first feature.
You get
Design system + automated checks
Build the pages
The real pages, built against real content and awkward cases rather than ideal mockups.
You get
Working product
Hand over
Documentation your team can use, and a CMS that lets non-engineers make changes safely.
You get
Docs + editable content
What we can point at. Including where we cannot.
This site’s colours are held to WCAG AA at the token level
When a colour fails a contrast check, we change the token rather than patch the page, so the fix reaches every page that uses it.
A booking platform live for a client, end to end
Appooppanthaadi: we designed and built the website, self-serve tour booking, payments, instalments and cancellations, and the AI assistant on top.
See itThis site is the reference build
The design tokens and the CMS model described here are the ones running on galenry.com.
What we reach for first. Not the only things we work with, and we change them when there is a reason.
Frontend
Widely known, so your next hire can pick it up, and typed, so mistakes show before release.
- Next.js
- React
- TypeScript
Styling
One set of tokens behind every page, so a brand change does not mean editing each one.
- Tailwind
- Design tokens
- CSS layers
Content
Your team edits without a deploy. We pick the CMS to suit who will use it.
- Payload
- Strapi
- Sanity
- Typed APIs
Quality
Browser, accessibility and speed checks that run before a change goes live.
- Playwright
- axe
- Lighthouse CI
Tell us what you’re trying to build. We’ll tell you where we’d start.
Bring an idea, a stalled project, or a system that has outgrown itself.
Send us a brief
The problem, what you have tried, and what success looks like. A few lines is enough to start.
Prefer email? contact@galenry.com
What happens next
- 01Reply within one business dayFrom one of our engineers.
- 02First call: 30 minutes, no deckA working call about the problem. We ask questions rather than present slides.
- 03An honest answerWhere we would start, or, if we are not the right team, who might be.