Illustrative scenarios
What the work looks like, without inventing results
These are not case studies: client work appears on this site only with the client's consent and real figures. Each scenario describes a problem we are built to solve, how we would approach it, and exactly what we would measure.
From a spreadsheet estate to one operations platform
The situation
A services business coordinates work across eleven spreadsheets and a shared mailbox. Everyone knows which file is authoritative, except when they do not.
Why it is hard
Work is assigned in one file, progress is tracked in another, and invoicing reads a third. Reconciliation before each management meeting takes most of a day, and two people hold the knowledge of how the files relate.
How we would approach it
- 01Map the real process — including the exceptions people handle informally — and write it down as an explicit domain model
- 02Build one application that owns intake, assignment, status and billing records, with a permission model matching the actual organisation
- 03Migrate historical data with mapping rules, a dry run and a parallel-running period before cut-over
- 04Replace the manual management pack with reporting generated from the system itself
What we would measure
- Time spent on pre-meeting reconciliation, measured before and after
- Number of systems a single job record touches
- Count of processes that depend on one named person being available
Turning one customer's application into a product
The situation
An application built for a single customer has attracted three more. Each new customer currently requires manual database work to onboard.
Why it is hard
Tenant separation depends on developers remembering to filter every query. There is no metering, so billing is reconciled by hand, and one customer's data volume degrades performance for the others.
How we would approach it
- 01Assess every place tenant identity must reach: data model, query paths, caches, background jobs, file storage, exports and audit trail
- 02Choose an isolation model against the customers' actual requirements and enforce it at the data-access layer rather than by convention
- 03Add provisioning so a tenant can be created without engineering involvement, then metering at the source of each billable event
- 04Introduce feature flags and staged rollout so a release cannot affect every tenant simultaneously
What we would measure
- Engineering time required to onboard one new tenant
- Whether a cross-tenant query can be written without the platform rejecting it
- Billing reconciliation differences between metered usage and invoices
Field work that continues when the network stops
The situation
Field technicians complete jobs in basements, plant rooms and rural sites. The existing mobile web form loses entered work whenever the connection drops.
Why it is hard
Technicians have learned to photograph their own paperwork as a backup, then re-enter it later. The office has no reliable view of same-day completion, and disputes cannot be settled from the record.
How we would approach it
- 01Design the data layer first: what is cached, what queues as intent, and how conflicts resolve when the same job changes in two places
- 02Build a mobile application with local persistence, an outbound operation queue and sync state the technician can actually see
- 03Capture evidence — photographs and signatures — locally, uploading with retry and deduplication when connectivity returns
- 04Give the office an exception-first view showing what has not yet synced, rather than implying everything is current
What we would measure
- Proportion of jobs completed without data loss on unreliable connections
- Duplicate or missing job records per week
- Time between job completion in the field and visibility in the office
A whole site section stops appearing in search
The situation
After a platform upgrade, an entire product category disappears from search results. Rankings for individual pages were never manually changed.
Why it is hard
Search Console reports 'crawled — currently not indexed' across the section. Opinions about the cause are plentiful and evidence is absent, so proposed fixes are guesses.
How we would approach it
- 01Crawl the section as a search engine would, comparing the rendered output with the initial HTML response
- 02Read Search Console coverage and, where available, server logs to establish what is actually being requested and returned
- 03Identify the mechanism — a canonical pointing elsewhere, content arriving only after client-side rendering, or a directive applied too broadly
- 04Fix it in the codebase, then verify recovery through re-crawl and index coverage rather than declaring success at deployment
What we would measure
- Indexed URL count for the affected section
- Share of primary content present in the initial HTML response
- Impressions for the section's queries, tracked from the pre-incident baseline
When AI assistants describe the company incorrectly
The situation
A prospective customer quotes an AI assistant's description of the company back to the sales team. Two of its three claims are wrong.
Why it is hard
The assistant has assembled a description from a stale directory listing and a competitor comparison page. The company's own site never states plainly what it does, for whom, or where it operates.
How we would approach it
- 01Record a verbatim baseline: ask the major assistants a fixed set of questions and capture exactly what they currently say
- 02Agree one canonical description, service taxonomy and terminology, then reconcile every place those appear on the site and on third-party profiles
- 03Publish machine-readable organisation and service data that matches the visible page, with same-as links to authoritative profiles
- 04Repeat the prompt set on a schedule and report changes in mention and accuracy without claiming causation the data cannot support
What we would measure
- Accuracy of assistant descriptions against the canonical facts, scored on a fixed prompt set
- Consistency of company description across owned and third-party properties
- Which sources the assistants cite when describing the company
Document extraction that knows when to ask a human
The situation
A team re-keys several hundred supplier invoices a month from PDF into an accounting system. Accuracy matters more than speed.
Why it is hard
An earlier AI pilot extracted fields impressively in a demonstration, but nobody could say how often it was wrong, what a wrong value would cost, or how an error would be caught before payment.
How we would approach it
- 01Build an evaluation set from real documents with verified expected values, including the awkward ones, before choosing any model
- 02Implement extraction with structured output validation and a confidence score per field rather than per document
- 03Route anything below the confidence threshold to a reviewer, with the source region highlighted for fast verification
- 04Measure cost and latency per document at real volume, and grow the evaluation set from every production failure
What we would measure
- Field-level accuracy on a held-out evaluation set
- Proportion of documents requiring human review, and review time per document
- Cost per document processed at current volume
Infrastructure that exists only in a console
The situation
A production estate was built by hand over three years. Cloud spend has doubled, and no one can describe what would happen if the account were lost.
Why it is hard
Environments differ in undocumented ways, deployments require one specific engineer, and backups exist but have never been restored. Every change carries risk nobody can quantify.
How we would approach it
- 01Inventory what exists — resources, permissions, spend, dependencies and the current recovery position
- 02Bring resources under infrastructure code incrementally, lowest-risk environment first, with rollback at each step
- 03Set recovery objectives per system, implement matching backups, then rehearse a full restore and fix what the rehearsal exposes
- 04Measure before right-sizing, so cost reduction is evidenced rather than asserted
What we would measure
- Proportion of production resources managed as code
- Whether a documented restore has been executed successfully, and how long it took
- Cloud spend per environment against workload
A condition-monitoring pilot that reaches a decision
The situation
A manufacturer wants to know whether sensor-based monitoring would predict failures on a line, before committing to a plant-wide programme.
Why it is hard
An earlier pilot ran for months without success criteria and ended without a decision. Operational-technology segmentation also has to be preserved, which rules out several vendor proposals.
How we would approach it
- 01State a hypothesis, the success criteria that would confirm or reject it, a time box and a cost ceiling before any hardware is ordered
- 02Instrument a small number of machines using read-only collection at the edge, with one-way data flow into the business network
- 03Compare detected anomalies against actual maintenance events over the pilot window rather than against a vendor benchmark
- 04Report findings with the cost to productionise and the risks that remain — including the case for not proceeding
What we would measure
- Anomalies detected that corresponded to real faults, and those that did not
- Whether segmentation and safety boundaries remained intact throughout
- Cost per monitored machine, projected to plant scale
Recognise your situation in one of these?
If any of these scenarios reads like your organisation, the conversation starts from a shared understanding of the problem — which is most of the value of a first call.
Prefer email? hello@kornspire.com