How We Build

We build with the people who know the work. That can mean sitting beside someone while they untangle a spreadsheet, making a tool they have wanted for months, or helping a leadership team decide what deserves its attention. Often it means moving between all three.

The useful contribution determines the job. Sometimes we write code. Sometimes we help someone else write it. Sometimes a conversation reveals that the proposed software would make a bad process considerably more efficient at being bad.

Join the work

The beginning usually looks like ordinary onboarding. Meet the people, get access to the systems involved, understand what is happening, and find somewhere to contribute. We do not need to establish a new operating model before opening the files.

People have usually found ways to make an imperfect arrangement work. A spreadsheet may contain years of practical judgment. An apparently redundant conversation may be where a team catches mistakes or learns what customers actually need. Before replacing either, we want to understand what would disappear with it.

We ask people to show us a real example. Where did it come from? What happens next? Which part takes care, and which part is just moving information between places? The answers give us something more useful than a list of desired features: a view of the job, including the parts its official description leaves out.

From there, we agree on something worth doing and get to work. The agreement might fit in a conversation. If there are unresolved choices, writing them down can help. The document earns its place by helping someone act.

Make the first useful thing

A first version gives people something to use and correct. We want to find out whether it helps with their actual work, which means trying their inputs and paying attention when the result is wrong, awkward or simply unnecessary.

A workbench is often a good place to start. It keeps the instructions, tools and examples together so the work can be repeated and improved. The person doing the job can bring their knowledge; an AI assistant can handle much of the mechanics; we can make the technical changes and help the person understand them. There is no requirement for everyone to become a programmer before they can contribute.

One example among many is a colleague we helped get started with source control and AI coding tools. She now contributes her own changes and onboards her team. The time spent working alongside her became something she can pass on. That is one form enablement can take; other people contribute through their judgment, examples, reviews, and the help they give colleagues.

The first useful thing may remain small. A tool one person runs when they need it can be a good result. An existing application may already do most of the job. Teaching someone how to get more from it may be a better contribution than building a replacement.

For a public-health program delivering naloxone by mail, the early idea involved a detailed questionnaire. We started with what the recipient needed and reduced the request to what delivery required: where to send the package. Separating delivery from reporting and optional learning protected the recipient’s privacy and left operators with fewer fields to check, less sensitive information to manage, and clearer exceptions to resolve. That decision to build less made the service simpler on both sides.

We call the reusable methods and starter structures behind our work Skillpad. They save us from repeatedly solving the same setup problems. They are useful to the extent that they make the customer’s work easier; the customer does not need to become an adherent.

Let the job determine the architecture

Software needs different things as people come to depend on it. A local script and a public service are different commitments. Adding users, retaining important records or acting in another system changes what someone needs to understand and maintain.

That is when architecture becomes a practical conversation. Where should this run? Which systems already hold the information? Who will change it? What needs to keep working when a person is away? We prefer components the team can understand and support, including infrastructure they already use. Familiarity is worth something. So is having fewer moving parts.

For a workflow that has to survive interruptions, it can help to make its states explicit. A request might be waiting for information, ready to act on, in progress or complete. The software can preserve that position and make the next action clear. An uncertain result can remain available for someone to resolve instead of disappearing into an inbox or being treated as settled.

AI can help interpret an input, compare material or draft an answer. A repeatable business rule often belongs in ordinary code. Where an AI interpretation changes what happens next, we want to understand how a mistaken interpretation would show up and who can correct it. Calling the surrounding workflow deterministic does not make the interpretation correct.

The amount of care follows the work. A private draft that someone reads before using it asks for different attention from a system purchasing postage or changing a customer record. We deal with those differences in the design itself. Another approval ceremony is useful only if it resolves something the work genuinely needs resolved.

Make the work understandable while it happens

Customers should be able to see what we are doing, question it and influence it. Working files, source code, decisions and examples belong where the people involved can use them. A short explanation of a consequential choice is usually more useful than a presentation announcing progress.

Transparency still takes work. An open repository is not self-explanatory. We may need to walk through a real example, describe why something was done a particular way, or help a colleague make their first change. Teaching and translation are part of building when they make another person more capable.

We also need to say when something is not working. A promising idea can prove unnecessary. A tool can make one person’s job faster by giving someone else more to check. A small saving can be overwhelmed by maintenance. Those are reasons to change the plan, even when continuing it would give us more billable work.

Our independence is useful here. We do not need to preserve a role in the customer’s hierarchy or turn every discovery into a larger engagement. We can tell people what we think, show why, and help them decide what to do with it.

Leave something people can carry on

Customer work belongs with the customer: the source, the records, the tools, and the knowledge needed to use and change them. Ownership becomes practical when someone can find the relevant material, explain the important choices and do the next piece of work.

Sometimes that is a person running and adapting their own workbench. Sometimes it is an engineering team taking on a service. Sometimes it is a leader who can now make a decision they previously had to outsource. We work with the people who will carry it on, instead of saving transfer for a final presentation.

There may be a good reason for us to stay involved. The work may still benefit from our skills, or everyone may simply want to keep working together. But continued usefulness is a better reason than a dependency we designed into the system.

We are a small company doing work with people we like on problems we find interesting. We charge for our time. The aim is to make that time useful, including by making ourselves unnecessary where we can.