Services
The four practices.
Design, build, host, and maintain. Engage for one, or the full stack. Same team either way. You own the product.
Design
Design
Product and interface work for software a company actually runs. We sit with the people who will use it, trace what they do today, and decide what the tool has to make easier.
You get a written picture before the build spends weeks in the wrong place: the flows, the interface direction, and a clear list of what we are leaving out. Enough for an engineering team to build from, including ours.
Design can be the whole engagement when you already have people who write code. It is also how most of our builds start, so the same people who shaped the product are still there when it is written. If the next step is construction, see Build. If you want the path from first call through care, read the process.
Build
Build
Custom applications, internal tools, and the integrations that connect them to systems you already use. We write to a scope you have seen, in short cycles. You review working software, not a slide about software.
You leave with the product and the code. Repositories and the accounts that should sit with your company are put in your name. We do not keep a private copy as the thing you rent back.
Build is enough when the design is already settled and you want it made. It also sits in the middle of a longer engagement: design before it, host and maintain after, if you want us to stay. Timing and cost come from the written scope. We do not publish a rate card, because the work is not the same twice.
Host
Host
We run the software in production. Releases, uptime, and the ordinary work of keeping a system available, so you do not have to staff a platform team for one product.
You get an environment we operate and a plain account of how it is deployed. The product stays yours, including the right to move it. Access that belongs to the company stays in the company's name.
Host stands on its own for software that already exists, whether we wrote it or not, once we can take responsibility for it. After a build, it is how launch becomes a normal week. Many companies pair it with maintain, because a system that is up still needs changes.
Maintain
Maintain
The work after people are using the system. Fixes, small improvements, and the updates a business asks for once the first version is no longer the question.
You get a written cadence and a place to send the next change. We say what we will look at and how often. New work that outgrows that agreement goes back through scope, in writing, before anyone pretends it was already included.
Maintain can start without a new build, on software we did not write, when we understand it well enough to own the care. On its own it is a retainer for a living system. Stacked with design, build, and host, it is the same team staying on after launch instead of handing you a folder and leaving.