Built for operators
who need it at midnight.
Built for operators who need to know it’ll be there at midnight on April 14th. A .NET Core multi-tenant backend across six live API services, run for the April crush and audit-logged top to bottom — in production since 2022.
Multi-tenant topology
99.8%The numbers, and why they hold up.
Proven across 50+ offices — not a pilot. Each of these is a load-bearing claim about how the platform behaves when every office is filing at once. Here’s what each one buys you.
6
Live API services
Filing, submission, banking, and billing run as separate live instances, so a spike in one never starves the others — and one can fail without taking the season down with it.
50+
Tax offices, hard-isolated
Every office runs as its own tenant with hard data boundaries. A busy office can never see, touch, or slow another — isolation is enforced in the data layer, not promised in a policy.
30,000+
Returns accepted, in production
This is not a pre-launch promise. The same stack has carried real returns through live April nights at a 98% IRS acceptance rate — proven at scale, not projected to it.
98%
IRS acceptance rate
Returns clear the IRS on the first pass 98% of the time because validation is deterministic before submission — fewer rejects to chase the week the deadline lands.
What it runs on.
The infrastructure behind six live API services and a 98% IRS acceptance rate — described plainly, because operators deserve specifics, not adjectives.
.NET Core services
The backend runs on .NET Core — a long-term-support runtime chosen for performance and stability under the kind of load a tax deadline generates.
Multi-tenant by design
Every office is an isolated tenant on shared infrastructure. One codebase, one operations team, hard data boundaries between every customer.
Six live API services
Core capabilities run as six dedicated API services, so filing, submission, banking, and billing can scale and fail independently of one another.
Promoted, not pushed
Changes flow through staged environments before they touch production. Nothing ships to a live office without clearing the path ahead of it.
Built for the crush
The platform is engineered and operated for the busiest hours of the year — because the April filing window is the one window you cannot afford to be down.
Audit-logged throughout
Operations are logged across the stack. When you need to know what happened and when, the answer is recorded, not reconstructed.
The test isn’t a quiet Tuesday. It’s April 14th.
Any platform looks fine when nobody’s filing. The one that matters is whether it holds when every office is submitting at once and the deadline is hours away. This infrastructure has carried 30,000+ accepted returns through those nights — multi-tenant, redundant, and logged — and it’s built to run the next one.
Security, reliability & control
Built to be interrogated.
Tax data is the most sensitive data an office holds. Here is exactly how it’s isolated, encrypted, recorded, and recovered — described in terms an engineer can check, operated to SOC 2-aligned practices.
Multi-tenant isolation
Every office is its own tenant with hard data boundaries enforced in the data layer. Queries are tenant-scoped by default, so one office physically cannot read or write another’s returns, clients, or ledgers.
Encrypted in transit and at rest
Traffic moves over TLS; stored data — returns, taxpayer PII, banking detail — is encrypted at rest. The sensitive fields a tax office handles are never sitting in the clear.
Every request audit-logged
Each meaningful action is written to an audit trail with who, what, and when. When you need to answer a question about a return or an access, the record is retrieved — not reconstructed from memory.
Scoped, gated access
Production access is least-privilege and deliberate. Who can touch what is a granted decision, not a default — operated to SOC 2-aligned practices across access, change, and monitoring.
Separate, staged environments
Development, staging, and production are distinct environments with their own data. Changes are promoted only after proving out upstream — production never receives an untested change mid-season.
Monitored and alerted
Service health, error rates, and submission throughput are watched continuously. When something drifts, the on-call path is paged — the goal is to know before an office does, not after.
Automated backups and recovery
Data is backed up automatically with tested recovery, so a return in progress is never one bad moment from gone. Recovery is a runbook, not a scramble.
Sized for the April crush
Capacity is provisioned and load-tested against the busiest hours of the year, when every office submits at once. The platform is built to hold at peak, because peak is the only test that counts.
You stay in control of the record. Every access and change is scoped, logged, and reviewable, and the data boundary between your office and every other is enforced — not assumed. When a client, an auditor, or the IRS asks what happened, the answer is already written down.
What it means for you
The same backbone, your scale.
Multi-tenant isolation, independent API services, and a promotion pipeline aren’t infrastructure trivia — they’re why the platform holds whether you file a hundred returns or a hundred thousand.
Single preparer
You get redundant, monitored uptime without running a server. The same .NET Core backend that carries 50+ offices carries yours — there at midnight on the 14th.
Multi-office ERO
Every location is an isolated tenant on shared infrastructure, so a busy office never degrades another. Six live API services let filing, banking, and billing scale and fail independently.
Service bureau
Changes are promoted through staged environments before they touch a live office, so a release never surprises your sub-offices mid-season. Operations are audit-logged across the stack.
Infrastructure you can
stop worrying about.
Run your season on a platform built to be there when it counts. We’ll walk you through how it’s architected, operated, and kept up during the hours that matter most.