SaaS operations
The SaaS cost problems worth solving before you scale
Why architecture cost is shaped by unit economics, noisy tenants, background jobs, data retention, and operational attention—not just the cloud bill.
Find the cost of one useful action
A monthly infrastructure total does not explain whether a product model works. Connect spend to product activity: an imported document, generated report, processed minute, active workspace, or other unit customers understand. Include third-party APIs, storage, background compute, and support effort.
The goal is not perfect accounting. It is early visibility into features whose marginal cost grows faster than the value or price attached to them.
Protect the shared system from noisy tenants
Multi-tenant efficiency disappears when one customer can consume every worker, database connection, or external API quota. Apply limits at the tenant level, prioritize interactive work over bulk jobs, and make expensive exports or imports observable.
Useful limits are visible. Show customers their usage, explain what happens at a boundary, and provide a deliberate route for workloads that genuinely need more capacity.
- Attach tenant and operation labels to cost-relevant metrics.
- Bound retries so failed jobs do not become infinite spend.
- Expire temporary exports and unused object versions.
- Test the economic effect of plan limits as well as the technical effect.
Retention is a product decision
Keeping everything forever raises storage, backup, restore, privacy, and investigation costs. Define retention by data category and customer promise. Archive or delete deliberately, and verify that indexes, replicas, and backups follow the intended lifecycle.
A database that is inexpensive to store can still be expensive to query, migrate, and restore. Measure operational time alongside provider invoices.
Optimize after making cost explainable
Start with tagging, per-operation measurements, budgets, and alerts. Then improve the dominant cost driver. Prematurely replacing a managed service to save a small line item can create more engineering and on-call cost than it removes.
Evidence from our work
Resource totals are more useful when tied to ownership
On a 12 GiB host running several QubixTeam services, the largest process was a bot-specific Redis instance using about 2.7 GiB of resident memory. Bot workers collectively added roughly 1.6 GiB and sustained enough CPU work to keep load average above the six available cores. The VPN API itself used about 100 MiB.
We separated the two Redis instances, capped the bot cache at 4 GiB with least-recently-used eviction, added service-level memory boundaries, and stopped the trading workload when it was not needed. Available memory rose from roughly 2.3 GiB to 7.7 GiB. The useful conclusion was ownership: optimizing the VPN API would not have addressed the host pressure.
Limit: These measurements are a point-in-time operational example, not a capacity recommendation for another workload.