Services
Projects rarely fit one heading. Pick the ones that sound like your problem and we will tell you which others it will touch before we quote.
01 / product
Typed from the database to the button. Server-rendered, fast on first load, and built so the second feature is as easy to add as the first.
We build the application layer people actually use: dashboards, portals, admin tools, and customer-facing products. Routing, authentication, permissions and forms are treated as core engineering, not as a template to fill in.
02 / desktop
The same product as a real desktop app for Windows, macOS and Linux, packaged as an installer with updates that land on their own.
Some work belongs on the machine: local files, hardware, long-running background processes, or simply working when the network does not. We build desktop applications on Tauri and Electron, so the interface shares code with the web product while the parts that need the operating system get it.
03 / mobile
Phone and tablet builds, plus progressive web apps that install straight from the browser and keep working offline.
Not every product needs a store listing. We start from what your users actually have to install and where they use it, then ship either a packaged mobile app or a progressive web app. Both are built from the same codebase as the rest of the product, so a fix lands everywhere at once.
04 / commerce
Headless storefronts where the catalogue, cart and checkout are built as a real application rather than bolted onto a template.
Selling online stops being simple the moment your pricing, stock or fulfilment does not match what an off-the-shelf platform assumed. We build the storefront and the order model ourselves against a headless backend, so the rules your business actually runs on are in the code rather than worked around. Card data stays with the payment provider; everything either side of it is ours to get right.
05 / platform
HTTP and realtime interfaces, background workers, and scheduled jobs. Documented, versioned, and safe to call twice.
Behind most products sits work that has to happen reliably whether or not anyone is watching. We design the service boundaries, the retry behaviour, and the queues in between, then make the whole thing observable.
06 / data
PostgreSQL schemas with migrations you can run forward under load, plus the search, caching and object storage around them.
The schema outlives every framework choice, so it gets designed first. We model the domain properly, keep migrations reversible where they can be, and make sure reporting reads from the same source of truth the product writes to.
07 / realtime
Multi-user editing, presence, and live updates, with conflict resolution handled rather than hand-waved.
Collaborative features fail in ways request/response apps do not. We build them on CRDTs and persistent sockets, with offline behaviour and reconnection designed in from the start rather than patched later.
08 / ai
AI-powered features in the product you already have: assistants over your own data and agents that call your APIs, with guardrails, cost limits and a human in the loop where it counts.
We treat a model the way we treat any other third-party dependency that can fail: constrain its output to a schema, validate what comes back, cap what a request can spend, log every call, and design what happens when it is wrong. Most of the work is retrieval, permissions and evaluation, which is ordinary software engineering and is where these projects usually come apart.
09 / infra
Containerised builds, TLS, backups, monitoring and rollback, set up before launch day rather than after the first incident.
We deploy what we build. That means reproducible images, a reverse proxy that terminates TLS properly, secrets kept out of the repository, and logs and traces you can search when something looks wrong. Self-hosted or cloud, whichever suits the budget and the compliance story.
10 / managed-it
The systems your business runs on rather than the ones it sells: networks and Wi-Fi, Microsoft 365 and identity, backups you have actually restored from, cameras and access control, and the servers still sitting in the building.
This is the operational half of the work, and it is a monthly agreement rather than a project. We keep an asset register, monitor the things that give warning before they fail, patch on a cadence, and rehearse restores instead of assuming them. Administrative accounts stay in your name, and the documentation is written so that leaving us is a decision rather than a project.
11 / migration
Moving off a legacy system, or picking up a codebase someone else left behind. We map what exists before we change it.
Inherited systems are normal. We start by reading the code and the data, write down how it actually behaves, and then move it in steps that can each be verified, rather than betting the business on one cutover weekend.
Research and development
Neither is a service line today and we are not taking bookings for either. If you have an idea, a project or a problem that lands in one of them, bring it to us anyway and we will consider it on its merits.
Building the bench
Board-level work on modern electronics: component-level diagnosis, reflow and rework under a microscope, connector and port replacement, and recovering data from boards that no longer power on. We are assembling the bench and proving the process on our own hardware first.
Prototyping
Devices that run their own firmware and talk to software we already know how to build: sensors and controllers, the embedded layer in Rust or C, and the desktop or web side that provisions, configures and monitors them. Prototypes at this stage, not a product line.
We would rather tell you where we are actually up to than quote for work we have not proved. If we are not far enough along to be useful to you yet, we will say so and tell you what would change that.
Engagement models
Whichever shape fits, you get the same engineers and the same reporting.
A defined scope, milestones and a fixed price per milestone. Best when you know roughly what needs to exist and want it delivered and deployed.
New products, rebuilds, internal tools
A recurring block of engineering time each month, prioritised with you. Best when the roadmap moves and you need capacity rather than a contract.
Growing products, ongoing platform work
A focused audit of an existing codebase, schema or deployment, written up with prioritised findings and what we would do about each one.
Inherited systems, pre-launch checks, due diligence