Sector depth is knowing where it goes wrong

What breaks here

• A retry that quietly takes payment twice because the endpoint was never idempotent
• Ledgers that disagree, discovered at month end rather than at the moment they diverged
• Fraud rules nobody can change safely because nobody can explain what they currently do
• An audit trail assembled after the fact from logs that were never designed to be evidence

How we approach it

1. Idempotency and immutability firstEvery money-moving endpoint takes an idempotency key, and the ledger is append-only. Corrections are new entries, never edits, so history is reconstructable at any past moment.
2. Reconciliation as a first-class featureAutomated matching between your system, the processor and the bank, running continuously with alerts on drift, rather than a spreadsheet somebody owns.
3. Explainable decisioningFraud and risk logic that can be read, versioned and shadow-tested against live traffic before it starts declining real customers.

Compliance and security

• PCI-DSS aware
• SCA and 3-D Secure
• Open Banking and PSD2
• SOC 2 aligned controls

• Card data kept out of your systems entirely where a tokenising processor can hold it
• Segregated environments with no production data in development, ever
• Immutable audit log of every state change, with the actor and the reason
• Key management in a managed vault, rotated, with no secret in a repository

What breaks here

• Access control bolted on at the interface while the API underneath answers to anyone
• Consent captured once and never modelled, so withdrawal cannot actually be honoured
• Integrations that move whole records when the receiving system needed three fields
• Test environments seeded with real patient data because anonymising it was hard

How we approach it

1. Permissions in the data model, not the UIRow and column level access enforced at the source, so a new client, report or AI feature cannot accidentally route around it.
2. Consent as a modelled entityPurpose, scope, expiry and withdrawal represented explicitly, so honouring a withdrawal is a query rather than an investigation.
3. Interoperability without oversharingFHIR and HL7 where they fit, with the minimum necessary fields rather than whole-record transfers by default.

Compliance and security

• HIPAA aware
• GDPR and UK GDPR
• FHIR and HL7 v2
• NHS DSP Toolkit aligned

• Encryption in transit and at rest, with keys you control
• Synthetic or de-identified data in every non-production environment
• Access reviews and least privilege by default, granted per role rather than per person
• Breach and incident runbooks written before launch, not after an incident

What breaks here

• Overselling, because inventory was eventually consistent and the checkout was not
• Peak traffic that takes down search or checkout rather than degrading gracefully
• A catalogue that means one thing in the ERP and another on the storefront
• Personalisation that recommends the thing the customer bought last week

How we approach it

1. One source of truth for stockReservations at the point of intent with explicit expiry, so the item in a basket is genuinely held and the number shown is the number available.
2. Degrade, do not fall overLoad-tested against your actual peak profile, with caching, queues and read replicas so the worst case is a slower page rather than an outage.
3. Recommendations that respect contextGrounded in real behaviour and current stock, with rules for what should never be suggested, because a confident irrelevant recommendation costs trust.

Compliance and security

• PCI-DSS aware for payment paths
• GDPR and ePrivacy for tracking
• Accessibility to WCAG 2.2 AA
• Consent-gated analytics

• Payment handled by a tokenising processor so card data never touches your estate
• Marketing tags loaded only after consent, and auditable
• Rate limiting and bot mitigation on checkout and search
• Peak readiness rehearsed before the season, not discovered during it

What breaks here

• Telemetry arriving late, out of order or twice, and being treated as if it did not
• Exceptions handled by whichever operator happens to notice them
• Route optimisation that ignores the constraints drivers actually work under
• Integrations with partners whose data quality you cannot control and did not plan for

How we approach it

1. Event ingestion built for the real worldOrdering, deduplication and late-arrival handling assumed from the start, because a device on a lorry is not a reliable network client.
2. Exceptions as a designed workflowEvery failure mode has an owner, a queue and an escalation path, so the unusual case is handled by the system rather than by whoever is watching.
3. Optimisation with the constraints in itDriver hours, vehicle types, access restrictions and customer windows modelled explicitly, so the plan survives contact with the depot.

Compliance and security

• GDPR for driver and customer data
• Customs and EDI message formats
• ISO 27001 aligned controls
• Working time and telematics obligations

• Partner integrations validated at the boundary, with bad data quarantined rather than absorbed
• Location and driver data minimised and retained only as long as there is a reason
• Offline-tolerant mobile capture, so a lost signal is not lost work
• Replayable event streams, so a bad day can be reconstructed exactly

