“Our billing migration has stalled and we're afraid to cut over.”
Usually the cutover plan is the problem, not the code. I have run this migration on a live operator, with every CDR accounted for on both sides of the switch.
Telecom billing. CTI and telephony. Low-latency execution.
Some systems can't be built by trial and error.
I build these systems, and I rescue them when they stall: the ones where a bug writes the wrong invoice, drops the call or sends an order nobody wanted. From the switch to the browser, working with your team rather than instead of it.
- 100,000subscribers billed by a system I built and then ran
- Millionsof CDRs a day through mediation, rating and reconciliation
- 11 yearsthat billing stayed in production without a rating rewrite
- 4 monthsfrom nothing to beta for a contact centre of several hundred agents
What people come to me with
“We need CTI on our PBX and the vendor quoted a year.”
CSTA is a large specification with a small useful core. An agent desk on top of an existing PBX takes months if you know which parts of the spec your switch actually implements.
“The backtest says this strategy works. Live says otherwise.”
Most of that gap is accounting rather than execution: fees left out of the model, an exit horizon that does not match the signal, or a leak between the data used to pick parameters and the data used to check them.
Selected work
11 years in production without a rating rewrite
Billing for a fixed-line operator: eleven years in production
A rating and charging system built when there was nothing on the market to buy, which then had to survive a decade of tariff changes, a new regulatory settlement model, and a company that grew around it.
Several hundred agents, four months to beta
Replacing Avaya under a live contact centre
An agent desk and the middleware under it, built against a young contact-centre platform whose API was still growing while the project ran, where the schedule risk sat in another company’s backlog.
Nine years in production, audience up 25%, two services extracted
Nine years, one developer, and two services
A CRM for commercial property, kept in production for nine years while its backend platform, its frontend generation and its database were all replaced underneath it. The interesting decision was how little of it became services.
Signal worth 0.5–1.5 bp against 11 bp of cost. No live order ever sent.
Six layers, and the measurement that killed the strategy running on them
A six-layer crypto execution platform I built for myself, and the two weeks of measurement that proved the strategy on top of it could not pay for its own fees. The engineering was fine. The economics were never checked, until they were.
Start with an architecture review
One to two weeks, fixed price. I read the code, the schema and the deployment, talk to the people who run the system, and write down what is actually there: ranked risks, the bottlenecks with the measurement behind them, and a staged plan for the next quarter.
It is also the cheapest way for both of us to find out whether a larger project is real, which is why most of them start here.
Writing
- Migrating a fixed-line billing system without losing a single CDR
· The hard part of a billing migration is not rating calls correctly in the new system. It is proving that both systems agree before you cut over, and still being able to reproduce last March a year afterwards.
- The website was the easy part
· Five weeks, one person, 48,000 lines. A therapy practice needed booking, a client area, session packages, debt tracking and four messaging transports. The hard parts were the ones I already knew from telecom billing.
- Fifteen ideas, zero orders: how to kill your own hypothesis cheaply
· I built a trading platform before checking whether anything profitable would flow through it. Then I built the discipline that answered that question for fifteen strategies in a row, and never placed a single order.
Describe your problem in three sentences. I'll tell you honestly whether I can help.
If it isn't my kind of problem, I'll say so and point you somewhere better. Direct email works too: hi@realgeek.biz.