Build it, then be the ones who have to support it.
Software written by a team that will never get the 7am phone call tends to look different from software written by a team that will. We do both, deliberately, because it changes the decisions.
The handoff is where systems go wrong.
The usual arrangement splits these: one firm builds, another supports. The seam between them is where undocumented assumptions live, and it is the reason so many internal systems end up with nobody who fully understands them.
When the same people carry the pager, logging gets written properly, error messages say something useful, and the runbook is accurate — because otherwise we are the ones paying for it at 7am.
Ask any vendor what happens at 2am when their system fails. If the answer involves a different company, you have found the seam.
Two halves of the same engagement.
You can take either on its own. Most clients start with one and add the other within a year.
Systems that match how you actually work
Off-the-shelf software encodes somebody else's process. Usually that is fine and cheaper. Occasionally your process is the business, and bending it to fit a product costs more than building the right thing.
We will tell you which situation you are in, including when the honest answer is to buy a product instead.
- Line-of-business systems
- Case management, job tracking, scheduling, quoting — the system your operation runs on rather than a peripheral tool.
- Integration layers
- Making existing systems talk without replacing them, with reconciliation so you can prove nothing was lost in transit.
- Legacy replacement
- Retiring a system nobody can maintain, incrementally, with both running in parallel until the new one has earned trust.
- Reporting & data access
- Getting information out of operational systems without a person exporting spreadsheets every Monday morning.
Keeping it all running
Support that is measured rather than promised. Response targets are written into the agreement, reported against monthly, and we show you the months we missed as well as the ones we hit.
Coverage is defined per system, because treating a payroll cutover and a printer queue as the same priority helps nobody.
- Service desk
- A first line your staff can actually reach, with escalation to the engineers who built the system rather than to a script.
- Monitoring & alerting
- Instrumented so we usually know before you call. Alerts are tuned rather than exhaustive — an alert nobody acts on is noise.
- Patching & maintenance
- Scheduled windows agreed with you in advance, with a rollback tested before the window opens.
- Backup verification
- Scheduled restore tests, not just backup jobs that report success. The report tells you the date of the last successful restore.
What we commit to, in numbers.
These are the standard tiers. They are adjustable during contracting — what is not adjustable is that there are numbers at all.
| Severity | What it means | First response | Update cadence |
|---|---|---|---|
| Critical | A business-stopping outage. Nobody can work, or data is at risk. | 30 minutes | Hourly until resolved |
| High | A core function is unavailable, but a workaround exists. | 2 business hours | Twice daily |
| Normal | Something is broken or degraded for an individual or small group. | 1 business day | Every two days |
| Request | New access, new hardware, a change — nothing is broken. | 2 business days | On progress |
First response means a named engineer has picked it up and told you what they are doing — not an automated ticket acknowledgement. Resolution times depend on the fault and we will not pretend otherwise.
From first conversation to steady state.
Discovery
We map the process as it is actually performed, including the workarounds people do not mention in meetings.
Build or buy
A written recommendation. Where a product would serve you better, we say so and can help you select one.
Incremental delivery
Releases every two weeks into a real environment. The first users are live long before the last feature ships.
Support from day one
Response targets apply from first production use, not from project close. There is no unsupported gap.
Describe the process, not the software.
Walk us through what your team does and where it breaks down. We will design the right solution around it, whether that is a full build or a targeted change.