Shape and architecture
Discovery
We agree the data model, the API shape and the first slice to ship, before writing the bulk of the code.
Technologies
Web & SaaS engineering
Modern web and mobile frontends and APIs for SaaS, platforms and internal tools. React, Next.js, TypeScript and React Native, with Node/NestJS and .NET APIs on top of a solid data stack.
- React, Next.js, TypeScript, React Native
- Node.js, NestJS, .NET / ASP.NET Core
- REST/GraphQL APIs, event-driven integrations
What we build
What we build with Web & SaaS engineering
The web, mobile and API work behind SaaS products, portals and internal tools.
Web apps and dashboards
React, Next.js and TypeScript frontends for SaaS, portals and data-heavy admin tools.
APIs and integrations
Node, NestJS and .NET backends with REST or GraphQL and event-driven integrations.
Cross-platform mobile
React Native apps for iOS and Android, with native Kotlin or Swift where the platform demands it.
Design systems, not one-off screens
A component library so the product stays consistent and quick to extend as it grows.
What's modern now
How we build for the web now
The web stack moved toward the server again. Here is where we land and why.
Server-first with Next.js App Router
Render on the server where it helps load time and SEO, ship client JavaScript only where there is real interaction.
Type safety end to end
TypeScript across the React frontend and the Node, NestJS or .NET API, so a broken contract fails at build, not in production.
Performance is a constraint, not a polish step
Core Web Vitals are a target from day one, tracked with real before-and-after numbers.
The stack
The stack we use here
The tools we reach for in this pillar. Honest, not exhaustive.
ReactReactNext.jsNext.jsTypeScriptTypeScriptVue.jsVue.jsAngularAngularFigmaFigmaMaterial UIMaterial UIAnt DesignAnt Designshadcn/uishadcn/uiTanStack QueryTanStack Query
Tools & integrations
Services we wire into products
The third-party services we wire into web and mobile products, chosen per project.
- Auth & identity
- Auth0
- Firebase Auth
- AWS Cognito
- Keycloak
- Custom (JWT)
- Payments, billing & commerce
- Stripe
- Stripe Billing
- WSPay
- RevenueCat
- Shopify
- Comms & chat
- Agora
- Sendbird
- Twilio
- Email & CRM
- SendGrid
- Resend
- Mailchimp
- HubSpot
- Charts & motion
- Chart.js
- D3
- ApexCharts
- GSAP
- Framer Motion
- Lottie
- Three.js
- Maps & scheduling
- Google Maps
- Cal.com / Calendly
- Google Calendar
- Mobile & notifications
- Maestro
- App Store Connect
- Google Play Console
- ConfigCat
- Firebase FCM
- OneSignal
- Docs & localisation
- DocuSign
- PDF generation
- i18next
- Government & compliance
- Government Service Bus (GSB)
- e-invoicing / fiscalisation
Third-party services we wire in, picked per project. Our core stack is the section above.
How we choose
How much to split up front
How a product is split decides how it grows. We reach for a modular monolith by default and split out services when the load, not the org chart, demands it.
Criteria
Single app
Modular monolith
Microservices
Fast to a first release
Strong.
Strong. Clear module seams
Limited. Infra overhead first
Simple to run and deploy
Strong.
Strong.
Limited. Many moving parts
Scale the busy parts on their own
Limited. All or nothing
Partial. Extract when needed
Strong. Scale per service
A small senior team can own it
Partial.
Strong.
Limited. Needs platform + teams
Tenant isolation by design
Row- or schema-level isolation chosen up front, so one customer can never reach another's data.
Roles and permissions that scale
Access control that survives new tenant types and admin roles without a rewrite.
Billing and limits as first-class
Plans, seats and usage limits modelled into the schema from the first migration.
How we adopt it
How we start a build
A first real slice in weeks, with the foundations to grow on.
Build the first slice
Build
Server-first frontend, a typed API and a design system, shipped behind reviews and tests.
Harden and scale
Ongoing
Multi-tenant concerns, performance budgets and the next streams of the roadmap.
Proof
Real work in this stack
SaaS and platform builds that held up as tenants, roles and load grew, not just at first release.
FAQ
Common questions
Yes, and the way to avoid that rewrite is to decide tenancy early, not late. Most SaaS pain we see traces back to tenant isolation, roles and billing being bolted on after launch. We choose row- or schema-level isolation up front so one customer can never reach another's data, design access control that survives new tenant types and admin roles, and we model plans, seats and usage limits into the product rather than patching them in later. We default to a modular monolith and split out services only when real load justifies it.
Both. A lot of our work is on products that already exist, whether adding to a React, Node, NestJS or .NET app, untangling a stalled build or rebuilding the parts that are holding you back. We start by reading the code and the data model, agreeing what stays, what gets refactored and what gets replaced, then shipping a first real slice before any large rewrite. We don't insist on a greenfield restart to feel comfortable, and we won't hand you back a black box.
We treat quality and reliability as first-class concerns: automated tests where they add value, clear performance budgets, logging/monitoring and incident practices. Part of our role is to leave your systems healthier than we found them, not just ship features.
You do. We usually work in your repositories and cloud accounts, or hand them over at the end, with clear documentation and runbooks so you're not dependent on us for basic operations.
Work with us
Building with Web & SaaS engineering?
Tell us about your product and constraints, and we'll help you choose the right stack and a sensible first step.
Build faster with AI
Our playbook for integrating AI into product design and development workflows.
Download the playbook