Skip to content
Starone

Industries

Different industries, different failure modes

We do not sell an industry template. For each sector below we describe the engineering problems that actually determine whether a system succeeds there, and what we build to solve them.

Financial Services

For banks, insurers, asset managers and capital-markets firms modernising core systems while keeping them auditable and available.

Engineering problems

Core systems that only speak batch
Core banking and policy administration platforms often expose data through nightly files, while digital channels expect a current balance or policy status in milliseconds. Bridging the two requires change data capture, an API layer and a clear rule for which side is authoritative between batch runs.
End-of-day processing under time pressure
Settlement, interest accrual and regulatory extracts must complete inside a fixed window, and a single failed job can delay everything behind it. Jobs need to be restartable from a checkpoint and idempotent, so a rerun does not post entries twice.
Entitlements across products and legal entities
Who may see or approve a transaction depends on role, desk, legal entity, client relationship and limit. When those rules are scattered across applications, access reviews become guesswork and segregation of duties cannot be demonstrated.
Data lineage for regulatory reporting
A figure in a regulatory return has to be traceable to the source transactions that produced it. Pipelines built from undocumented transformations and manual spreadsheet steps make that trace impossible to reproduce.

What we build

  • API and event layers in front of core banking and policy systems
  • Restartable batch and settlement processing
  • Centralised entitlement and approval services
  • Reporting data platforms with column-level lineage
  • Customer onboarding and case management workflows

FinTech

For payment companies, digital wallets, lenders and financial-product start-ups building money-moving systems from the ledger up.

Engineering problems

Retries that move money twice
A timeout between your service and a payment provider leaves the outcome unknown, and a blind retry can charge a customer again. Every mutating call needs an idempotency key stored atomically with its effect.
Webhooks that arrive late, twice or out of order
Providers deliver status updates at least once and with no ordering guarantee, so a refund notice can arrive before the capture it refers to. Payment state has to be a persisted state machine that rejects invalid transitions and tolerates duplicates.
Balances with no entries behind them
A wallet balance kept as one mutable number cannot be audited and is prone to race conditions under concurrent spend. Balances should be derived from an append-only double-entry ledger, with integer minor units and explicit currencies.
Reconciliation breaks found weeks later
Internal records, provider settlement reports and bank statements disagree on timing, fees and references. Without automated daily matching, small differences accumulate until their cause can no longer be found.

What we build

  • Double-entry ledgers and wallet services
  • Payment orchestration with provider adapters
  • Lending origination and repayment schedules
  • KYC, screening and transaction-monitoring integrations
  • Automated reconciliation and exception handling

Digital Assets

For exchanges, custodians, brokers and treasury teams that hold and move digital assets and need the infrastructure to do so safely.

Engineering problems

Hot wallet keys within reach of an attacker
A signing key held on an application server is exposed to anyone who compromises that server, and an on-chain transfer cannot be reversed. Keys belong in hardware security modules or multi-party computation, with every signature checked against policy.
Deposits credited before they are final
A transaction seen in a recent block can vanish in a chain reorganisation after the user has already traded against it. Confirmation thresholds must be set per network, and the indexer must be able to roll back and reprocess from the fork point.
Stuck withdrawals and nonce gaps
An underpriced transaction can sit in the mempool and block every later one from the same account. The withdrawal pipeline needs explicit nonce tracking, fee replacement rules and a guarantee of one transfer per request.
Customer liabilities versus on-chain holdings
The internal ledger and the balances at platform addresses drift apart through missed deposits, unrecorded network fees and failed sweeps. Per-asset reconciliation has to run continuously and alert on any shortfall.

What we build

  • Custody and policy-controlled signing services
  • Deposit detection and withdrawal pipelines
  • Matching engines and internal settlement ledgers
  • On-chain monitoring and address-risk screening
  • Treasury and proof-of-holdings reconciliation tooling

AI

For AI product companies and teams building model-backed features that have to hold up under real traffic, cost limits and scrutiny.

Engineering problems

No regression test for model behaviour
A prompt tweak or a model upgrade can fix one case and break ten, and without an evaluation set the breakage is found by users. Quality needs a scored dataset that runs in the delivery pipeline and gates releases.
Inference cost that scales faster than revenue
Long contexts, large models used for trivial tasks and uncached repeat queries turn usage growth into margin loss. Routing by task difficulty, caching, context trimming and batching have to be designed into the serving path.
GPU capacity that is either idle or exhausted
Self-hosted models need accelerators that are expensive to leave idle and slow to provision when a spike arrives. Serving requires request batching, autoscaling on queue depth and a fallback path when capacity runs out.
Untrusted input reaching tool-calling models
Content retrieved from documents or the web can carry instructions that a model follows as if they came from the user. Tool permissions must be scoped to the caller, and retrieved content treated as data, never as instructions.

What we build

  • Retrieval and orchestration backends for AI products
  • Evaluation harnesses and quality gates
  • Model gateways with routing, caching and cost attribution
  • Model serving on Kubernetes with GPU autoscaling
  • Guardrail and prompt-injection defences

Enterprise Software

