Four ways to work with us
A systems audit on its own, a fixed-scope build, a setup followed by a monthly service, or support on something already live, each with a stated way of ending.
- Shapes
- Four, each bought on its own
- Systems audit
- One week, at a fixed fee
- Prices
- Quoted after scoping, not published
- Ending
- Written into each agreement
There are four engagement shapes: a one-week systems audit bought on its own, a fixed-scope build handed over to you, a setup followed by a monthly service we run, and a support agreement on a live system. Each is priced after scoping, as a fixed fee, a fixed quote or a monthly fee, and each agreement says how it ends.
Where cost arguments start
Most arguments about software cost begin with something one side assumed was in scope.
A quote is only as clear as the scope it prices. So the fixed quote for a build comes after the systems audit, against a written specification whose out-of-scope list names what a reasonable buyer might expect and this build leaves out.
Wanting something different halfway through is normal. It becomes a change request: written, quoted and approved by you before any work on it starts. The specification is what makes the line between a fix and new work visible to both sides.
The four shapes, side by side
The first shape is where a build begins, and the next one is chosen with the process map in hand.
| Shape | What you buy, and how it is priced | How it ends |
|---|---|---|
| Systems audit | One week inside the workflow: a current-state process map and a written recommendation, which is sometimes to build nothing. A fixed fee. | When the map is delivered |
| Fixed-scope build | The system in the specification, built, piloted and handed over, with the code in your repository from the first commit. A fixed quote after the audit. | At handover, with the pack |
| Setup, then monthly service | A system we set up and then run for you, such as the monthly client report assembly or a prequalification vault kept current. A setup fee, then a monthly fee driven by sites, submissions or documents. We operate it. | On notice, with an export and the runbook |
| Support agreement | Fixes, small changes and monitoring on a live system, whoever built it. A monthly fee by tier, with the response window per severity set by the tier. | On notice, with the runbook brought up to date |
What each shape leaves with you
From a systems audit
The current-state process map and the written recommendation. Both are useful to any supplier you show them to, including us.
From a fixed-scope build
The running system, the specification, the data model document, the test record, the cutover record and the handover pack.
From a monthly service
The outputs each month for your approval, and at the end a running system in your accounts, its export and the runbook to operate it.
From a support agreement
The change log of everything touched, a short monthly note on what is open and trending, and an up-to-date runbook when it ends.
Two shapes in one engagement
A typical case: a property operator in Khobar runs residential compounds and owes each owner a monthly maintenance report.
It starts with the systems audit. The map shows the reports are assembled by hand from a ticket export and a chat thread, and that nobody inside wants to own the assembly. The recommendation is a small build for capture and assembly, then a monthly service for the assembly itself.
The setup covers the capture form, the report template and the owner list. From the first month we assemble each report from the records and send it to the operator's contract manager, who approves it before it goes to the owner. The data, the template and the accounts sit in the operator's name throughout.
The agreement states how the service ends. If the operator later hires a coordinator to run it in-house, notice is given, the runbook and operations manual are brought up to date, and the coordinator takes over a running system rather than rebuilding one.
Which shape fits
When you are not sure what to build
The place to start when you know which process hurts but not whether software is the answer. The audit is priced on its own so that a recommendation to stop is credible.
- One week, a process map you keep
- A written recommendation, which may be to build nothing
When you will run the system yourself
You have someone who will own the process and administer the system. The build ends at handover, and your team runs it from the operations manual.
- A written specification with an out-of-scope list
- Working software at step four of eight
- Code in your repository from the first commit
- Handover pack, operations manual and runbook
When the work repeats and nobody inside wants it
Some work is repeated every month: assembling client reports, keeping a prequalification vault current, running an obligation register and chasing its owners. A setup followed by a service we run can cost less than building it and staffing it yourself. You still approve every output that leaves your company.
- Monthly fee driven by sites, submissions or documents
- Ending it means taking over a running system
When the system is live and needs looking after
For a system we built or one another supplier built. Severity levels are defined before anything breaks, and every change is logged with who approved it.
- Response window per severity, set by the tier
- A change log and a monthly note
- Configuration stays with your administrator
How we charge, answered
Can we start with the systems audit and decide later?
Yes. The audit is priced so it can be bought that way. You hold the process map and the recommendation, and the decision on a build waits until you have read them.
Is the work billed by the hour?
Work is priced by what it produces: a fixed fee for the audit, a fixed quote for a build against its specification, and a monthly fee for a service or a support tier. You know the number before the work starts.
What happens if we change what we want mid-build?
It becomes a change request, written, quoted and approved by you before work on it starts. The specification's out-of-scope list is how both sides tell a fix from new work.
Can we move from a monthly service to running it ourselves?
Yes. The runbook and the operations manual are written for that day, and the data and accounts are already in your name.
Can you support a system another supplier built?
Yes, after a review. We start by reading the code, the data and whatever documentation exists, and write the missing runbook first. That review is quoted before support begins.
Read with this
How a build runs
The eight steps, and the table of what moves a quotation up or down.
Read moreHandoverWhat you receive
Every document in the handover pack, with when you get it.
Read moreAfter launchSupport after launch
Severity levels, what counts as a fix, and how leaving support works.
Read moreFAQQuestions before you commit
Ownership, Arabic, timing and data, answered before the first call.
Read morePart of one system
Every division keeps records to the same standard, so the second one you need works the way the first one did.
Every build starts with one week
The systems audit is priced on its own and ends with a process map you keep, whichever shape comes next.