Our Technology Stack
The languages, frameworks and platforms we build production software with — and where we have shipped each one.
Frameworks
Our primary mobile stack since 2018 — one Dart codebase shipping to iOS, Android, web and desktop without a separate team per platform.
Every app we ship reaches Android — platform APIs, background execution, permissions, and the store requirements that come with them.
The front-end framework we work in when a product is already Angular — a batteries-included structure that suits large, long-lived apps.
The Python framework we use when a product needs an admin, auth and a real data model on day one rather than a hand-rolled service.
Sharing business logic across iOS and Android while each platform keeps its own native UI — the alternative when Flutter is not the right fit.
Vue with server rendering, routing and SEO handled — how we build marketing sites and web apps that must be fast and indexable on first load.
The front-end library we work in when a product is already React — components, hooks, and the ecosystem that has grown around them.
A headless CMS we reach for when editors need to own the content — a real admin and a clean API, without building either from scratch.
Apple's UI framework, where we build the native surfaces a Flutter app cannot own — widgets, App Clips, extensions and system integrations.
How we style every front end we build — utility classes and design tokens instead of a stylesheet that only ever grows and is never deleted.
Our front-end framework for admin panels, merchant dashboards and product web apps that have to stay maintainable for years, not sprints.
Languages
The language every Flutter app we ship is written in — sound null safety, real pattern matching, and a compiler that targets native and the web.
Our backend language for real-time APIs and services under load — small binaries, fast builds, and concurrency that stays readable.
What we reach for when a Flutter app needs real Android underneath it — platform channels, background work, and native SDK integrations.
Where we work with an existing PHP backend — extending it, integrating with it, and building the mobile and web clients it has to serve.
Our language for backends, data work and AI integrations — including the Python bindings we ship for our own Rust tooling.
The language our mobile release automation is written in — Fastlane lanes, custom actions, and the CI glue that ships builds to the stores.
Where we go when performance and correctness both matter — document rendering, CLI tooling, and services that have to stay fast and predictable.
What we reach for when a Flutter app needs real iOS underneath it — platform channels, native SDK integrations, widgets and App Clips.
The default for everything we write for the browser and for Node services — types that catch integration bugs before they reach a review.
Databases
Our default database — the one we reach for unless a product gives us a specific reason not to, from schema design through to index tuning.
Where we put data that has to be fast and can be rebuilt — caches, sessions, rate limits, and the queues behind a product's slow paths.
The database that ships inside the app — local caches, offline-first storage, and anything that still has to work with no network.
Infrastructure
Every service we build ships as a container, so what runs on a laptop, in CI and in production is one artefact rather than three of them.
The cloud our production workloads run on — managed Kubernetes, storage and networking, without hand-built servers nobody wants to maintain.
How we package a Kubernetes deployment — service, config, secrets and ingress as one versioned unit that can be promoted and rolled back.
How we run services in production — Helm-packaged deployments, rollouts that can be rolled back, and scaling that does not need a person at 3am.
Lightweight messaging between services — publish/subscribe and request/reply without the operational weight of a full broker cluster.
Tools
The release automation behind our mobile work — signing, builds and store uploads run from CI instead of from one engineer's laptop on release day.
Every project we touch lives in Git — reviewed pull requests, CI on every branch, and a history that still makes sense months later.
The build system every Android release goes through — product flavours, signing configs, and the dependency wiring under a Flutter app.
Not sure which stack fits your product?
Tell us what you are building and we will recommend the technologies that fit your budget, timeline and team.
Get in touch