For software vendors and internal platform teams whose products are sold to, or run inside, large organisations.

Engineering problems

A monolith that every team must release together
When one codebase and one database serve every feature, a small change waits for a full regression cycle and one team's defect blocks all others. Module boundaries and data ownership have to be established before any service is extracted.
Customer-specific forks
Custom work for large customers ends up as long-lived branches that must each be patched and tested separately. Variation should be expressed as configuration, extension points and feature flags on a single codebase.
Integrations that break on customer upgrades
Enterprise customers run different versions of the systems you integrate with, on their own schedules. Without versioned API contracts and adapter isolation, each customer upgrade becomes an incident.
On-premises and cloud from one codebase
Some buyers require deployment in their own environment, where you cannot observe or patch the system directly. Packaging, upgrades and diagnostics need to work without assuming your own cloud control plane.

What we build

  • Modular backends with enforced domain boundaries
  • Extension and plug-in frameworks
  • Versioned public APIs and SDKs
  • Installers and upgrade tooling for customer-hosted deployments
  • Audit logging and enterprise access control

SaaS

For SaaS companies whose platform has to isolate tenants, meter usage and release continuously as the customer base grows.

Engineering problems

A missing tenant filter
If isolation depends on every query including a tenant clause, one omission shows one customer another's data. Isolation needs to be enforced below the application, with row-level security or per-tenant stores.
One tenant degrading everyone
A large import or an expensive report from a single customer can saturate shared database connections and queues. Per-tenant rate limits, quotas and workload isolation keep one tenant's load from becoming a platform incident.
Usage events counted wrongly
Metering events dropped under load or duplicated on retry lead to invoices that customers dispute. Events need idempotency keys, durable transport and an aggregation that can be replayed and explained.
Schema migrations that lock tables
A migration that rewrites a large table blocks writes for every tenant at once. Changes have to follow expand and contract steps so old and new application versions can run against the same schema.

What we build

  • Tenant control planes and automated provisioning
  • SSO, SCIM and role-based access integration
  • Usage metering and billing pipelines
  • Entitlement and feature-flag services
  • Zero-downtime release and migration pipelines

E-commerce

For online retailers, marketplaces and direct-to-consumer brands whose revenue depends on a fast storefront and accurate orders.

Engineering problems

Overselling during a flash sale
Many buyers check out the last units at once, and a read-then-write stock check lets several of them succeed. Inventory needs atomic reservation with expiry, and a queue or rate limit that protects the database at peak.
Checkout that half-completes
Payment succeeds but the order write fails, or the reverse, leaving a charged customer with no order. Checkout has to be an idempotent saga with compensation for each step and a reconciliation job behind it.
Catalogue pages that are slow or stale
Rendering every product page on demand is slow under load, while caching aggressively shows old prices and stock. The answer is a rendering and cache-invalidation strategy tied to product and price change events.
Search that returns nothing useful
Shoppers misspell, use synonyms and filter by attributes the catalogue stores inconsistently. Search needs a dedicated index, normalised attributes and relevance tuning measured against real queries.

What we build

  • Headless storefronts with edge caching
  • Inventory reservation and order management services
  • Idempotent checkout and payment integration
  • Product search and recommendation backends
  • Marketplace seller onboarding and payout systems

Healthcare Technology

For health-tech companies, providers and device makers building software that handles clinical data and connects to clinical systems.

Engineering problems

Clinical systems that do not share a data model
Records arrive as HL7 v2 messages, FHIR resources, DICOM studies and proprietary exports, each with local variations in coding. Integration needs an engine that maps and validates these into a canonical model and flags what it cannot map.
Duplicate and mismatched patient identities
The same patient appears under different identifiers and spellings across facilities, and merging the wrong records is a safety risk. Matching needs deterministic and probabilistic rules, with ambiguous cases sent for human review.
Access to records that nobody can account for
Clinicians need rapid access, including emergency override, while every view of a record must be attributable. This calls for fine-grained authorisation, break-glass procedures and an immutable access log.
Software that must keep working offline
Wards, clinics and field settings lose connectivity, and care cannot wait for it to return. Applications need local storage, conflict-aware synchronisation and clear indication of what has not yet been sent.

What we build

  • HL7 and FHIR integration services
  • Patient and clinician applications for web and mobile
  • Consent, access control and audit logging
  • Clinical data platforms with de-identification pipelines
  • Document intelligence for clinical and claims paperwork

Logistics

For carriers, freight forwarders, warehouse operators and delivery platforms coordinating physical movement through software.

Engineering problems

Carrier events that are late, duplicated and out of order
Tracking updates come from many carriers through APIs, EDI files and email, and a delivered scan can arrive before the out-for-delivery scan. The shipment timeline has to be rebuilt from event time, with deduplication and tolerance for late arrivals.
High-frequency location data
Thousands of vehicles reporting position every few seconds produce a write-heavy stream that a transactional database handles poorly. Telemetry belongs in a streaming pipeline and time-series store, with only derived state written to operational tables.
Driver apps with no signal
Proof of delivery is captured in basements, lifts and rural areas where the network is absent. The mobile app must work offline, queue signatures and photographs, and synchronise without creating duplicates.
Route plans invalidated by reality
Traffic, failed deliveries and new orders make a morning plan obsolete by midday. Re-optimisation has to run incrementally within seconds and respect time windows, capacity and driver hours.

