Most software goes wrong long before anyone writes code. It goes wrong when the problem was never written down clearly, when the first version was scoped to do everything, or when nobody asked whether the thing already exists.

Discovery is the work of answering those questions on paper, where changing your mind is cheap. We go through what the business actually needs, what the software has to do to satisfy it, and where the genuine risk sits. You come out with a specification precise enough to build from and honest enough to decide against.

The specification is written in Eidos, our own system for defining a product: one plain markdown file per unit of the thing, kept in a folder you can put in any repository, and checked against a framework so it stays consistent as it grows. That is the format we define our own products in, and it means the spec keeps working after we leave. Any developer can read it, any coding agent can work from it, and eidos check will tell you when a change has made it drift.

The deliverable is yours. If you take it to another developer, or decide not to build at all, the engagement still did its job.

Plenty of businesses are held together by steps that live in someone’s head: a spreadsheet that gets copied every Monday, a system that only one person knows how to update, an approval that waits on a specific inbox.

This work starts by tracing how a job actually moves through the business, from first contact to invoice, and finding where it stalls or gets done twice. Some of what turns up is fixed with configuration you already pay for. Some of it justifies a small piece of custom software. The point is telling those apart before committing to either.

You get a clear read on where the time goes and a plan to get it back, sequenced so the business keeps running while it happens.