Mobile apps
iOS and Android apps that feel at home on the device: quick to open, careful with the battery, and still useful when the signal drops.
KT · A software studio
Software built
with passion.
We’re a small studio that still believes software is made by people, for people. A machine can write a line of code now — but every line still has an author, and you can tell.
What we build
Apps, backends, and the AI in between.
Four kinds of work, one way of doing it. Most projects touch more than one — a mobile app needs a backend, and a backend is increasingly something an AI assistant talks to.
Web apps
Products, dashboards and internal tools that load fast, work on every screen, and stay easy to change long after launch day.
Backends & APIs
The part nobody sees: APIs, data models, integrations and background jobs — secure, observable, and pleasantly boring in production.
AI & MCP servers
Model Context Protocol servers that give AI assistants scoped, auditable access to your data and tools — and the AI features built on top of them.
What we believe
Care is a feature.
You cannot see craftsmanship in a screenshot, but you feel it every day you use the thing. That feeling is what we are actually building.
Made, not assembled
Anyone can wire libraries together. We care about the decisions in between — the naming, the edge cases, the error message someone reads at 2am.
Simple on purpose
Simplicity isn’t what’s left when you run out of time. It’s what’s left when you keep going after the thing already works.
Built to be lived with
Code gets read far more often than it gets written. We write for the person who inherits it — usually, eventually, ourselves.
How we work
Close to the problem,
close to the people.
We’d rather understand one problem properly than ship five half-answers to it. That means fewer meetings, more conversations, and working software early enough to change course cheaply.
- Senior hands on the work, no layers in between
- Something real to look at within days, not months
- We tell you when we’re wrong, before you find out
- The work is handed over understood, not just delivered
Build it the way you’d want to inherit it. That’s the whole brief.
Framing
A short, intense start. We sit with the problem, the constraints and the people who live with it, then come back with the shape of an answer — and an honest list of what we’re still unsure about.
A thin slice
Something real, running end to end, within days. Not a prototype to throw away: the first piece of the actual thing, small enough to argue with.
Build in the open
Working software every week, a board you can read without us, and a direct line to the people writing the code. Progress you can check, not a status report you have to believe.
Hardening
Tests, logging, the unglamorous failure paths. The part most projects skip and then pay for in year two, with interest.
Handover
Documentation written for whoever comes next, a walkthrough with your team, and a stretch where we’re still around while they take the wheel.
Since early 2026
AI in the loop,
not in charge.
We run an AI-assisted lifecycle on our own work first — the same one we’d bring to yours. It takes the repetitive parts off the table. It doesn’t get to decide what good looks like.
What it buys you is tempo: a working slice in days rather than weeks, fewer rounds of “that’s not quite what I meant”, and more of our attention left for the decisions that actually need a person.
Specs start at draft two
Agents read the existing code, tickets and docs and produce a first-pass spec. We spend the meeting disagreeing with something concrete instead of staring at a blank page.
Scoped work, isolated branches
Coding agents pick up tickets with a clear boundary and work on their own branch, held to the same types, linters and tests as anyone else. A named engineer owns every branch.
Two passes, one of them human
Every change gets an automated review for correctness, security and the things diffs hide, before a person opens it. Human review doesn’t go away — it starts better informed.
The cases people forget
Bad input, partial failures, the third retry, the empty state. Generated where it’s tedious, then read and edited by us like any other test.
Scripted, repeatable, boring
One command to deploy, the same on every machine, with the change log assembled from what actually landed rather than from memory.
The project explains itself
Each repository carries a written account of how it works and why. It keeps new people and new agents on the same page — and it’s the documentation you wanted anyway.
The rules we hold it to
- A person is accountable for every line that merges
- Every change is read by one of us before it ships
- No agent holds production credentials or customer data
- Your code is not used to train anyone’s model
- If your contract rules agents out, we build without them
- We measure whether it helps — if it doesn’t, it goes
Tell us what you’re building.
If it’s interesting, difficult, or both, we’d like to hear about it. No sales call, no pitch deck — just a reply from someone who would work on it.