Internal tools
Purpose-built applications for teams managing cases, approvals, schedules, exceptions or other work their core systems do not cover.
Custom Software & AI
We build the software no product on the market sells.
Internal tools, portals and integrations, with AI where AI is genuinely the right mechanism. Built against your real cases, and built to run in production rather than demo well.
The starting point
When this is worth doing
A demo takes a week. Something the business can rely on takes longer, and costs more to keep running.
So we start by trying not to build. If a rule solves it, we write the rule. If your existing system already does it, we configure it. We build when the job is genuinely specific to you and the volume justifies the cost of owning software.
What we build
What we build
We build the missing layer around the operation, whether or not that layer needs AI.
Client and staff portals
A focused interface for submitting requests, checking status, reviewing information and completing the next required action.
Integration layers
Custom services that coordinate several systems, apply business rules and expose one reliable workflow without replacing the useful tools underneath.
Applied AI features
Document extraction, classification, drafting, retrieval or decision support, with testing and human review matched to the risk.
How it gets built
How it is built
Anyone can make the easy 80% work. The last 20% is where these projects die.
Define the job
We agree who will use it, what the system must do, where its boundary sits and how we will know it works.
Design the whole system
Interface, data, business rules, integrations, permissions and operating ownership are designed together.
Build and test the edges
We start with the cases that break things: missing data, unusual inputs, conflicting rules, failed connections and uncertain AI output.
Hand it over
Deployed, monitored and documented. The code, configuration, prompts and tests are yours, and one named person owns it before we finish.
Questions
Before building anything.
When should we build instead of buy?
Build when the job is specific to how your business works and no product does it without heavy workarounds. Buy when a product already does it and the gap is configuration. Most of the time, buying wins.
How long does it take?
It depends on the data, the number of edge cases, and how much review the output needs. We scope the boundary before quoting. We would rather narrow the job than extend the timeline.
What happens when it gets something wrong?
That is a design question, not an accident. We decide in advance which cases the tool handles alone, which it escalates, and what a person sees when it is unsure.
Who owns it afterwards?
You do. The code, the prompts, the evaluation set and the documentation are yours. One named person on your side owns it before we finish.
Which models do you use?
Whichever fits the job, the data and the budget. That choice should be replaceable. We build the tool so the model can be swapped without rewriting it.
Can it use our internal documents?
Yes, and that is usually a knowledge system rather than a standalone tool. See Company Brain if the goal is answering questions from internal sources.