Business problem
Pay-per-call is a three-sided coordination problem wearing the costume of a simple one. A publisher generates a phone call. A buyer wants that call if it matches their vertical, their geography, their hours, their caps and their price. Someone has to decide, in the seconds while a caller is holding, which buyer gets the call and on what terms — and then has to be able to prove afterwards that the decision was correct, that the call met the buyer’s settlement terms, and that the publisher is owed exactly what the ledger says.
The industry does this badly in specific, repeatable ways. Source transparency is weak, so a buyer discovers the quality of a traffic source after paying for it. Operations are fragmented across platform dashboards, spreadsheets and email threads, so the same question gets a different answer depending on who is asked. Routing configuration accumulates exceptions until nobody can predict where a given call will go. And the financial layer — the part that has to be exactly right — is usually the part with the least verification, because a billing system that produces plausible numbers is indistinguishable from a billing system that produces correct ones until someone reconciles against a bank statement.
I had spent years operating inside those failures rather than reading about them. DCE is the attempt to specify a marketplace where the decision path is legible, the tenant boundaries are real, and the financial invariants are asserted by the system instead of assumed by the operator.
Why this was difficult
The hard parts are not the ones a feature list surfaces.
Correctness has to survive being plausible. A routing engine with a subtly wrong eligibility rule still routes calls. A billing pipeline reading the wrong settlement term still produces invoices, and those invoices still get paid. The failure mode of this category of system is not an outage — it is confident, well-formatted, wrong output that accumulates for weeks. Designing for that means deciding in advance which economic relationships must always hold, and treating a violation as an alertable production event rather than something to be found during a month-end close.
Every decision is on a clock held by someone else. An inbound RTB request is answered while a caller is on the line. Buyer endpoints are third-party systems with their own latency, their own error semantics and their own opinions about what a bid means. The auction has to degrade to a defensible decision when a participant is slow or wrong, not wait for perfect information.
Multi-tenancy is a correctness property, not a feature. Two competitors are frequently both buyers in the same vertical. A leak across that boundary is not a bug report, it is a commercial incident, and it can happen through a reporting query as easily as through an API.
The call is a distributed state machine with an unreliable participant — the telephone network. Calls are abandoned mid-bridge, duration events arrive late, and the moment a call becomes billable is defined by a contract term rather than by anything the telephony provider reports.
And I was directing implementation rather than writing it. That makes ambiguity expensive. An underspecified requirement does not stall — a coding agent fills the gap with something reasonable and moves on, and the gap surfaces later as behaviour nobody chose. The discipline the project actually demanded was specification precision and adversarial review, sustained across a codebase far larger than one person could have typed.
My responsibility
I conceived the product, created the PRD and product requirements, defined the core workflows and integration behaviour, researched the technical concepts necessary to make informed decisions, directed coding agents through implementation, established the quality and production doctrine, managed deployment and database operations, and operate the platform in production today.
Concretely, the artifacts that are mine are the requirements and the judgement behind them: what the eligibility and auction rules must do; what an RTB request and response must contain and how a partner’s failure should be interpreted; when a call becomes billable and against which contract term; what a publisher is owed and when that number is allowed to change; what must be true before a migration runs against production; and what a reviewer must be able to verify before a change is allowed to ship.
Constraints
- No engineering team. Delivery capacity came from coding agents under my direction, so the throughput ceiling was my ability to specify and review, not to type.
- Live money. The platform bills buyers and pays publishers. There is no staging tenant with real economics, so financial behaviour had to be provable before it was live, and observable once it was.
- Partner systems I do not control. Roughly 15 first-party external integrations plus partner RTB endpoints, each with its own semantics, uptime and change cadence.
- Compliance and permission boundaries. Caller data, tenant isolation and consent state are not areas where “mostly right” is a category.
- Deliberate deployment friction. Deployments are manual by choice. Continuous deployment of agent-generated changes into a system that moves money optimizes the wrong variable.
Architecture
The spine of the system is a single path a call takes, and every subsystem exists to serve or observe that path. A publisher source produces an inbound request. Eligibility filtering runs before the auction, so buyers who cannot legally or commercially take the call never see it. The auction collects bids from buyer RTB endpoints under a latency budget and resolves to a routing decision with an explicit reservation, so two concurrent calls cannot both be promised the same capacity. Telephony bridges the caller to the winning buyer. The call outcome — duration, disposition, and whether the buyer’s settlement term was actually met — is what feeds the billing and payout ledgers, which in turn feed reporting, reconciliation and the AI operations layer.
Around that spine sit the surfaces and rails: PostgreSQL as the system of record, object storage for recordings and artifacts, the admin, buyer and publisher frontends, the observability stack, the external integrations, and the two agent surfaces — Partner Chat for external users and the operator MCP for internal work. Those two are described in their own case studies, because their design problem is different in kind from this one.
At the measured point in time the production system carried 200 registered buyer and publisher organizations across 30 distinct campaign verticals, more than 50 routing targets, more than 70 configured buyer and publisher RTB integrations, 10K–13K RTB requests on an active day, a peak measured throughput of 3,273 bids per hour, and a peak of 18 simultaneously bridged calls.
Important decisions
Go and PostgreSQL, with typed queries rather than an ORM. The decision was driven by reviewability. When most of the implementation is agent-generated, the property that matters most in a stack is how quickly a reviewer who did not write the code can tell whether it is correct. Explicit SQL with generated typed accessors makes a data-access mistake visible in review; a query builder three abstractions deep does not.
Eligibility before auction, always. Filtering first is marginally more work per request and removes an entire class of incident where an ineligible buyer wins and the call has to be unwound after the fact.
Reservations, not optimistic routing. A routing decision takes a reservation against buyer capacity before the bridge is attempted. Concurrency in this system is not theoretical — the peak of 18 simultaneous bridged calls means capacity races happen daily.
Financial state is derived from recorded events, not edited in place. Billing and payout values come from call outcomes and contract terms rather than from a mutable field someone can correct. Corrections are new events. This is the single decision that most changed how tractable month-end reconciliation is.
Alert on economic invariants, not only on system health. CPU and error rates say nothing about a billing pipeline that is confidently wrong. Production monitoring includes rules for phantom revenue, economic inversion, unearned payout and settlement-term mismatch — conditions where the system is healthy and the money is wrong.
Integration tests run against real PostgreSQL. The risky behaviour in this system lives in SQL and in transaction boundaries. Tests against a mocked database prove the mock works. Testcontainers with a real database was a non-negotiable in the testing doctrine.
Manual deployment gates. CI runs on every change; promotion to production is a human decision with a human who has read the diff.
AI and agent usage
AI appears in this project twice, and conflating the two is the most common way to misunderstand it.
As the delivery model. The development loop is: I research the domain problem until I can state the required behaviour precisely; I write the requirement and its acceptance criteria; I direct coding agents through implementation; I review the result adversarially — including asking a second agent to argue against the first — and I validate the behaviour in production. Agents generated most of the Go, TypeScript, SQL, frontend and test code in this codebase. The specification, the acceptance standard, the review and the shipping decision are mine. The practical lesson is that this model’s bottleneck is specification quality: agents are extremely fast at producing something and completely indifferent to whether it is the thing you needed.
As product capability inside the platform. Partner Chat gives external partners an assistant that can perform real production actions under a confirmation and permission model, and the internal operator MCP exposes roughly 120 typed tools over the same production data. Both are covered in the agentic AI case study, and the operating layer built on top of them in DCE-Ops.
Safety, reliability, and operational controls
The reliability posture is the part of this project I am most willing to be interrogated about, because it is where the AI-native model is most often assumed to be weak.
- 16,212 Top-level Go test functions Authored by coding agents under a testing doctrine David defined; he did not hand-write these tests.
- 2,971 Go test files
- 257 Vitest test files
- 28 Playwright end-to-end specs
- 181 Production alert rules
At the measured point in the repository there were 16,212 top-level Go test functions across 2,971 Go test files, 257 Vitest files, 28 Playwright end-to-end specs and 181 production alert rules. I did not hand-author those tests. I defined the doctrine that produced them: what classes of failure must be covered, that financial and routing paths require integration tests against a real database rather than mocks, that accessibility and visual regression are gated in CI rather than reviewed by eye, and that a change touching money must arrive with the test that would have caught its most plausible failure.
Observability follows the same principle — Prometheus, Grafana, Loki, OpenTelemetry and Alertmanager exist so that the questions I ask during an incident have answers that do not require a database session. The alert catalogue deliberately includes economic conditions alongside operational ones, which is a direct consequence of the phantom-revenue incident described below.
Results
The platform is in production. At the 2026-08-10 measurement it carried 200 registered buyer and publisher organizations, 30 distinct campaign verticals, over 50 routing targets, over 70 configured buyer and publisher RTB integrations, roughly 15 first-party external integrations, 10K–13K RTB requests on an active day, a measured peak of 3,273 bids per hour, and 18 simultaneously bridged calls at peak.
Those are scale and coverage figures, and I want to be precise about what they do and do not claim. They describe a system that real organizations are configured into and that carries live auction and telephony traffic. They are not revenue figures, and I am not presenting them as market share. The registered-organization count is exactly that — organizations with configured accounts — because the alternative framings available from the same database would be flattering and misleading.
The operational result that matters more to me is that the back office of this marketplace is run by one person with an AI operations layer, at roughly nine documented engagements a week, without AI being permitted to send an invoice or move money. That is covered in DCE-Ops.
What I learned
The most dangerous defect is a plausible number. A legacy configuration on a partner integration parsed a 140-second buyer settlement term while billing used a static 10-second conversion setting. 1,185 conversions were booked; roughly 242 actually met the buyer’s term. Approximately 943 conversions were phantom, about $18,860 in booked revenue the buyer did not owe, against roughly $15,088 in publisher payout for calls the buyer would never pay for. The dashboards looked healthy the entire time — the apparent economics were positive while the real economics were a loss. The postmortem produced 15 design invariants that now shape DCE’s controls, and it is the reason economic conditions are in the alert catalogue at all.
Specification precision is the real constraint in agent-directed delivery. Every defect I have traced back to its origin in this project began as a requirement that was clear to me and ambiguous on the page. Agents do not ask the clarifying question a colleague would ask; they resolve the ambiguity silently and confidently.
Tests are most valuable as an artifact of specification, least valuable as a count. 16,212 test functions is a number I can state, not a claim I lean on. What I actually rely on is that the financial and routing paths have integration tests against a real database that encode the invariants from the postmortem.
What I would change. I would define the financial invariants before the first line of billing code rather than after the first incident, and I would require a reconciliation harness against an external source of truth from the first billing release instead of adding it once the discrepancy had a dollar value attached.