Loading…
Loading…
Services
Six capabilities. Most projects combine two or three — a system to run the work, automation to remove the repetition, and AI only where the input is genuinely messy.
The interface your team lives in all day
Custom applications built around a real workflow rather than a template: dashboards that show the numbers that matter, portals your customers log into, internal tools that replace a spreadsheet nobody trusts any more. Roles and permissions are designed before the first screen, because retrofitting access control is how data leaks.
Built with: Next.js · React · TypeScript · PostgreSQL · Tailwind
Your working data is spread across several spreadsheets that no longer agree, or the software you bought covers only part of the job and cannot be extended.
Orders, stock, production, delivery — in one place
The system a company actually runs on. An order arrives once and moves through picking, production, delivery and invoicing without being retyped. Stock decrements as it goes. The owner sees margin; the floor sees what to make next; support sees the customer's history. One database, one version of the truth.
Built with: PostgreSQL · Row-level security · Background jobs · Reporting
Sales, stock and accounts disagree with each other, and producing one simple report means reconciling numbers from several departments by hand.
The work that happens whether anyone remembers or not
Most wasted time is not one big problem — it is twenty small handoffs. Data retyped between systems, approvals chased by message, a report rebuilt from the same three files, an export someone runs every Monday. Automation connects those systems directly and puts the routine on a schedule.
Built with: Queues · Webhooks · Cron · API integrations
Someone on your team re-enters the same data into a second system every day, and everything stops when they are away.
For messy input and real judgement — nothing else
AI is the expensive answer to a problem plain automation usually solves. Where it genuinely pays is unstructured input: a document nobody formatted, a question phrased a hundred ways, a request that needs routing before anyone reads it. Everything we build cites its sources, so an answer can be checked rather than trusted.
Built with: RAG · pgvector · Embeddings · Evaluation harness
You receive a high volume of documents, invoices or requests that arrive in inconsistent formats, or answering the same customer questions is taking real time from your team.
For the people who are not at a desk
Android and iOS apps that share one backend with your web system, so the warehouse, the floor and the office are never looking at different numbers. Built to work where the signal does not: actions queue locally and sync when the connection returns.
Built with: React Native · Shared API · Offline sync
Part of the work happens in a warehouse, on a production line, or at a customer's site, where nobody is in front of a computer.
So a bad day is a rollback, not an outage
Software is only as reliable as what it runs on. We set up environments, deployment, backups and monitoring as part of the build rather than after it — so releases are routine, failures are visible, and recovery is a decision rather than an emergency.
Built with: Vercel · Managed Postgres · Object storage · CI/CD
Releases go out by hand, you are not confident the backups would restore, or you hear about downtime from your customers first.
Releases stop being events
Shipping by hand works right up until the night it doesn't. Tests get run when someone remembers. The build is copied to a server by a person following steps held in their head. A change that breaks checkout is found by a customer rather than by a check. A delivery pipeline takes that ritual off your team: every change runs the same checks in the same order, lands on a preview nobody can break, and reaches production only once it has passed — with one step back if it still goes wrong. This works on a codebase that already exists; nothing has to be rebuilt to get it.
Built with: GitHub Actions · Vitest · Playwright · Preview environments · Reversible migrations
Your product works and people use it, but every release is a manual ritual — tests run by hand if at all, files copied to a server, and nobody finds out a change broke something until someone outside the team says so.
We take on a small number of projects at a time, because the alternative is doing several of them badly. That means we say no to work we cannot do well: maintaining a codebase nobody can read, competing purely on price, or building around a process the client is still arguing about internally.
If we are not the right fit, we will say so in the first conversation rather than three months in.