What breaks here

• Multi-tenancy added later, so isolation is enforced by remembering to add a WHERE clause
• Billing that cannot express the plan sales just sold
• Permissions that were three roles and are now forty special cases
• No usable telemetry, so incidents are diagnosed by guesswork and customer complaints

How we approach it

1. Tenancy decided once, properlyIsolation enforced at the database rather than in application code, so a missed filter is impossible rather than unlikely.
2. Billing that matches how you actually sellPlans, entitlements, usage and proration modelled as data, so a new package is a configuration change rather than a release.
3. Observability from the first deployTraces, structured logs and the handful of alerts that mean something, in place before you need them at three in the morning.

Compliance and security

• SOC 2 readiness
• GDPR as a default posture
• Data residency options where customers require them
• Subprocessor transparency

• Audit logging on the actions your future enterprise buyer will ask about
• Single sign-on and role-based access designed in, not sold as a later tier you cannot build
• Environment separation and least-privilege credentials from day one
• A security questionnaire you can answer honestly without a scramble

What breaks here

• A checkout that loses baskets on a network blip and never tells anyone
• Search that returns nothing useful for the terms customers actually type
• Marketplace payouts and commissions reconciled by hand at month end
• A replatform that quietly drops the SEO the old site had earned

How we approach it

1. Protect the revenue path firstBasket, checkout and payment are instrumented, load tested and given the strictest error budget on the estate, because that is where a fault is measured in orders rather than tickets.
2. Search built from real queriesTuned against your actual search logs and synonyms rather than defaults, with a measurable relevance baseline so a change can be shown to help.
3. Migrate without losing rankingsRedirect maps, structured data and canonical URLs planned before launch, so a replatform does not cost you the traffic you already had.

Compliance and security

• PCI-DSS aware for payment paths
• GDPR and ePrivacy for tracking
• WCAG 2.2 AA on the buying journey
• Strong Customer Authentication

• Card data handled by a tokenising processor, never stored by you
• Marketing and analytics tags gated behind consent
• Bot and fraud mitigation on checkout, login and gift cards
• Payout and commission logic reconciled automatically with an audit trail

What breaks here

• Age and consent handled as a checkbox rather than modelled properly
• Content that fails a screen reader, discovered during a procurement review
• Institutional rollouts blocked because there is no working single sign-on
• Learner data retained indefinitely because nobody defined when it should go

How we approach it

1. Safeguarding in the data modelAge bands, guardian consent and staff oversight represented explicitly, so what a given account can see and do is enforced by the system rather than by policy.
2. Accessibility as an acceptance criterionKeyboard paths, contrast, captions and screen reader behaviour tested as part of definition of done, because retrofitting them means rebuilding the screens.
3. Built for institutional buyingSSO, rostering, bulk provisioning and the reporting a school or university will ask for, present before the procurement conversation rather than promised during it.

Compliance and security

• GDPR and age-appropriate design
• COPPA aware
• WCAG 2.2 AA
• SSO via SAML and OIDC, LTI where required

• Data minimisation on learners, with retention periods defined and enforced
• Staff access scoped to their own cohort rather than the whole estate
• Moderation and reporting routes on anything user-generated
• Content and assessment data exportable, so an institution is never locked in

What breaks here

• Portal feeds that silently change format and take listings offline
• Duplicate properties from three sources that nobody can reliably merge
• Document and signature workflows that lose track of what stage a deal is at
• Compliance checks performed once and never revisited as a deal drags on

How we approach it

1. Ingestion that expects bad feedsValidated at the boundary, with schema drift detected and quarantined rather than absorbed, so one partner cannot take your listings down.
2. One property, however many sourcesDeterministic matching and a clear rule for which source wins per field, so a merged record is explainable rather than mysterious.
3. Transactions as a modelled workflowEvery stage, document, party and deadline represented explicitly, so the state of a deal is a query rather than a phone call.

Compliance and security

• KYC and AML aware
• GDPR for applicant and tenant data
• Accessibility to WCAG 2.2 AA
• E-signature and document retention rules

• Identity documents handled by a specialist provider rather than stored by you
• Full audit trail on every document, approval and status change
• Retention schedules for applicant data that did not convert
• Access separated between agents, landlords and back office by default