Custom applications, multi-tenant platforms, mobile apps and the integrations that hold an estate together. We build the unglamorous parts — permissions, audit trails, migrations, tests — because those are what decide whether a system is still running in three years.
Every bullet below is work we have shipped. Where a line looks like filler on another company's site, it is here because a client needed it and we built it.
Bespoke web and desktop software built around how your organisation actually works.
Subscription products with the parts nobody puts in a demo: tenant isolation at row level, audit logging written on the way in, billing hooks, and a migration path that does not require downtime.
iOS and Android, including on-device inference and private distribution where an app is for one organisation rather than the public store.
Connecting systems you already pay for.
Marketing sites, portals and storefronts that load fast on a mid-range phone and rank because the foundations are crawlable, not because someone stuffed keywords in afterwards.
Moving an ageing system forward without a rewrite-everything gamble.
The same artefacts every time, regardless of project size.
Deliberately narrow. A team our size claiming twenty frameworks is claiming one thing badly, twenty times over.
Open the work page for the full case note on any of these, including what did not go to plan.
Led the move from Java Swing to JavaFX, achieving an 80% improvement in user satisfaction.
Procurement to disposal with 30% fewer reporting errors and 40% stronger access control.
Multi-tenant SaaS across thirteen core tables, in production with paying customers.
Answered as we would answer them on a call, including the ones with awkward answers.
Yes. We start with a short review of what is there, what is tested and what is load-bearing, then propose the smallest change that gets you moving. We do not open by recommending a rewrite.
That is the intent. Building for your team to maintain costs more up front and less over three years. Handover includes documentation, tests and sessions until your engineers are comfortable.
Then we write for that. Documentation aimed at whoever will actually operate it, plus a support agreement so there is someone to call.
The reason a product is not working is rarely where the client first thought it was, so these three sit alongside this one more often than not.
Describe the problem rather than the specification. If a smaller piece of work would answer it, we will propose that instead.