Understand
We learn the actual job before we design anything — including the awkward parts, the exceptions, and the reasons the current way is the way it is. Most bad software is a correct solution to a misunderstood problem.
What we do
We design, build and publish software.
Three lines of work that share one discipline — understand the job properly, then build something that holds up under it.
01 — Business software
The work nobody went into business to do.
Every business generates a second business inside itself: the records, the documents, the receipts, the renewals, the small administrative jobs that have to be done accurately and on time and that produce nothing anyone is paid for.
We build the tools that carry that load. Software for capturing, organizing and keeping business records, for the daily operational admin that piles up, and for getting information back out in a form somebody else will accept.
The test we hold ourselves to is simple: it should be faster to do it in the software than to not bother. If it is not, the software has failed and we have more work to do.
02 — Product development
From a sketch to something people rely on.
We take products the whole distance. That means the parts that are enjoyable — deciding what a thing should be, designing how it behaves, building it — and the parts that are not, which is most of what actually determines whether a product survives.
Release engineering. Compatibility with devices and platforms that keep changing underneath you. Migration when data has to move. Support for the version somebody is still running two years from now because it works and they see no reason to touch it.
We work across mobile and web, and we build systems to be maintained rather than to be demonstrated.
03 — Applied digital ideas
The fields software has not properly arrived in.
Technology does not reach every industry at the same speed. Some fields have had four rounds of reinvention; others are still running on paper, on habit, and on somebody's memory of how it was done last time — not because they are behind, but because nobody has built them anything worth switching to.
That gap is the part of our work we are least willing to give up. We investigate where digital tools can go next, in industries outside the ones software usually serves first, and we are deliberate about not limiting ourselves to the fields we already know.
Some of that work becomes a product. Some of it stays research and teaches us something we use somewhere else. Both are worth the time.
How a project goes
Four stages, in order, every time.
No stage gets skipped because a deadline is close. Skipping one is how you arrive at the deadline with something that does not work.
Design
We decide how it behaves before we decide how it looks. What happens when the signal drops, when the input is wrong, when somebody taps the thing they did not mean to tap. Those answers are the product.
Build and prove
We write it, then we try to break it on purpose — because a test that has quietly stopped checking anything reports a healthy system in exactly the same words it would use for a healthy one.
Ship and stand behind it
Release is the beginning of the obligation, not the end of it. Software that holds records has to keep working through platform changes, new devices and years of daily use.
Have something that needs building?
Tell us the problem in your own words. We will tell you honestly whether we are the right people for it.