Industry
Software engineering for Telecommunications
Telecoms software is defined by three things that do not forgive shortcuts: massive scale and real-time load, charging that has to be correct as it happens, and an OSS/BSS estate of interlocking systems no single project replaces. The interface is never the hard part. Scale, real-time charging and integration are, and Ofcom obligations like One Touch Switch and number porting sit on top. We build for that reality.
Why the domain matters
A telco, ISP or MVNO is not a website with a lot of users; it is a set of interlocking operational and business systems running at a scale and a tempo that punish anything built casually. Calls, sessions and data flow continuously and have to be rated and charged in real time or close to it; services have to be provisioned onto real network elements; the network inventory has to be known; customers have to be billed correctly, ported between providers, and switched under regulated processes. The operational support systems and business support systems (OSS and BSS), that do all this form a sprawling estate that has grown over decades, and the hard problems live in how they scale, how correct they are in real time, and how they integrate, not in the screens on top.
The market has a shape worth naming, because software lands very differently across it. A full mobile network operator runs deep OSS and BSS across a physical network and carries the heaviest real-time charging and inventory load. An MVNO rides another operator’s network and lives or dies on its BSS (billing, charging, provisioning and customer management), and on the integration into the host network. An ISP or fixed-line provider carries order management, provisioning across access networks, and switching obligations. What unites them is scale that makes inefficiency expensive at every transaction, charging and rating that have to be right as money and usage accrue, regulated processes like number porting and One Touch Switch that are not optional, and an integration estate where the real cost of change lives. Software that underestimates any of those does not merely underperform: it loses revenue, misbills customers, or breaches an Ofcom obligation.
We are a senior-led team and we operate what we build, so we start from the scale, the real-time correctness and the existing OSS/BSS estate rather than from a product we would like to sell. The recurring failure mode in telecoms software is a system that demos beautifully at low volume and falls over at production scale, or a charging path that is subtly wrong and quietly leaks revenue or overbills customers, or a new component that assumes a clean integration the estate does not offer. We would rather do the unglamorous work of engineering for scale, getting the real-time charging correct, and integrating honestly with the OSS/BSS estate than ship a front end that impresses in a pitch and then cannot carry the load. The hard part here is scale, real-time charging and integration, and we build for it. Where the work is the contact centre rather than the network, that runs through our call centre engineering and, for operators running the open-source route, VICIdial.
The challenges in telecommunications
Scale that makes every inefficiency expensive
Telecoms systems handle enormous volumes (events, sessions, subscribers, usage records), continuously, so an inefficiency that is invisible at demo scale becomes ruinous in production. Rating and charging paths, inventory queries and order flows all have to hold up under sustained real load, not a benign test. Building here means engineering for scale from the start (data models, throughput, back-pressure and horizontal growth), because a system that works for a thousand records and dies at ten million has not solved the problem, it has postponed it to the worst possible moment.
Real-time charging that has to be correct as it happens
Charging and rating decide what customers pay, often in real time as usage accrues and against balances, bundles and tariffs that have to be applied correctly the moment they are consumed. Errors are not cosmetic: undercharging leaks revenue, overcharging harms customers and invites regulatory attention, and a race condition on a balance is money. This raises the bar on correctness, consistency and reconciliation far above ordinary business software, because the system is handling money in motion at high volume with little room to be quietly wrong.
An OSS/BSS estate no single project replaces
The operational and business support systems have grown over decades into a sprawling estate of interlocking components (billing, charging, provisioning, order management, inventory, mediation, CRM), each depending on the others. New work almost always means integrating into this estate, not replacing it, because a big-bang OSS/BSS transformation is one of the riskiest programmes in the industry. The real cost and risk of change live in the integration, so any plan that assumes a clean slate ignores the estate the business actually runs on.
Provisioning and order management across real network complexity
Turning an order into a working service means orchestrating provisioning across real network elements and other systems, with steps that can fail, partially complete, or need to be unwound. Order-to-activation is a distributed, long-running process where the failure modes: a service half-provisioned, an order stuck, an activation that succeeded on the network but not in billing, are exactly what damage customer experience and revenue. Getting this right is orchestration and reconciliation, not a simple form-to-database flow.
Regulated processes that are not optional
Number porting and, for consumer switching, One Touch Switch are Ofcom-regulated processes with defined behaviours and timescales that a provider must implement correctly, not approximate. They involve inter-provider messaging and coordination, and getting them wrong is both a customer-experience failure and a regulatory one. These obligations shape the software directly (what it must do, in what order, by when), so they are design inputs from the start, not features to add once the happy path works.
Resilience because the service is essential and always on
Connectivity is an essential service that people and businesses depend on continuously, so telecoms systems are held to a standard of availability and resilience above ordinary commercial software. Charging, provisioning and the customer-facing paths cannot simply go down for maintenance, and outages have regulatory and reputational weight. That raises the bar on redundancy, graceful degradation, and the ability to recover cleanly, because in telecoms a system that is correct but not resilient has still failed the customers relying on it.
What we build for telecommunications
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
BSS: billing, charging and customer management
Business support systems built for the reality of telecoms billing, rating and charging that stay correct at volume, bundles and tariffs applied properly, invoicing, and customer management that ties it together. For MVNOs especially, the BSS is the business, so we build it to carry real-time charging correctly and to reconcile against usage, because a charging path that is subtly wrong leaks revenue or overbills customers and neither is a cosmetic defect.
Real-time and convergent charging
Charging engines and integrations that rate usage in real time against balances, bundles and policies, handling the concurrency and consistency that money-in-motion demands. We treat correctness and reconciliation as the point rather than an afterthought, engineering the balance and rating logic to hold up under concurrent load, because a race on a balance or a mis-applied tariff at scale is revenue lost or customers wronged, not a rounding error to fix later.
Provisioning and order management
Order-to-activation orchestration that turns an order into a working service across real network elements and downstream systems, built as the distributed, long-running, failure-prone process it actually is. We design for the failure modes, half-provisioned services, stuck orders, activations that succeed on the network but not in billing, with reconciliation and compensating actions, because a form that writes to a database is not order management, and the gap between the two is where customer experience and revenue leak.
Network inventory and OSS components
Operational support components that keep an accurate picture of the network and its resources, inventory, resource management and the data that provisioning and assurance depend on. An inaccurate inventory quietly undermines everything built on top of it, so we treat keeping the network picture correct and consistent as core work, because provisioning and assurance decisions are only as trustworthy as the inventory they are made against.
Number porting and One Touch Switch
Implementations of the regulated switching and porting processes (number porting and One Touch Switch), built to the defined behaviours, timescales and inter-provider messaging Ofcom requires, not approximated. We treat these as design inputs from the start, engineering the coordination and the edge cases deliberately, because getting a regulated switch or port wrong is simultaneously a customer-experience failure and a regulatory one, and both land on the provider.
Integration across the OSS/BSS estate
Integration layers, mediation and APIs that let new capability plug into the existing OSS/BSS estate without pretending it is a clean slate. We treat the estate as the interlocking, decades-grown reality it is, and build integration that respects the dependencies between billing, charging, provisioning, inventory and CRM, because the real cost and risk of telecoms change live in the integration, and a big-bang replacement is one of the riskiest programmes in the industry.
Where we help
A charging path that stays correct at production scale
An operator or MVNO is losing revenue or generating billing complaints because rating and charging drift under real load. We engineer the charging path for correctness under concurrency (balances, bundles and tariffs applied right as usage accrues), with reconciliation that surfaces discrepancies rather than hiding them. The measurable win is charging that is correct at ten million events, not just ten, because the difference between the two is leaked revenue and wronged customers, and it only ever shows up at the scale a demo never reaches.
Order-to-activation that does not strand services or orders
A provider’s order flow leaves services half-provisioned, orders stuck, or activations that succeeded on the network but never reached billing. We rebuild it as the distributed, long-running orchestration it really is, with explicit handling of partial failure, reconciliation and compensating actions. The win is orders that complete or unwind cleanly rather than silently stranding a customer between systems, because the gap between a form-to-database flow and real order management is exactly where customer experience and revenue quietly leak.
One Touch Switch and number porting implemented to the rules
A provider has to implement a regulated switching or porting process correctly, with the inter-provider messaging, timescales and behaviours Ofcom defines. We build it to the actual rules and edge cases rather than approximating the happy path, coordinating with the other provider’s side and handling the failure cases deliberately. The value is a switch or port that works for the customer and satisfies the regulator at once, because getting it wrong is both a customer-experience failure and a regulatory breach that lands squarely on the provider.
New capability integrated into a legacy OSS/BSS estate
A telco wants new customer-facing or operational capability but cannot rip out the OSS/BSS estate to get it. We build integration and mediation layers that let the new capability plug into billing, charging, provisioning and inventory as they are, respecting the dependencies rather than assuming a clean slate. The win is genuinely new capability delivered without betting the business on a big-bang transformation, because in telecoms the real cost and risk of change live in the integration, and that is exactly where we concentrate the engineering.
How we build for telecoms
We start from scale, real-time correctness and the existing estate, not the screens. Before designing anything we want to understand the volumes the system will actually carry, where charging has to be correct in real time, and how the OSS/BSS estate is wired together, because in telecoms those three shape delivery far more than any interface. We design for production load and money-in-motion from the outset, not for a benign demo that never meets the scale the system has to survive.
We engineer for scale and correctness as first-class concerns, not optimisations to add later. Data models, throughput, concurrency and reconciliation are decided early, because a charging path or an inventory query that is fine at demo volume and collapses at production scale has postponed the problem to the worst possible moment. On charging especially we treat correctness and consistency as the point: a race on a balance or a mis-applied tariff at scale is money, not a rounding error, and we build reconciliation that makes discrepancies visible.
We treat the OSS/BSS estate as the interlocking reality it is and integrate honestly with it. New capability plugs into billing, charging, provisioning and inventory as they actually exist, with integration and mediation that respect the decades-grown dependencies, rather than a big-bang replacement that is one of the riskiest programmes in the industry. We are candid that this is less glamorous than a clean rebuild, and that candour is precisely what keeps a telecoms change from becoming a transformation horror story.
Because we operate what we build, the people designing a charging path, an order-orchestration flow or a porting implementation are the ones accountable when a balance races, an order strands a service, or a regulated switch misbehaves. That concentrates the mind on the failure modes that actually matter in telecoms (leaked revenue, misbilled customers, half-provisioned services, a breached Ofcom obligation), and keeps us honest about scale and trade-offs up front rather than discovering them in production at volume on the operator’s behalf.
Regulation and compliance
Telecoms in the UK is regulated by Ofcom, and a number of the regulator’s requirements reach directly into the software. Consumer switching through One Touch Switch and number porting are defined processes with expected behaviours, inter-provider messaging and timescales that a provider must implement correctly rather than approximate. We treat these as design inputs from the start, because getting a regulated switch or port wrong is simultaneously a customer-experience failure and a regulatory one, and both land on the provider.
Billing accuracy and fair treatment of customers carry regulatory weight of their own. Charging that overbills customers or systematically misapplies tariffs is not merely a defect but a matter that attracts regulatory and reputational attention, so we treat charging correctness and reconciliation as compliance-relevant engineering, not just a quality target. The obligation to bill customers correctly is one the provider is accountable for, and the software has to make that accuracy demonstrable.
Resilience and continuity matter because connectivity is an essential service. There are expectations around the availability and security of telecoms networks and services, and outages carry regulatory as well as commercial consequences, so we build charging, provisioning and customer-facing paths for the availability the sector demands rather than treating downtime as an ordinary trade-off. Data protection under UK GDPR sits across all of it, given the volume of personal and usage data telecoms systems hold.
We build software that supports these obligations, but we are engineers, not your regulatory or compliance function. The obligations around switching, porting, billing accuracy, network resilience and security carry real weight, and accountability for them rests with the provider and its regulatory team. Our job is to build software that implements the regulated processes correctly, makes billing accuracy demonstrable, and holds up to the availability expected of an essential service, and to work alongside the people accountable for Ofcom compliance rather than to stand in for them.
Integration
The OSS/BSS estate is the gravitational centre of telecoms integration. Billing, charging, provisioning, order management, mediation, network inventory and CRM have grown over decades into interlocking systems that depend on one another, and new work almost always plugs into this estate rather than replacing it. We treat integration and mediation as first-class engineering, respecting the dependencies between components, because the real cost and risk of telecoms change live here, and a big-bang OSS/BSS transformation is one of the riskiest programmes in the industry.
The network itself is an integration target as much as any software system. Provisioning has to reach real network elements to activate services, and assurance and inventory have to reflect the actual state of the network, so order-to-activation and inventory work are distributed integrations with the network, not database writes. We design for the failure modes that live at that boundary: activations that succeed on the network but not in billing, or an inventory that drifts from reality, because those gaps are where service and revenue leak.
Inter-provider integration is unavoidable for regulated processes. Number porting and One Touch Switch require coordination and messaging with other providers to defined behaviours and timescales, and for MVNOs the integration into the host operator’s network is fundamental to the whole business. We build these external integrations to the actual rules and edge cases, because they are both customer-facing and regulator-facing, and a failure at the boundary is visible to the customer and the regulator at once.
The recurring integration problem across all of this is consistency at scale: the same subscriber, service, order or network resource represented across many systems that were never designed to agree, at volumes that make reconciliation a serious engineering task rather than a nightly script. We treat that reconciliation, between charging and usage, between orders and activations, between inventory and the real network, as core work, because in telecoms the discrepancies that hide in it are money, stranded services, or a misbilled customer.
Security and data protection
Telecoms systems hold a great deal of sensitive data (subscriber identities, usage and location-adjacent records, billing and payment data), at enormous volume, and they sit at the heart of an essential service, which makes them a serious target. We build with access controls scoped to genuine need, encryption in transit and at rest, and retention limited to what a lawful basis supports, because the combination of volume and sensitivity means a breach here has both a large blast radius and regulatory consequences.
Charging and billing are a direct financial-fraud and revenue-assurance surface. Fraud against telecoms charging is a real and evolving threat, and revenue leakage through subtle charging errors is a standing risk, so we build the charging and reconciliation paths to make anomalies and discrepancies visible rather than silent, because at telecoms volumes a small systematic error or an exploited gap is a large amount of money, and revenue assurance is a security concern as much as a billing one.
Resilience is part of security when the service is essential. An outage or a compromise of charging, provisioning or customer-facing systems does not just embarrass the provider; it denies people and businesses a service they depend on, with regulatory weight attached. We build for availability, graceful degradation and clean recovery, treating the ability to keep running and to recover cleanly as a security property, not merely an operational nicety, because in telecoms downtime is a form of harm.
Because we operate what we build, security here is not a report handed over at the end. We instrument for the access patterns, fraud signals and reconciliation discrepancies that indicate a problem, keep the audit trail an investigation or a regulator would need, and treat the ability to reconstruct exactly what happened to subscriber data, to a charge, or to an order as part of the deliverable, because at telecoms scale a quiet failure in security or revenue assurance compounds fast, and finding it missing after the fact is the expensive way to learn that lesson.
What changes
Charging that stays correct at production scale
Because we engineer the charging path for correctness under concurrency and build reconciliation that surfaces discrepancies, rating and billing stay right at production volumes rather than drifting into leaked revenue or customer complaints, closing the gap that only ever shows up at the scale a demo never reaches.
Systems that carry real load and stay up
By engineering for scale and resilience from the start (throughput, concurrency, graceful degradation and clean recovery), the systems carry sustained production load and keep running, rather than demoing beautifully and then falling over at the volume and availability an essential service actually demands.
New capability without a big-bang transformation gamble
Because we integrate honestly into the existing OSS/BSS estate rather than assuming a clean slate, the business gets genuinely new capability without betting itself on one of the riskiest programmes in the industry. The real cost of change handled as integration, where it actually lives, instead of a rip-and-replace.
What we build for telecommunications
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for telecommunications?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in telecommunications choose us
We engineer for scale, because telecoms punishes anything that does not
Telecoms systems handle enormous continuous volumes, and an inefficiency invisible at demo scale is ruinous in production. We decide data models, throughput and concurrency up front, because a system that works for a thousand records and dies at ten million has not solved the problem. It has postponed it to the worst possible moment, at the scale a pitch never reaches.
We treat real-time charging correctness as the point
Charging decides what customers pay, often in real time against balances and bundles, and errors are money, undercharging leaks revenue, overcharging harms customers and draws regulatory attention. We engineer the balance and rating logic for correctness under concurrent load and build reconciliation that makes discrepancies visible, because a race on a balance at scale is not a rounding error.
We integrate honestly with the OSS/BSS estate
The operational and business support systems are an interlocking, decades-grown estate, and the real cost and risk of change live in the integration. We plug new capability into billing, charging, provisioning and inventory as they are, rather than pushing a big-bang replacement that is one of the industry’s riskiest programmes, candour that keeps a change from becoming a transformation horror story.
We operate what we build
The people who design a charging path, an order-orchestration flow or a porting implementation are the ones accountable when a balance races, an order strands a service, or a regulated switch misbehaves. That keeps us focused on the failure modes that matter in telecoms (leaked revenue, misbilled customers, half-provisioned services, a breached Ofcom obligation), and honest about scale and trade-offs up front.
Common questions
Can you build billing and real-time charging that stays correct at scale?
Yes, and we treat correctness under load as the whole point rather than an optimisation to add later. Charging decides what customers pay, often in real time against balances, bundles and tariffs, so we engineer the rating and balance logic for the concurrency and consistency that money-in-motion demands, and we build reconciliation that surfaces discrepancies rather than hiding them. The difference between right at ten events and right at ten million is leaked revenue or wronged customers, and it only ever shows up at production scale, which is exactly why we engineer for that scale from the start instead of discovering the problem at the worst possible moment.
We have a large, legacy OSS/BSS estate, do you replace it or integrate with it?
Almost always integrate, because a big-bang OSS/BSS transformation is one of the riskiest programmes in the industry and the real cost of change lives in the integration anyway. The estate (billing, charging, provisioning, order management, inventory, mediation, CRM), has grown over decades into interlocking systems that depend on one another, so we build integration and mediation layers that let new capability plug in and respect those dependencies, rather than assuming a clean slate the estate does not offer. We are candid that this is less glamorous than a rip-and-replace, and that candour is precisely what keeps a telecoms change from becoming a transformation horror story.
Can you implement number porting and One Touch Switch correctly?
Yes, and we treat them as regulated design inputs from the start, not features to bolt onto a working happy path. Number porting and, for consumer switching, One Touch Switch are Ofcom-defined processes with expected behaviours, inter-provider messaging and timescales that have to be implemented correctly, including the edge and failure cases, and coordinated with the other provider’s side. Getting a regulated switch or port wrong is simultaneously a customer-experience failure and a regulatory one, and both land on the provider, so we engineer the coordination and the edge cases deliberately rather than approximating them. We build to the rules; accountability for Ofcom compliance rests with the provider and its regulatory team.
How do you handle provisioning and order-to-activation across the network?
As the distributed, long-running, failure-prone orchestration it really is, rather than a form that writes to a database. Turning an order into a working service means coordinating provisioning across real network elements and downstream systems, with steps that can fail, partially complete, or need unwinding, so we build explicit handling of partial failure, reconciliation and compensating actions. The failure modes that damage customer experience and revenue. A service half-provisioned, an order stuck, an activation that succeeded on the network but not in billing, are exactly what we design for, because the gap between a naive flow and real order management is where service and revenue quietly leak.
How do you handle scale and resilience for an essential service?
By engineering for both from the outset, because connectivity is an essential service and telecoms punishes anything built casually. On scale, we decide data models, throughput, concurrency and back-pressure early, because a system fine at demo volume and collapsing at production volume has only postponed its failure. On resilience, we build charging, provisioning and customer-facing paths for the availability the sector demands, with graceful degradation and clean recovery, because outages carry regulatory as well as commercial weight and a system that is correct but not resilient has still failed the customers relying on it. We build to that bar; accountability for the regulatory expectations around availability rests with the provider.
Building for telecommunications?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if telecommunications is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.