Choosing software that actually fits your sector is a decision about constraints, not features. This article walks through how industry-specific development differs from generic development with an industry skin, where vertical solutions win and where they lose, how to test a team’s sector expertise before you commit, and how to structure the first release so the riskiest unknowns surface early.
The demo went fine. Every screen rendered, every click worked, the stakeholder nodded along. Six weeks later the same application was choking on a claim that arrived twice, a payment that settled for the wrong amount, and a regulator who wanted to know exactly who approved the reversal. Nothing in the demo covered any of it, because nothing in the demo was the actual business.
That gap is what separates industry-specific software development from generic development with an industry skin. The skin is the easy part.
Reading time: 12 min
Key points
- Industry-specific development designs around a sector’s constraints first; features come last.
- Domain knowledge is visible in the first-pass data model, long before any interface exists.
- Exceptions, not the happy path, define most of the code and most of the risk in industry software.
- Build versus buy hinges on how often your domain rules change and whether changing them faster than competitors matters.
Table of contents
Industry-specific software development starts with constraints, not features
Industry-specific software development means designing around the constraints that shape a sector’s workflows, data, and risk, then turning those constraints into architecture and delivery decisions. The features come last. In insurance, the constraint is that a policy can be amended after a loss event and the audit trail has to survive it. In healthcare, the constraint is that a clinical order can be retracted after administration has started. In logistics, the constraint is that a shipment can be partially fulfilled across three carriers with different reconciliation cycles.
None of that appears in a requirements document written by someone who has not sat with the operators. The constraint types repeat across sectors: regulatory obligations, safety expectations, auditability requirements, domain data models, and integration realities. Each one dictates an architecture decision before a single screen is drawn. Teams that skip this step build applications that look functional in early demos and collapse under production edge cases, usually in front of the customer who paid for the demo.
Where vertical solutions beat generic platforms
Vertical solutions win when the domain contains repeatable workflows and a shared vocabulary, and when the product derives its value from pre-built domain logic rather than a configurable interface. Claims processing is the same shape at every insurer. Clinical orders follow the same lifecycle at every hospital group. Settlement and reconciliation follow the same rhythm at every payments company. A team that has built that state machine before is not guessing, they are configuring.
The contrast with horizontal capabilities is sharp. Authentication, billing, notifications, and file storage are solved problems. Buy those. Claims adjudication, clinical order management, and reconciliation workflows are domain primitives. Build or buy those vertically, because a generic platform has to express them as configuration and configuration has limits.
The counter-case matters. If your workflows vary widely between clients, or between regions of the same client, a highly configurable platform may be safer than hardcoding industry assumptions that only fit one operator. We have seen both. The mistake is choosing the rigid vertical build for a business that is genuinely heterogeneous.
Domain knowledge shows up in the data model first
Domain knowledge becomes visible in the first-pass data model, long before any interface exists. When entities, relationships, lifecycle states, and invariants match the operational reality of the business, the team has absorbed the domain. When they do not, no amount of polished UI will save the project.
Here is a test we use and recommend. Before reviewing any mockups, ask the team for their top ten entities and the state machine for each. A team that knows freight will model a shipment that can exist without a carrier, a carrier that can exist without an account, and a proof-of-delivery that attaches to a leg rather than the whole move. A team that does not will model an order table with a status column and call it done.
The failure mode this test prevents is expensive. Late-stage schema rewrites break existing integrations, corrupt historical reporting, and consume a quarter that was budgeted for new features. A schema discovered in month eight is not a refactor. It is a restart with a deadline.
The hidden workload is exceptions, not the happy path
Industry software is defined by its exceptions. Reversals, disputes, partial fulfillment, supervisor overrides, manual review queues. The happy path is maybe twenty percent of the code. The other eighty percent is what keeps the system honest when reality disagrees with the process diagram.
Exception handling is where workflow automation either earns its keep or falls apart. A reversal that does not propagate to the general ledger creates a reconciliation gap someone finds at month-end close. An override that is not logged creates an audit finding. A partial fulfillment that is modeled as a full fulfillment with a note field creates a data model nobody can query six months later.
Plan for the week a senior engineer leaves mid-migration and the exception logic lives only in their head. That is the real risk profile of industry work. The counter-case is narrow: internal tools with a single operator and low volume can tolerate manual patches for rare exceptions. Once two systems of record exist, they cannot. Manual patches become silent data drift.
Sector expertise is a delivery capability, not a slide deck
Sector expertise means an engineering team makes correct tradeoffs under domain pressure, even when the requirements are incomplete or contradictory, which they usually are. A slide deck can claim anything. Delivery capability shows up in observable behavior, and you can look for it directly.
Watch for clarifying questions during discovery. A team with real expertise asks what happens when the same invoice arrives twice, who can approve an amount above threshold, and what the system must prove after an incident. Boundary definitions come next: which rules are enforced in code, which are advisory, and which belong to the external system. A maintained risk register and a decision log that ties each domain rule to the code module implementing it are the strongest signals of all.
The failure mode is quieter than a missed deadline. A team ships features rapidly while accumulating domain debt, undocumented rules patched into controllers, edge cases handled by hand in production. Eighteen months later that debt blocks scalability and makes operational auditing impossible. The demo was good. The codebase is a liability.
What to demand in discovery for industry-specific builds
A robust discovery phase produces artifacts, not conversations. Four of them matter most: a domain map naming the core entities and who owns them, event flows showing what triggers what across systems, an integration inventory, and a prioritized risk list. These reduce ambiguity in a way that meeting notes never do, and they align with the lifecycle process discipline described in the IEEE/ISO/IEC 12207 standard for software lifecycle processes.
The right ending for discovery is a buildable backlog for the first thin slice, not a big design upfront document. Exhaustive upfront design in a domain you do not yet understand produces confident fiction.
The failure mode this prevents is the most common one in our industry: development starts with ambiguous requirements, the team builds the wrong workflow entirely, and nobody notices until user acceptance testing, when the actual operators see it for the first time.
Domain workshop outputs that engineering can actually use
Workshops are only worth the calendar space if their output translates directly into acceptance criteria, edge cases, and testable domain rules. Two artifacts make that translation reliable. A context map showing which team or system owns which concept, and a data classification document stating what is personal, what is financial, and what is operationally critical.
Workshops that yield only high-level journey maps fail to guide engineering. A journey map tells you the customer feels frustration at step four. It does not tell you whether a refund can be issued after settlement, or which system is the source of truth for the customer address. Demand the artifacts an engineer can write a test against.
Integrations are where generic teams lose weeks
In many sectors the product is the integration layer. Payments, claims, customs, clinical records, warehouse management. Industry-specific development treats external systems as first-class design inputs, with the same rigor applied to them as to your own schema.
Build an integration inventory early. For each external system, record who owns it, what the service level agreement is, what the rate limits are, and what happens when it fails. Does the ERP return a 500 and expect a retry, or does it silently accept and reconcile later? Does the payment rail reject duplicates or create them? Teams that cannot answer those questions build brittle point-to-point integrations that fail silently and create data drift between systems, the kind that surfaces months later as a reconciliation gap nobody can explain.
If your product spans hardware and software boundaries, map those contracts even earlier. Our system and embedded engineering work has taught us that a firmware interface discovered late costs more than any API change, because the deployment cycle is measured in devices in the field, not in releases.
Compliance becomes architecture when auditability is real
When auditability genuinely matters, it stops being a feature and becomes an architecture constraint. Traceability, least privilege, and reproducible decisions have to be designed in. Adding secure storage afterward gives you encrypted records you cannot explain.
Define exactly what must be provable after an incident. Who did what, when, and with which inputs. That single sentence drives your design: an append-only event log for actions, immutable input snapshots for decisions, and role scoping narrow enough that “who” is answerable. The NIST Secure Software Development Framework is a workable baseline for building traceable architecture, and it maps cleanly onto these requirements.
The counter-case is legitimate. Early prototypes can defer full security controls if the boundary is explicit and the data is strictly synthetic. Write that boundary down. The prototype that quietly starts using production data is the one that ends up in the incident report.
Where teams underestimate onboarding and domain transfer
The biggest risk in industry projects is not coding speed. It is the speed of domain transfer across roles and over time. Code can be written by anyone. The rules in a domain expert’s head can only be extracted, and the extraction is slow.
Technical onboarding for a new engineer on an industry project needs three things beyond repository access: a domain glossary that defines terms precisely, sample cases that show real transactions including the ugly ones, and shadowing sessions with subject matter experts where the engineer watches exceptions get handled. A new hire who has read the glossary and worked through twelve real dispute cases is productive in weeks. One who has only read the code is productive never, because the code does not say why.
The failure mode is knowledge silos. One domain expert holds the reconciliation rules, one engineer holds the exception logic, and when either leaves, delivery continuity breaks. We treat domain transfer as an engineering deliverable with the same standing as a test suite.
Vertical solutions need product thinking even in custom builds
Even a fully custom build needs product discipline. Someone has to define the user, the job-to-be-done, and the measurable outcome inside the specific domain. Custom does not exempt you from product thinking. It usually demands more of it, because there is no vendor roadmap to hide behind.
The practical form of that discipline is a thin slice. One workflow that crosses UI, domain logic, and at least one integration, shipped behind feature flags. The slice proves the data model, the integration contract, and the exception handling at the same time. A big platform built in a vacuum, reviewed at month nine, is the failure mode this prevents. Nobody in the field wanted it, and now it is too late to ask.
Vertical solutions succeed when the product decisions are made by people who understand the domain vocabulary. A backlog item that reads “support partial refund” is not a specification. A backlog item that reads “support partial refund after settlement with clawback through the acquirer” is.
Thin-slice planning that survives real data
Start the thin slice with a workflow that touches the core domain primitive and produces a verifiable record. Not a dashboard. Not a settings page. The workflow that the business would run on day one if the rest of the system did not exist.
Validate the slice with test fixtures built from real-like edge cases: the duplicate submission, the amount mismatch, the mid-flight cancellation. Slices tested only with clean synthetic data hide structural flaws, because clean data never exercises the state machine. The first messy fixture is where you find out whether your domain model is right.
Build versus buy decisions hinge on domain volatility
Build when your domain rules are a differentiator or change frequently. Buy when the workflows are stable and mature products exist. Most of the agonizing in build-versus-buy debates dissolves once you ask one question: how often do these rules change, and does changing them faster than competitors matter?
Before deciding, evaluate the candidate product against a written list of non-negotiable domain rules. Check configurability limits, integration surfaces, data ownership, and roadmap dependence. The verdict is usually clear once the list exists.
When domain rules form your competitive edge, buying a generic platform often shifts the pain instead of removing it. The pain moves into endless customization, plugin workarounds, and processes that bend to fit the tool. Here is how the decision tends to land in practice.
| Dimension | Build | Buy generic platform | Buy vertical product |
|---|---|---|---|
| Fit for volatile domain rules | High, you control the model | Low, configuration has limits | Medium, depends on roadmap alignment |
| Time to first release | Slower, months | Fastest, weeks | Fast, weeks to a few months |
| Integration flexibility | Full control of contracts | Constrained by vendor APIs | Pre-built for sector systems |
| Data ownership | Complete | Often shared or vendor-held | Usually yours, verify contractually |
| Roadmap dependence | Not applicable | High | Medium |
Vertical solutions versus horizontal platforms in the long run
Horizontal platforms reduce time-to-start. Vertical solutions reduce time-to-correct once you hit real-world edge cases. Both numbers are real, and they pull in opposite directions, which is why so many teams choose wrong.
The first quarter flatters the horizontal platform. Everything is configuration, screens appear fast, and the demo impresses. The correction arrives when the edge cases do. Each exception becomes a customization, each customization becomes a workaround, and the workaround layer grows until nobody can upgrade the platform underneath it.
Measure two signals to know which world you are in: manual review queue volume and exception rate. If operators are routing a growing share of transactions into a manual queue because the system cannot handle them, the platform is misfit for your domain. If exceptions are frequent and costly, building vertical logic is a stronger foundation than configuring a horizontal tool endlessly. If exceptions are rare and stable, stop reading this section and buy the platform.
In-house hiring stalls when domain and delivery both need seniors
Hiring internally stalls when you need senior engineers capable of both shipping code and absorbing domain complexity without heavy supervision. Those two requirements overlap in a small population, that population is expensive, and they are rarely looking.
The stall has a specific shape. Two senior hires arrive, and their first months go to reverse-engineering domain rules from old tickets, stale Confluence pages, and the memory of one veteran operator who answers messages on Tuesdays. That is not delivery. That is archaeology, and it can consume an entire quarter before the first feature ships.
In-house development is strongest when stable leadership bandwidth and a mature domain model already exist. If both are true, hire. If either is missing, adding permanent headcount multiplies the problem, because every new hire needs the same slow domain transfer and the people who could provide it are already overloaded. The verdict is not anti-in-house. It is sequencing.
Staff augmentation breaks down when ownership is fragmented
Staff augmentation works for narrow skill gaps. You need a Kubernetes specialist for two months, or a second Golang engineer to clear a backlog. It fails when the domain requires cohesive ownership across design, implementation, and operations, because augmented individuals sit inside your org chart but outside your accountability structure.
The failure pattern is predictable. Domain logic gets split across people with no single owner, integration contracts are maintained by whoever touched them last, and each rotation off the project takes tribal knowledge with it. Individual contributors optimize for their assigned tickets, correctly, and the system as a whole drifts.
The fix, if you augment anyway, is to define a single owner for each domain logic module and each integration contract, regardless of who implements it. For industry-specific systems, teams with shared accountability outperform collections of isolated contributors. That is not a preference. It is a structural property of how domain knowledge accumulates and survives.
Embedded engineering teams fit when continuity is the main risk
An embedded team model fits when you need a unit that learns your domain, integrates into your workflow, and retains product context across releases. The trigger condition is continuity risk. If you expect the domain logic to evolve over multiple quarters, keeping context together matters more than short-term capacity.
True embedded models are heavier than they sound. They require toolchain alignment, shared sprint rituals, common code review standards, and a shared definition of done. Anything less is staff augmentation with a friendlier name. When those conditions hold, the team stops being an external resource and starts being a durable part of your engineering organization.
At Sentice we run dedicated software engineering teams on exactly this premise, engineers working as one unit from a single office, following your practices and absorbing your domain over years rather than sprints. If your roadmap implies multi-quarter evolution of domain logic, continuity beats capacity. Buy continuity first.
Let’s scope your team
If your roadmap depends on domain logic that keeps evolving, talk through the team shape that fits it.
How to test sector expertise in a technical interview loop
Test domain competence by probing how candidates reason about edge cases, data integrity, and failure handling. Do not ask for industry buzzwords. Anyone can say “reconciliation” in a sentence.
Give the candidate a sample domain event log and ask how it would be replayed or reconciled after an outage. Ask what happens to in-flight transactions when the upstream system comes back with different data. Ask them to sketch the state machine for a refund after settlement. A candidate with real expertise will ask you questions back, about idempotency, about ordering guarantees, about who owns the source of truth. A candidate performing expertise will jump straight to an architecture diagram.
The failure mode this prevents is expensive and common: selecting a team that demos well but cannot operate under strict production constraints. The demo tests the happy path. Your interview loop has to test everything the demo skipped.
The minimum viable domain stack for a first release
A first release must include the smallest set of domain primitives, auditability features, and integration contracts needed to produce trustworthy outcomes. Trustworthy means three things here: consistent records, traceable actions, and clear exception handling. Strip anything else.
In practice the minimum stack looks like this. The core entity and its state machine, enforced in the database rather than only in application code. An append-only event log for every state transition. One integration contract, the most critical external system, implemented properly with retries and idempotency. A manual review queue for exceptions, because there will be exceptions and spreadsheet tracking does not survive contact with auditors.
If the release is purely internal and low-risk, you can relax audit depth while keeping the boundaries explicit. For anything else, our end-to-end software solutions work has convinced us the first release should cover the full stack from UI to integration, because a partial slice that skips the integration defers the riskiest unknown to the phase where it is most expensive to discover.
Pick one workflow and prove domain fit
Choose a workflow that contains real exceptions, touches at least one integration, and produces an auditable record. Build that thin slice end-to-end, with the same engineering standards you will use at full scale. If the slice holds up under messy inputs, your domain model is probably right. If it does not, fix the primitives before you scale the team or the scope.
Frequently asked questions
What is the difference between industry-specific software and custom software?
Custom software is built to order but can be domain-agnostic. Industry-specific software embeds sector rules and constraints directly into the architecture. A custom internal tooling project might solve a generic approval workflow need. Industry-specific software solves sector rules like post-settlement clawback or clinical order retraction, where the domain logic is the product.
What does vertical architecture look like in practice?
The architecture is driven by domain primitives and state machines rather than generic CRUD operations. The database schema enforces invariants that match the business workflow, such as preventing a settlement record from being modified after close. Most of the code volume sits in transitions and exceptions, not in list and form screens.
How do we document domain knowledge so it survives team changes?
Capture domain rules in a living glossary and tie each rule to a decision log entry and an executable test. Use the same ubiquitous language in the codebase as in the glossary, so a class named DisputeResolution maps to the term your operators use. Documentation nobody can trace to code rots within a quarter.
What signals that a team is faking sector expertise?
The clearest signal is a team that presents UI mockups before understanding the data model or exception flows. Add the absence of clarifying questions about edge cases and failure states during technical discovery. Genuine experts probe the messy parts first, because that is where their scars are.
How do we keep domain logic testable as rules evolve?
Isolate domain logic from infrastructure code so rules can change without touching database or messaging layers. Write behavioral tests in the domain’s own language, and build fixtures from real-world edge cases rather than clean synthetic records. When a rule changes, the test names should read like the regulation that changed.
What should we expect from the first 30 days of an engagement?
Expect a completed discovery phase producing a domain glossary, a context map, and a thin-slice release plan. The team should also deliver a working integration contract for your most critical external system, validated against a sandbox or a recorded fixture set. If week four produces only slide decks, the engagement is drifting.
About Sentice
Sentice is a boutique software engineering partner founded in 2013 by Roni Levi and Martin Petkovic, now headquartered in Skopje, North Macedonia. Rather than supplying individual developers, we build embedded teams that blend with a client’s culture, tech stack and goals, working together from a single office under our own technical leadership. We deliver dedicated software engineering teams, end-to-end software solutions, product development, and system and embedded engineering, and we act as technical advisors across the full development lifecycle, from specification and architecture through development, testing and support. We use AI coding tools across every project, and we help clients integrate AI into their own products through chatbots, MCP services, connected application layers and workflow automation. Some of the clients we started with more than a decade ago are still building with us today.