What we build

  • Shipment event ingestion and tracking platforms
  • Carrier and EDI integration layers
  • Offline-first driver and warehouse mobile apps
  • Telemetry pipelines and estimated-arrival services
  • Dispatch, routing and exception-management tools

Retail

For retailers running physical stores alongside online channels who need stock, prices and customers to agree across all of them.

Engineering problems

Stores that must trade through an outage
A point-of-sale terminal that depends on a live connection to head office stops selling when the link drops. Tills need local transaction storage and deferred synchronisation that resolves conflicts when connectivity returns.
Stock figures that differ by channel
Store systems, the warehouse and the website each hold their own inventory count and update on different schedules. Click-and-collect and ship-from-store depend on a single availability service fed by near-real-time stock events.
Price and promotion changes across many stores
A promotion must start at the same moment on tills, shelf labels and online, and overlapping offers must resolve the same way everywhere. This needs one pricing engine and a distribution mechanism that confirms each store has applied the change.
One customer, several profiles
Loyalty, e-commerce and in-store systems each identify a customer differently. Unifying them requires identity resolution with consent tracking, so personalisation and data-subject requests work from one record.

What we build

  • Offline-capable point-of-sale backends
  • Unified inventory and availability services
  • Central pricing and promotion engines
  • Loyalty platforms and customer data pipelines
  • Store operations and replenishment applications

Web3

For protocol teams, decentralised application builders and infrastructure providers who need engineering beyond the smart contract.

Engineering problems

Reading chain state at application speed
Querying a node directly for historical events or aggregated balances is too slow for a user interface. An indexer has to ingest blocks, handle reorganisations and serve the data from a query-optimised store.
Contracts that cannot be patched
A deployed contract is immutable unless an upgrade path was designed in, and that path is itself a privileged control. Upgradeability, pause mechanisms and their governance must be decided and tested before deployment.
RPC endpoints as a single point of failure
A front-end or backend tied to one node provider fails or serves stale data whenever that provider does. Requests need failover across independent sources and checks for nodes that have fallen behind.
Transaction flows users abandon
Seed phrases, gas tokens and multi-step approvals lose most non-specialist users. Account abstraction, sponsored transactions and clear transaction simulation reduce that friction without hiding what is being signed.

What we build

  • Smart contracts with fuzz and invariant test suites
  • Chain indexers and query APIs
  • Wallet integration and account-abstraction flows
  • Relayers, keepers and off-chain automation services
  • Node infrastructure and multi-provider RPC gateways

Cybersecurity

For security product companies and internal security teams building the platforms that collect, analyse and act on security data.

Engineering problems

Telemetry volume against a fixed budget
Endpoint, network and cloud logs arrive at a rate that makes indexing everything unaffordable. Pipelines need to parse, filter and tier data at ingestion, keeping hot storage for what detections query and cheap storage for the rest.
Alerts that analysts learn to ignore
Detections that fire constantly on benign activity bury the one that matters. Rules need testing against recorded data, enrichment with asset and identity context, and tuning tracked as code.
Sources with a hundred different schemas
Every product logs the same event with different field names, formats and timestamps. Correlation only works after normalisation to a common schema, with parsers that are versioned and monitored for silent breakage.
Automated response that could cause an outage
A playbook that isolates a host or disables an account acts with high privilege and can be triggered by a false positive. Response actions need scoped credentials, approval gates for destructive steps and a complete audit trail.

What we build

  • Security data pipelines and detection platforms
  • Detection-as-code repositories and test frameworks
  • Response automation with approval controls
  • Identity, secrets and policy-enforcement services
  • Agents and collectors for endpoints and cloud accounts

Business Automation

For operations, finance and shared-service teams whose processes still depend on people moving data between systems by hand.

Engineering problems

Scripts that stop halfway and tell no one
A scheduled job fails at one step, leaves records partly updated and is noticed days later. Processes need a durable workflow engine that persists each step, retries transient faults and surfaces stuck instances.
Documents in hundreds of layouts
Invoices and forms arrive as scans and PDFs whose formats change without notice, defeating template-based extraction. Extraction needs model-based parsing, validation against master data and review for low-confidence fields.
Approvals lost in email
A request waiting in an inbox has no deadline, no escalation and no link to the process it blocks. Approvals must be tracked tasks with owners, timeouts, delegation and a recorded decision.
AI agents acting beyond their remit
An agent with broad credentials can take an unintended action, especially when a document it reads contains hostile instructions. Each agent needs a narrow tool set, scoped permissions and human sign-off for consequential steps.

What we build

  • Durable workflow and orchestration platforms
  • Document intake and extraction pipelines
  • AI agents with human-in-the-loop approval
  • Connectors to ERP, CRM and finance systems
  • Process monitoring and exception queues

Your sector is not listed

The engineering carries over. Describe the constraints you work under and we will tell you how we would approach them.

Start a project