Internal tools for work that outgrew spreadsheets
Web applications for the work a company actually repeats, built around a data model you own and can walk away with.
- Specification
- One week of mapping, then a written scope
- First usable increment
- Two to five weeks after the specification
- Data export
- Exists from the first release, not on request
- Languages
- Arabic and English, right-to-left designed in
An operations build starts by naming one record and deciding who may change it, not by drawing screens. Inspections, work orders, registers, approvals, portals. What you keep is a documented data model and a tested export, in your own repository.
- 01 Enquiry
- 02 Systems audit
- 03 Specification
- 04 Build
- 05 Pilot
- 06 Deploy
- 07 Handover
- 08 Support
Internal tools for work that outgrew spreadsheets sits at step 4 of the build cycle. You receive a working increment you can use.
The spreadsheet is rarely the problem
Most operations that ask for an app are not slowed down by the spreadsheet. They are slowed down by the copy of it.
One person keeps the master. Three people keep working copies. A supervisor emails a version to a client, and from that moment there are two truths and nobody can say which is current. Building an application does not fix that on its own. Deciding which record is the single one, and who is allowed to change it, is what fixes it. The software just makes the decision enforceable.
So the first thing we do is name the record. A work order, an inspection, an obligation, a document. One object, one owner, one set of states it can move through. Almost every failed operations build we have seen started with screens instead of that.
Then we write down its states and who may move it into each one. For a work order that is raised, assigned, in progress, waiting, done and verified. The waiting state, with a reason that has to be given, is the one most systems leave out. Without it, a job waiting three weeks for a client decision looks identical to a job nobody started, and every overdue report is wrong.
Inside a build
| Layer | What we build | What decides the size |
|---|---|---|
| The record | The core object, its fields, its states and the rules for moving between them. | How many object types the process really has |
| Capture | The screens the person on site actually uses, designed for one hand and poor signal where that is the reality. | Number of distinct roles capturing data |
| Workflow | Assignment, due dates, escalation and approval, with the state changes logged. Each approval names a role, a person holds it, and the log records who approved and when. | How many approvals the process carries |
| Output | Reports, exports and the client-facing document the work is ultimately for. | Whether the output format is fixed or negotiable |
| Access | Who can see and change what, including client users where they need a view. | Whether external users are in scope |
| Integration | Connections to the systems the data has to reach, specified in writing first. | The quality of the other system's interface |
Yours at handover
Four of these are documents. That is deliberate: software without them is a dependency.
The source code
In your repository, with the commit history intact. Not a compiled artifact and not a licence to use our copy.
The data model document
Every object, every field, every state and every relationship, written out. This is what a future platform migration is built from.
A working export
Full data out in an open format, tested as part of the first release rather than written the week you ask to leave.
The operations manual
How to add a user, change a checklist, fix the common mistakes. Written for your administrator, in their language of the job.
Admin training
A working session with the people who will run it, recorded so the next administrator can watch it.
How the increments get cut
The point of an increment is that it can be wrong cheaply. Each one is something a real person can do a real task with.
- 01
One record, all the way through
Create it, fill it, submit it, approve it, see it in a list. Ugly, narrow, and enough to prove the model is right.
- 02
The hard capture case
Whatever is genuinely difficult about your data entry gets built second, not last. Photographs, offline, bulk, awkward units.
- 03
The output the work exists for
The report or export a client or an auditor sees. Built early, because it usually changes what the record needs to hold.
- 04
Everything around the edge
Admin, permissions, bulk actions, the second and third role. This is the longest stretch and the least interesting.
A contractor's shared work order sheet
A maintenance contractor with its office in Khobar runs three client contracts from one shared spreadsheet of work orders, and each client receives a filtered copy by email every week.
The systems audit finds four live copies and two different meanings of "closed". The specification names one record, the work order, with six states from raised to verified, and one output, a weekly client view.
Increment one lets a supervisor raise, assign and close a work order in the browser. Increment two adds the closing photograph, taken on a phone with no signal. Increment three replaces the emailed copy with a client login that shows only that client's sites.
The pilot runs two weeks on one contract. The cutover record sets the spreadsheet to read-only on a named date. The contractor holds the repository, the data model document, a tested export, a two-page operations manual and a recording of the admin training.
The shapes a build usually takes
Work that happens on site and reports from an office
Inspections, maintenance, deliveries, handovers. The hard constraint is the person in the field, not the manager in the dashboard, and the build succeeds or fails on whether capture takes under a minute.
- Offline tolerant capture with a sync queue you can see
- Photographs attached to the record at the point of work, with the timestamp the device recorded
- Supervisor review before anything reaches a client
Giving your customer the view instead of the email
Usually cheaper than it sounds, because the data already exists inside your operation. The work is deciding what a client should see, and building the wall that keeps them from seeing anything else.
- Per-client access with no shared logins
- A view built from the same records your team uses, so there is nothing to reconcile
- Downloads that carry your document numbering, not ours
Vendors upload against your records instead of emailing
Your suppliers and subcontractors upload their certificates, insurance and job evidence against the record it belongs to. Each upload carries an expiry date and lands in a review queue, so an expired insurance certificate surfaces before the vendor is back on site.
- One login per vendor, seeing only their own uploads
- An expiry date on every document, with a reminder before it lapses
- A named reviewer accepts or returns each upload
An inherited system nobody can change
The riskiest of the four and the most common. The old system usually holds years of records and a handful of undocumented rules that somebody depends on, and finding those rules is most of the work.
- Data extracted and profiled before anything is designed
- The undocumented rules written down and confirmed with the people who rely on them
- Both systems run in parallel until the cutover record is signed
Fair questions about a custom build
Should we buy something off the shelf instead?
Often, yes, and we will say so. If a product covers eighty per cent of what you need and your process can bend to the rest, buying it is cheaper than anything we can build. We will name the product. Where a build genuinely wins is when the process is your actual differentiator, when the products in the category all assume a workflow you do not run, or when the licence cost per user stops making sense at your headcount.
How long before we see something real?
One week to map the workflow and write the specification. Two to five weeks to the first increment you can use on real work. A pilot with one team after that, usually two weeks, before anybody else touches it. If a supplier promises a finished system in that window, they are describing a demo.
Who owns the code?
You do, and it sits in your repository from the first commit rather than being transferred at the end.
What drives the cost?
The number of distinct record types, the number of roles that touch them, how many approvals the workflow carries, whether external users are in scope, and the state of any system we have to integrate with. A single-record internal tool with two roles is the cheap end. We quote after the systems audit.
Does it work in Arabic?
Yes, and right-to-left is designed in rather than retrofitted. Say so at specification, because bilingual interfaces change some layout decisions and almost no data decisions. Retrofitting Arabic into a finished English interface is the expensive order to do it in.
What happens if we outgrow it?
That is the intended ending. The data model is documented and the export is tested, so the next platform inherits clean records instead of a reverse-engineering project. Building something you will replace in five years is a normal, sensible outcome, and it is a better outcome than a platform you cannot leave.
Often the same project
Mobile apps for field work
Job cards, deliveries and readings captured on a phone with no signal.
Read moreDigitalAudit and inspection apps
The capture side, specified as its own thing because the constraints are unusual.
Read moreDigitalDashboards and reporting
What the records are for once they exist.
Read moreDigitalSystems integration
Connecting the build to the systems already holding your data.
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.
Start with the map, not the mockup
Bring the spreadsheet everybody argues about. The first hour usually goes on deciding which copy is the real one, and that is a conversation worth having whoever ends up building it.