Expertise
Front-end development
We build customer-facing applications, operator consoles and admin surfaces in React, Next.js, Angular, Vue and TypeScript, along with the design systems underneath them and the APIs they talk to. Design engineers and software engineers sit on one team, so the interface and the data model are decided together.
React and Next.js
Most of what we build. Server components, streaming, and the rendering decisions that follow from them, which is where a Next.js application is usually won or lost long before anybody writes a component.
- App Router, server components and the client boundary drawn deliberately rather than by accident
- Static export, ISR or a running server, chosen against how the content actually changes
- Data fetching that does not waterfall, and the loading states a reader will actually see
- React Server Components alongside a typed API, so the contract holds across the boundary
Angular
Long-lived enterprise applications, and the migrations off AngularJS that most teams have been putting off. Angular estates tend to be older, larger and more load-bearing than the React ones, which changes how you move them.
- Standalone components and the signals migration, taken incrementally
- AngularJS to Angular in waves, with both running side by side and routes crossing as they are ready
- NgRx where the state genuinely warrants it, and not where it does not
- Module federation for estates that several teams have to ship into
Design systems and component libraries
Taken on their own, and often how an engagement starts. A design system is a product with its own consumers, and treating it as a folder of components is why most of them are abandoned within two years.
- Tokens, primitives and composition rules, versioned and published as a package
- Storybook as the working surface rather than as documentation nobody opens
- Figma libraries that stay in step with the code, because the ones that drift stop being used
- Accessibility built into the primitives, so a consuming team gets it without knowing they did
design.md and AI-assisted consistency
The newest problem on this list and the one teams are least prepared for. Three engineers with assistants produce three dialects of the same application inside a month unless something tells the assistant what this codebase looks like.
- A design.md that states the tokens, the component vocabulary, the layout rules and the things never to do
- Lint rules that enforce it, because a convention an assistant cannot check is a convention it will drift from
- Component APIs shaped so the wrong thing is hard to write rather than merely discouraged
- Review that catches drift early, when it is one file rather than forty
Performance and accessibility
Treated as build requirements rather than as a pre-launch audit, because both are cheap while the architecture is open and expensive once it is not.
- Core Web Vitals budgeted per route and measured in CI, not checked the week before launch
- WCAG conformance designed into the primitives rather than retrofitted onto finished screens
- Bundle composition understood, so a dependency added on a Tuesday does not cost a second of load
- Real-device testing on the hardware your users actually have
What we build
- React and Next.js, including server components, streaming and the rendering decisions that follow
- Angular, from long-lived enterprise applications to migrations off AngularJS
- TypeScript throughout, with the API contracts typed end to end
- Design systems and component libraries: tokens, primitives, documentation, and the Figma that stays in step
- design.md and the conventions that keep an AI-assisted team writing the same application
- Accessibility and Core Web Vitals treated as build requirements rather than a pre-launch audit
Accelerators doing the work.
Where the interface is a Databricks App, Runway ships it. Where the product needs an auditable console, Platform sits underneath.
How this is delivered
Product development
Full product delivery: multi-tenant architecture, operator consoles and the data layer under them. On Azure, AWS, Google Cloud or Cloudflare, and as a Databricks App where the product belongs next to the lakehouse.
FAQ
Questions we get asked
What front-end stacks do you work in?
React and Next.js most often, Angular where the estate is already there, Vue where it is what your team knows. TypeScript throughout. Tailwind, shadcn/ui and Storybook where they fit, and whatever the existing application uses when we are extending rather than starting.
Do you build design systems?
Yes, and on their own. Tokens, primitives, documentation and the Figma libraries that stay in step with the code. Every client design system we have built starts from components our own team wrote and has been running in production for years.
What is a design.md and do you write them?
It is the file that tells an AI-assisted team what this application looks like: the tokens, the component vocabulary, the layout rules, the things never to do. Without one, three engineers using assistants produce three dialects of the same product inside a month. We write them, and we write the lint rules that keep them true.
Do you take front-end-only contracts?
Yes, and it is often how an engagement starts. A design system, a component library or one operator console. For a pure marketing site a specialist studio will serve you better than we would.
Can you migrate us off AngularJS or a legacy stack?
Yes. Usually in waves rather than a rewrite, with the old and new running side by side and routes moving across as they are ready, so the business keeps working while it happens.
Is this the same as experience design?
They sit on one team. Experience design at /expertise/experience-design is the shaping of the product while the engineering decisions are still open. This page is the engineering of the interface itself.
How can we help?
A technical conversation about the interface and the system behind it.