Everything you hold when we finish
The specification, data model, test record, handover pack and runbook, named and described, so you know before signing what you will own.
- Code
- Handed over with the system
- Timing
- Each document exists before the next step starts
- Written for
- Your administrator and the next developer
Every build ends with documents, not only a working system: the specification with its out-of-scope list, the data model document, the test record, the cutover record, the handover pack, the operations manual and the runbook. The code sits in your repository from the first commit. Each document is written for whoever inherits the system.
- 01 Enquiry
- 02 Systems audit
- 03 Specification
- 04 Build
- 05 Pilot
- 06 Deploy
- 07 Handover
- 08 Support
Everything you hold when we finish sits at step 7 of the build cycle. You receive an operations manual and admin training.
Where handovers go wrong
Most disputes between a buyer and a software supplier are about something one side assumed was included.
That is why the out-of-scope list is the most important section of the specification. It is written at step 3, before any code, and it names the things a reasonable buyer might expect that this build leaves out. Reading it at step 3 is quick. Discovering its contents at handover takes a meeting nobody enjoys.
The second weak point is the list of what is unfinished. Every system goes live with something open: a slow report, a label nobody likes, an edge case parked for later. The handover pack carries an open issues list with each item's severity, so you know what you are inheriting before your administrator finds it.
The documents, step by step
Eleven documents, each tied to the step that produces it. Each one is written for a named reader, not for us.
| Document | What is in it, and who it is written for | When you get it |
|---|---|---|
| Current-state process map | Every step, handoff, wait and owner. Written for you, and for any supplier you show it to. | Step 2 |
| Specification | What is built, what stays manual, the connections, the acceptance tests and the out-of-scope list. The contract of work for both sides. | Step 3 |
| Data model document | Every record, field, state, permission and relationship. Written for the next developer. | Step 3, updated to handover |
| Interface specification | One page per connection: direction, trigger, payload, conflict rule and failure behaviour. Written for the next supplier. | Step 3, where there is integration |
| Test record | Every test traced to a specification line, with who ran it, when, and the result. Written for you and your auditors. | Steps 4 to 6 |
| Pilot report | What broke during the pilot, what was fixed, and what we chose to leave. Written for your management. | Step 5 |
| Cutover record | What moved when, the fallback, and the date the old process was retired. Written for your process owner. | Step 6 |
| Handover pack | Ownership confirmations, accounts, the credential register and the open issues list. Written for your administrator. | Step 7 |
| Operations manual | Daily administration: adding users, changing checklists, lead times and the common mistakes. Written for your administrator. | Step 7 |
| Runbook | Numbered procedures for when something fails, each starting with the symptom. Written for whoever is on call. | Step 7 |
| Change log | Every change after launch, with who approved it. Written for you. | Step 8 onward |
Inside the handover pack
The pack is handed over at step 7, whether or not you take support afterwards.
Ownership confirmation
A dated sheet confirming that the repository, hosting, domain and every third-party subscription sit in your company's name.
Administrator accounts
Accounts for the people you name, with the permissions each role needs and a note of who holds which.
The credential register
Every key and certificate the system uses: what it opens, who owns it and the date it expires.
Final data model and interface specifications
At their last revision, matching the system as it runs on the day of handover rather than as it was specified.
The operations manual and the runbook
Daily administration in one, numbered failure procedures in the other, both written in the language of the job.
The training recording
The administrator training session, recorded, so the person who joins next year starts from the same place.
The open issues list
Everything known and not yet fixed, each with its severity. Every system goes live with something unfinished, and this says what.
Four tests buyers rarely ask for
Each test in the record is traced to a line in the specification, with who ran it, when, and the result. Failed tests are re-run after the fix and both results kept. These four sit in the record wherever they apply, and acceptance is signed by your named person.
- 01
The full export
A complete data export taken from the live system, its record counts checked against the system itself, so leaving is a tested path rather than a promise.
- 02
The restored backup
A backup restored into a clean environment and counted. A backup nobody has restored is a file, not a backup.
- 03
The no-signal run
The app used on your worst site with the signal gone, records captured, then synced when it returns, with the queue checked.
- 04
The known-answer run
Questions or documents whose right answers are known in advance, run through the AI feature and checked before go-live.
A handover, walked through
A typical case: a logistics operator near Dammam port reaches step 7 of a proof-of-delivery app built for its drivers.
The handover session runs with the operator's IT lead and the two dispatch supervisors who will administer the app. The pack is walked item by item. The ownership sheet is checked against the hosting and store accounts, which were opened in the operator's name at step 3. The credential register lists the map service key, the messaging gateway key and the signing certificate, each with its owner and expiry date.
The export test is run again in the session, and its record counts are compared with the live system on screen. The supervisors add a driver, change a delivery checklist question and retire a vehicle using only the operations manual, and any step where the manual was unclear is rewritten before the pack is signed.
The operator holds the pack, the final data model, the runbook, a recording of the session and an open issues list of cosmetic items. Whether it then takes a support agreement or runs the app itself, the same documents serve.
Three documents your administrator opens
Numbered procedures, each starting with the symptom
Written for whoever is on call, who may not be the person who was trained. Each procedure opens with what a person will actually see, then the steps, then who to call at each point, if anyone.
- Restart the application
- Restore from backup
- Rotate a credential before it expires
- Clear a stalled sync queue on a device
- Reprocess messages an integration could not deliver
- Investigate a rise in an agent's exception count
- Switch an agent off
The shape behind every screen
Screens differ from one client to the next. The shape of an operational record does not, and it is what you keep when the screens change. A typical record, shown here with synthetic values, holds the fields below.
- Record number: WO-0412
- Type and form revision: work order, form rev 3
- Site and asset: Block C, AHU-07
- Status, with the reason where it waits: waiting, parts
- Owner and due date: a named technician, a date
- Evidence slots: photograph before, photograph after, signed sheet
- Approved by and when: a named supervisor, date and time
- History: every change of status, who made it and when
Daily administration, without calling us
The manual covers the changes an administrator makes in an ordinary month, written in the language of the job rather than the language of the code. It is the document most worth having in Arabic, and it can be written in both at specification.
- Adding and removing users, and what each role can see
- Changing a checklist question or a form field
- Adjusting lead times and escalation steps
- The mistakes new administrators make, and how to undo them
Asked about the handover
Do the documents cost extra?
Each document is part of the step that produces it, so it is scoped with that step.
What happens if you stop trading?
Your system keeps running. The code, data, accounts and documents are already in your name, and the systems use ordinary tooling another developer can pick up from the data model document and the runbook.
Can we get the documents in Arabic?
Yes, where you ask for it at specification. The operations manual is the one most worth translating, because it is the one your administrators open every week.
Can our auditor see the test record?
Yes. It is written so that an auditor asking how the system was verified can read it: each test, the specification line it proves, who ran it, when, and the result.
What if our team changes the system after handover?
That is what the data model document and the operations manual are for. If you later take support, the change log starts from the system as it stands, including your team's changes.
Read with this
How a build runs
The eight steps these documents come out of, and the two points where stopping is the right answer.
Read moreCommercialEngagement models
The four commercial shapes, and how each one ends.
Read moreAfter launchSupport after launch
Severity levels, the change log and the monthly note, for systems you want us to keep running.
Read moreExamplesExample projects
Example systems, described by their records and who signs, written as what we can build for any company.
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.
The first document comes in week one
The systems audit produces the current-state process map, and it is yours whether or not anything gets built afterwards.