Industries
Sectors do not change how we build. They change what has to be proved.
The engineering method is the same everywhere. What differs is the condition the system has to hold up under, and that condition is usually the thing a generic proposal misses.
By constraint
Eight sectors, and what each one actually imposes.
Named as operating conditions rather than markets. If yours is not listed, the useful question on a call is which of these constraints it shares.
Logistics & transport
The constraint
The physical world does not wait for the system. A container moves before the paperwork clears, a scanner loses signal inside a warehouse, and the same event arrives twice from two devices.
What it changes
Ingestion has to be idempotent and tolerant of events arriving late or out of order. Capture works offline and reconciles afterwards. Reconciliation is a designed feature rather than a report someone runs when the numbers disagree.
Manufacturing
The constraint
The line does not stop for a deployment, and the equipment is usually older than the software being asked to read it. Operational technology and information technology are separate worlds for good reasons.
What it changes
Systems read from plant equipment without being trusted to write back to it. Release windows are planned around production rather than sprint boundaries, and every integration has a defined behaviour for when the source goes quiet.
Healthcare
The constraint
The data is personal at the highest sensitivity, and the cost of getting access control wrong is not financial. Who may see which record, and the proof of who did, is the architecture rather than a layer on top of it.
What it changes
Access decisions are made per record and logged as they happen. Data collection is minimised at the point of design, retention is an explicit decision with an owner, and any export path is treated as carefully as the interface.
Financial services
The constraint
Every movement of value has to be explainable long after it happened, to someone who was not there. Reconciliation and audit are not reporting concerns; they are the product.
What it changes
Append-only records, processing that is exactly once where it claims to be, and a replayable trail that reconstructs a balance at a past moment. This is also the sector where a distributed ledger most often earns its cost rather than merely sounding modern.
Professional services
The constraint
The thing being sold is people and their time, and the firm may act for parties with opposing interests. Confidentiality runs between engagements inside one organisation, not only outward.
What it changes
Separation is enforced by the data model rather than by convention, so one matter cannot be read from another by default. Time, billing and document retention are designed around the engagement as the unit, and access is revocable per person per matter.
Retail & e-commerce
The constraint
Demand is spiky by nature and the money moves in real time. Stock is a contended resource that several customers reach for in the same second, and tax treatment changes by market.
What it changes
Checkout is idempotent so a retried payment does not become a second order. Inventory is reserved rather than merely decremented. Tax and invoicing integrate against the rules of the market being sold into rather than the platform default.
Real estate & property
The constraint
The records outlive the software by a long way. Ownership, title and contractual documents have to remain readable and provable far past the lifetime of whatever system created them.
What it changes
Document provenance and long retention are designed in from the start, in formats that survive a vendor. Where fractional ownership or tokenised interests are involved, the legal position is settled before the technical one, never the other way round.
Education & non-profit
The constraint
Load is seasonal and extreme — enrolment and results periods concentrate a year of traffic into days — while the budget is fixed and usually scrutinised.
What it changes
Architecture is chosen for cost at the trough as well as capacity at the peak, which usually rules out sizing everything for the worst day. Records persist for many years, so schema changes are planned as migrations rather than rewrites.
Regulatory context
What shapes systems in this region.
These are real instruments with real architectural consequences. They are listed because they change design decisions, not to decorate a page.
PDPL
Saudi Arabia's personal data protection law. It affects lawful basis for processing, the rights a person can exercise over their own record, expectations around where data is held, and what has to happen after a breach. Any system holding personal data is in scope of the question.
SAMA frameworks
The Saudi Central Bank publishes cybersecurity and business continuity expectations for the financial entities it regulates. Where they apply, they shape resilience targets, incident response and the evidence a system has to be able to produce.
NCA Essential Cybersecurity Controls
The National Cybersecurity Authority controls, which reach government bodies, critical national infrastructure and in places the suppliers serving them. They bear on identity, segmentation, logging and how an environment is hardened.
ZATCA e-invoicing
The tax authority requirement covering electronic invoice generation and, in its later phase, integration with the authority itself. It affects any invoicing path in a business registered for value-added tax, and it is a systems change rather than a finance one.
Whether any of these applies to your organisation is a legal determination, not an engineering one. We build to the requirements your counsel or compliance function confirms, and we will tell you when a design decision has a compliance consequence worth checking before it is made.
What does not change
The method is the same in all of them.
Sector knowledge tells you what the system has to survive. It does not replace the way the system gets built.
The constraint is named first
Before architecture, the condition the system has to hold under is written down in plain language. Most failed designs are answers to a constraint nobody stated.
Decisions carry their reasoning
The recommendation, its cost, its risk and the dissenting view. In a regulated sector this is also the artefact an auditor asks for, so it is written once and serves both purposes.
It is operated, not handed over
A system that meets its constraint on launch day and is never watched against it again stops meeting it quietly. Running the thing is what keeps the constraint true.
Which of these is yours?
Describe the condition your system has to hold up under. If the honest answer is that the constraint you are describing is not one we have a good approach to, you will hear that.