Elegant, effective software craftsmanship
We work with founders and teams. Bring us a product idea, or an existing project in whatever state it's in, and we elevate it — with methods proven long before software existed, and responsibility for the outcome rather than the hours it takes.
Where the work starts
Most software work doesn't begin at zero. It begins somewhere specific — and the right first move depends entirely on where that is.
Ikigai — MVP development
“A reason for being” — deciding what deserves to exist.
You have an idea and the conviction to back it. What's missing is a version small enough to put in front of real people, and the evidence that comes back when you do. Ikigai takes an idea — including an AI or agent idea — to a working MVP in weeks, not quarters: scoped honestly, built properly, released to real users.
From idea to working productKintsugi — Project rescue
“Joined with gold” — the repair is shown, not hidden.
The software exists, but it isn't doing what it was supposed to do. Unfinished, unstable, abandoned by the people who built it — or written by an AI and now impossible to change. Kintsugi is the repair: an honest account of what you have, and a route back to a project that runs.
Rescue a failing projectKaizen — Ongoing development
“Change for the better” — small improvements, forever.
The product is live and earning its keep — which is exactly when it's easiest to stop paying attention. Kaizen is ongoing development done with intent: features, maintenance, and measurement, so the product keeps getting measurably better.
Ongoing development, measuredWhere the names come from
The names are not decoration. Each one is a practice that already existed, with an argument attached — and the argument is the reason we chose it.
円相
circle form
In Zen, an ensō is a circle drawn with one or two uninhibited brushstrokes. It is made in a single breath and never corrected — whatever the hand did is what the circle is. Many are drawn deliberately open, the ends not quite meeting.
The open circle is the honest description of software. It is complete enough to be useful and it is never actually finished. A closed circle would be a claim no product can support.
The four-circle diagram that circulates online — passion, mission, profession, vocation — is a Western invention layered onto the word much later. In Japanese, ikigai is humbler and more ordinary: the reason you get up, as likely to be a small daily thing as a grand purpose.
We use it in the plain sense. Before anything is built, the question is what would make this worth existing at all — for the person using it, not for the person funding it. Most software that fails was never able to answer that.
The craft of mending broken pottery with lacquer dusted in gold. The story usually told is of a fifteenth-century shogun who sent a favourite tea bowl to China for repair and got it back stapled with ugly metal, prompting Japanese craftsmen to find a better way. Whether or not that is how it began, the principle held: the break is filled rather than disguised, so the mended object shows its history — and is often valued more for it.
A codebase that has been through something is not worth less than a fresh one; it knows things a fresh one doesn't. Repair keeps that knowledge. A rewrite that pretends the history never happened throws it away and pays for the same lessons twice.
An ordinary Japanese word that became a manufacturing discipline after the war, shaped in part by American quality-control teaching and carried furthest inside Toyota. Its argument is unglamorous: improvement belongs to the people doing the work, happens in small increments, and happens continuously — not in transformation projects announced from above.
The same is true of a live product. Big releases arrive late and land hard. Small changes, shipped often and measured honestly, compound — and they let you tell improvement apart from activity.
Products that answer back
An agent your customers can actually talk to: one that onboards them, answers them, acts for them, and gets measurably better as the product grows. And increasingly the reverse too — your customers' own agents arriving to use your product, expecting it to be ready for them.
We build both the way we build everything: small honest first versions, real measurement, responsibility for the outcome. The parts that don't make demos — evaluation suites, guardrails, cost control, a human in the loop where one belongs — are in scope from day one, because they are the difference between a product and a demo.
Wherever your product is, this fits the same three situations: build it in (Ikigai), repair what isn't working (Kintsugi), or keep it improving with real users (Kaizen).
One company
The practices are not steps in a fixed process. They describe the condition a product is in, and a product can be in any of them at any point in its life.
What matters is naming the situation correctly. Building new features on a broken foundation is not improvement, and rewriting something that mostly works is not repair.
Positioning
We are responsible for the product, not the hours. EnsouWorks is not an agency selling development time — development time is easy to sell and tells you nothing about whether the product got better.
The work is the whole product, which means these questions belong to us too:
That's also why the first conversation is free and specific. You describe the situation; we tell you what we would actually do next — including when the honest answer is "don't hire us yet."
How an engagement starts
You write.
A few sentences about where the product is. No pitch deck, no RFP, no discovery-call gauntlet.
We talk.
One 30-minute call to name the situation. If we're not the right fit, we'll say so and point you somewhere better.
We propose the smallest useful engagement.
A fixed scope with a clear outcome — an MVP shipped, an audit delivered, a first month of improvement measured — so you can judge us on a result, not a promise.
What you can hold us to
EnsouWorks is new enough that there is no wall of client logos to show you, and we would rather say that plainly than assemble a vague one.
So here is the substitute, and we think it is the better test anyway: every line below is checkable from the first day you work with us, and you are entitled to hold us to all of it.
The person who answers is the person who does the work.
No account manager in between, and nothing handed down to someone more junior once the contract is signed.
Fixed scope, fixed price, agreed before we start.
The number does not move unless the scope does, and any change to the scope is a conversation before it is an invoice.
The audit is yours either way.
Use it to work with us, to brief an internal team, or to stop. There is no obligation to continue — the honest diagnosis is the product.
You own everything.
Source, documentation, infrastructure, accounts. No proprietary framework you have to keep paying us to maintain.
We will tell you not to hire us.
When the honest answer is that you do not need this yet, or that someone else is a better fit, you will hear it — and where we can, we will point you to them.
Start here
No pitch deck required. A short description of the situation is enough for a useful first conversation.