Four ways to bring us in
Some teams need something built. Some need a system to stop failing. Some need senior engineers beside them for a while and some want AI working inside real systems without it becoming a liability. Pick the one that sounds like your week.
01New buildsRaw billet, cold
Built once, built to carry the load.
Who it's for
Founders, heads of product and digital teams with a product, platform, portal or internal tool to make. Often there's a deadline that matters, like a tender, a launch or a board meeting, and no room to build it twice.
Signals you need it
- You have a clear problem and a direction, and need it built properly.
- Your last build looked fine in the demo and struggled with real users.
- The thing you need connects to systems you can't afford to break.
- You need it fast, and you need it to survive the week after launch.
The first two weeks
We work out what the system has to carry and where it is likely to fail, then agree the architecture and the order of work with you. The riskiest parts go first. By the end of the second week you have a plan you can hold us to and, on most builds, the first working version you can open and use.
What you get
- Working software in your repository, on your accounts.
- Tests, monitoring and documentation, written as part of the build.
- A handover your team can run, or us staying on if you'd rather.
Typical shape
A small senior team with AI in the making. We've built a working CRM platform in eight days and run a site build in a week. Larger platforms run in numbered releases over months.
02Rescue and stabiliseCherry red, cracked
Bring us in when it's failing.
Who it's for
CTOs, operators and founders whose system is failing in front of customers, or who've been left holding a platform by a vendor that stopped answering.
The first two weeks
Triage comes first, and it takes days. We get access, read the logs and the code, and find what is breaking. Then we stop the bleeding: roll back, fix the immediate cause or contain it, so customers stop feeling it. Only after that do we fix the underlying cause, and we give you a written view of what else is at risk and the order we'd tackle it in.
- 1Get accessRead the logs and the code
- 2Find what is breakingTriage takes days
- 3Stop the bleedingRoll back, fix or contain it
- 4Fix the underlying causeCustomers have stopped feeling it
- 5What else is at riskIn writing, in the order we'd tackle it
Taking a platform back from a vendor
We move the code first while access still exists, then the data, then the accounts, switching the domains last.
- 1Codewhile access still exists
- 2Data
- 3Accounts
- 4Domainsswitched last
What you get
- A system that stops failing, with the cause found and fixed.
- A plain account of what was wrong and what else is at risk.
- Control of your own code, servers and accounts.
Typical shape
Fast at the start, then steadier. One legal marketplace went from the decision to take its platform back to live on its own domains in six days. Some rescues end there. Others go on to a rebuild or to ongoing support.
03Engineering supportHeld at working heat
Senior engineers beside your team, or running it for you.
Who it's for
Teams with a live product and too few senior people. Businesses whose platform needs looking after and who would rather not hire a whole team to do it.
Signals you need it
- Your team ships, but nobody has time for the architecture, the security or the upgrades.
- You've lost the person who understood the system.
- Releases are irregular and nobody can say what's in the next one.
- You want someone accountable for the platform without building an engineering department.
The first two weeks
We read the system, the backlog and the way releases happen today. We agree with you what we own and what your team owns, set up a release rhythm and pick the first things worth fixing. If we're working alongside your engineers, we pair with them from the first week.
What you get
- Numbered releases on one roadmap, each with release notes.
- Upgrades and patches that happen without anyone chasing them.
- The measures you care about, reported against a baseline.
Typical shape
Ongoing, release by release. We run one consumer app this way today, reporting against the measures set before the rework shipped. Scope, hours and response times we agree with you.
04AI in productionQuenched and set
AI inside real systems, kept on a short leash.
Who it's for
Businesses that want AI doing real work in their operation, on real data, and need it to be safe, cheap to run and easy to check.
Signals you need it
- Your team is pasting confidential data into a chat tool to get work done.
- AI output varies run to run and someone has to recheck all of it.
- You need an assistant that answers from your own documents and doesn't make things up.
- You want AI to take actions, and you need to see what it did and reverse it.
The first two weeks
We look at where the work happens and what the AI would touch. Then we decide where AI belongs and where it doesn't. Sometimes the safest answer keeps AI out of the document path entirely: one renovation company's quotation tool reads only the client-price columns and runs in the browser, so cost and margin figures never leave the company. Where AI does act, we set how much it may do on its own, log every call and show where it ran.
What you get
- AI only where it earns its place, with permissions you set.
- A record of every action it takes, and a way to undo it.
- Your data kept inside your own accounts where that matters.
Typical shape
Often small and quick to prove: a working version in days, then tuned against how your people really work. Running costs are part of the design from day one.
What you hold at the end
The code lives in your repository, on your accounts, from the first commit. These are the pieces each way in leaves with you, and none of them stays with us.
Questions we get asked
No. Most of what we do is new builds. Rescues are where the same standards get tested hardest, so we talk about them.
Yes. We can work alongside your engineers, take one part of the system off their hands or run the whole thing. We agree with you at the start who owns what.
You do. It lives in your repository, on your accounts, from the first commit. When we took a legal marketplace back from its vendor, the point of the whole exercise was the client owning its code, servers and WhatsApp number.
AI drafts much of the code, tests and screens. A senior engineer reads and signs off everything before it merges. Which tools may see your code and data is agreed with you before we start, and where data shouldn't leave your environment, we build so it doesn't.
Whatever suits the system and the people who'll run it after us. On a rescue that usually means the stack you already have, made sound. On a new build we'll recommend one and explain why, and we agree it with you.
Tell us it's urgent on the form and we'll pick it up first. How fast we can get hands on the system depends on access and on what's broken, so we agree the first steps with you on the first call.
It depends on the shape of the work. After the first conversation and a look at the system, you get a written plan and a price for it. We don't publish rates because the jobs vary too much for a number on a page to mean anything.
Yes. We're based in Singapore and most of our work is in South-East Asia, and we've delivered for clients in Australia and across Asia Pacific.
If it doesn't fit neatly, tell us anyway.
A few lines about what's happening is enough. An engineer will read it and tell you which of these it is, or that it's none of them.