Technology
Our stack, chosen for fit and durability.
We do not collect tools for a trophy shelf. Every layer below is here because it fits the work and holds up under real use, from a first MVP to Android apps installed by millions.
How we choose what we build on.
The stack below is not a wish list. When a newer option is genuinely better for the job, we move to it. When it is just louder, we leave it where it is.
- Fit before fashion. We pick the tool that matches the problem in front of us, not the one trending this quarter.
- Boring where it counts. For data and payments we use proven, well documented tools, so the surprising part of the product is the product, not the plumbing.
- We own the second year. We weigh what a choice costs to run and maintain, not just how fast it demos, because we usually stay on to maintain it.
- Fewer moving parts. Each dependency is one more thing that can break at 2am. We add one only when it earns its place, and we remove it when it stops.
The stack, in honest layers.
No logo wall of tools we touched once. These are the layers we build in every week, and the names inside each are examples of what we reach for, not the whole list.
Applied AI, LLMs, and agents
We put language models where they take manual steps off a team's plate: reading documents, drafting replies, routing requests, and pulling the right answer from your own data. We keep a person in the loop and judge the result in hours saved, not features shipped.
Web
The interfaces our products and dashboards run on. We build in TypeScript so mistakes surface at compile time instead of in production, and keep components small so a screen still reads clearly a year after it ships.
Mobile
Our billing apps are installed by millions on Google Play, so the phone is a first target, not an afterthought. We build offline first and for slow networks, then sync when a connection returns, because that is how our users actually work.
Backend and data
The parts customers never see but always feel: APIs, background jobs, and the database. We favour proven, well understood data stores, write for correctness first, then make the paths fast where the numbers say it matters.
Cloud and infrastructure
Containers and pipelines so a change moves from a commit to production the same way every time. We keep environments alike, so a bug we see in staging is a bug we can reproduce, not a mystery that only happens live.
Design systems
One set of tokens and components, not a folder of one off screens. The site you are reading runs on that system, so design intent survives from the first mockup into shipped code and the product stays coherent as it grows.
Standards that stay fixed while tools change.
Names in the stack come and go. These are the habits underneath them that do not, and they are part of what "done" means for us.
Testing
We test the paths that touch money and data first, and add coverage where a bug would be expensive, not everywhere for the sake of a number.
Observability
Logs, traces, and alerts ship with the feature, so when something breaks we can see where before a customer has to tell us.
Accessibility
Keyboard focus, colour contrast, and semantic markup are part of the work, not a later pass. This page follows the same rules.
Performance
We set a budget for how much a page can weigh and how long it can take, and we hold to it as the product grows.
Security
Secrets stay out of the client, access is scoped to what a role needs, and we patch dependencies on a schedule instead of after an incident.
Privacy
We collect the data a feature needs and no more, and we are clear inside the product about what is stored and why.