About
A small studio that ships and then keeps running it.
T-Shell builds the software companies operate on — and, more often than not, keeps operating it afterwards. That second part is why the first part is written the way it is.
What we actually are
A small engineering studio working out of Da Nang, Vietnam, with clients in the UK, the EU and across Southeast Asia. Four-plus years of commercial work behind it: twenty-plus WordPress builds, a multilingual network of twenty-three sites run from one codebase, an eleven-tool SEO platform, a Telegram commerce app taking card, Stars and on-chain payments, and the outbound engine that probably sent you here.
Why we run what we build
Almost everything we offer, we built for ourselves first. That is not a marketing line — it is the reason the offer looks the way it does. A team that hands a system over at launch optimises for the launch. A team that is still on call for it in month eight optimises for the parts that fail quietly: idempotency, reconciliation, what happens when a provider redelivers a webhook or a worker dies holding a task.
It also means we know which of these things are hard. The pages under Services each say what the difficult part is, and those sections are written from having got them wrong at least once.
How we work
- The spec comes before the code. You approve behaviour in plain language, not a wireframe. Arguing on a page is far cheaper than arguing in a database migration, and it is the only way a fixed price stays fixed.
- Slices, not big-bang delivery. Something works and is deployed where you can click it every week. A project that goes wrong goes wrong in week two rather than week ten.
- Tests where the money is. Not coverage theatre — the seams between components, the payment and data paths, and everything that touches a customer.
- You own the result. Code in your repository, containers you can run anywhere, credentials in your accounts, documentation written for whoever comes next. Leaving should be easy; that is what makes staying a choice.
What we will tell you not to build
Some of what gets asked for should not exist: a dashboard nobody will open, an integration that saves twenty minutes a month, an AI feature that a lookup table would do better and cheaper. Saying so costs us a project and buys a client who believes the next thing we say. We would rather have the second.
Start with the problem, not the solution.
Describe what is slow, manual or breaking. We will tell you what it would take — and whether it is worth it.