Web development
We build web applications that stay quick and legible as they grow — on React and Node, with the performance and accessibility work treated as part of the build rather than a later pass.
What you get
Performance as a budget, not a cleanup
Limits on what ships to the browser, images and fonts handled properly, and rendering chosen per page rather than by habit.
Accessible as it is built
Real labels, keyboard paths, focus handling and contrast checked during the build, where they cost a fraction of a retrofit.
A design system rather than screens
Shared components and tokens, so the tenth page costs less than the first and the product stays coherent as the team grows.
How we approach it
Speed is a design constraint, not a cleanup task. That means budgets on what ships to the browser, images and fonts handled properly, and rendering chosen per page rather than by habit. This site is the example nearest to hand: every route is prerendered to static HTML with ReactDOMServer at build time and then hydrated, so a crawler and a first-time visitor both get a complete page without waiting for a bundle to execute.
Accessibility gets the same treatment — real labels, keyboard paths, focus handling and contrast checked as the interface is built. It is cheaper there than in a retrofit, and the habits that make a page usable with a keyboard tend to make it clearer for everyone.
Problems this solves
Pages that get slower as the product succeeds
Every feature adds script. Without a budget and a measurement in the pipeline, the slowdown is only noticed once it affects conversion.
A single-page app crawlers cannot read
A client-rendered app serves search engines an empty div. Fixing it after launch means reworking rendering rather than adding a tag.
Accessibility discovered during procurement
An audit demanded by a client or a regulator finds months of work. Built in from the start, most of it is simply how the markup was written.
How we work
Ideate
We collaborate with clients to define goals, explore ideas, and create a clear plan for a successful software solution.
Develop
Our team builds robust, scalable applications using modern technologies and best development practices.
Maintain
We provide ongoing support, updates, and optimizations to ensure your software remains reliable and efficient.
Scale
We help your solution grow with your business by enhancing performance, adding features, and supporting larger user bases.
What this includes
Products we designed, built, and still run.
Our portfolio showcases projects delivered with expert craftsmanship and exceptional quality.
New & preloved fashion marketplace
Seller onboarding, condition grading and an editorial storefront tuned for mobile-first browsing.
- React
- Node.js
- Stripe
- AWS
Childcare discovery and booking
Helps families find and book the right daycare, with licence verification, availability and enquiry management for providers.
- React
- Node.js
- MongoDB
- Twilio
Marketplace for lighting design experts
A two-sided marketplace connecting specifiers with certified lighting professionals worldwide — verified profiles, project briefs and direct contracting, with payouts handled end to end.
- React
- Node.js
- Stripe Connect
Questions we get asked
What stack do you build on?
React and Node by default, with TypeScript where a team will maintain it long term, and Postgres or MongoDB depending on the shape of the data. We are not religious about it: the constraint that matters more than the framework is whether your team can hire for and maintain what we leave behind.
How do you keep a site fast as it grows?
Budgets enforced in the build rather than measured afterwards, code split along real navigation boundaries, images served in modern formats at the size they are displayed, and fonts loaded without blocking text. Then a measurement in the pipeline, because performance work that is not re-checked regresses within a quarter.
Server rendering, static, or a single-page app?
Per page, by what the page is for. Marketing and content pages should arrive as HTML a crawler and a first-time visitor can read immediately; a logged-in dashboard behind authentication gains nothing from that and is simpler as a client-rendered app. This site prerenders every route to static HTML at build time and hydrates it, which is one working example of the first case.
Can you work with our existing codebase?
Yes, and it is a large part of what we do. That starts with reading it and writing down what we find — structure, risks, dependency state, what is untested — so the first conversation is about evidence rather than first impressions. Sometimes the honest recommendation is targeted repair rather than the rewrite that was expected.