SaaS Infrastructure Cost Modeling: How One Founder Cut Projected Growth Costs by 53%

SaaS infrastructure cost modeling is often treated as a finance exercise to postpone until after product-market fit. A recent founder post makes the opposite case: if every successful user adds more cost than your business model can absorb, growth is not yet a win—it is an expensive stress test.

In a post on r/SaaS, a builder of a local social-commerce app modeled their expected monthly infrastructure costs at 10,000 and 100,000 monthly active users (MAU). The first version of the model projected about $1,061 per month at 10,000 MAU and roughly $15,495 per month at 100,000 MAU. After several product and architecture optimizations, the projections fell to approximately $490 and $7,300, respectively—a reduction of around 53–54%.

Those numbers are estimates, not verified production invoices at 100,000 MAU, and that distinction matters. Still, the post is valuable because it identifies a pattern that applies to far more than social-commerce apps: cloud bills are frequently driven less by a single catastrophic architectural choice than by dozens of reasonable-looking defaults repeated at scale. (reddit.com)

The core lesson: scalable does not automatically mean affordable

A system can technically support ten times more users while becoming economically worse at every step. Autoscaling may add instances, managed databases may add capacity, and APIs may keep returning data. But if user activity multiplies image delivery, third-party API calls, database reads, polling requests, and data-transfer charges faster than revenue, the system is operationally scalable but commercially fragile.

That is the central insight behind this SaaS infrastructure cost modeling exercise. The founder did not report discovering one wildly overpriced vendor. Instead, they found what might be called compound usage leakage: small inefficiencies that seem harmless in isolation but interact with the core behavior of a high-engagement product.

For a local social-commerce experience, that behavior may include:

• Browsing image-heavy feeds and listing cards
• Loading map views and nearby results
• Searching businesses, places, or inventory
• Refreshing messages, orders, and activity states
• Opening seller profiles, product pages, and media galleries
• Receiving locale-specific content and interface strings

Every one of those actions can create multiple billable events. One screen load may trigger database reads, authorization checks, server-side rendering work, image transformations, cache misses, map loads, place-detail lookups, outbound bandwidth, analytics events, and background refreshes. The user sees one feed. Your billing accounts see a chain reaction.

The good news is that the optimizations described in the post are not exotic. They are mostly examples of disciplined product engineering: send fewer bytes, make fewer requests, reuse work that has already happened, defer expensive capabilities until users ask for them, and avoid retrieving records nobody can see.

What the founder changed to lower projected costs

The reported reduction came from a cluster of changes rather than a migration to a radically different stack. That is precisely why the story is useful. Founders often assume that major savings require moving clouds, replacing a database, or rewriting an application. In reality, the first 30–50% may be sitting inside request patterns and frontend defaults.

1. Responsive image variants instead of original files everywhere

The post identifies full-resolution images in cards as a major source of unnecessary cost. This is a common media-delivery trap: an application uploads a high-quality original, then serves that original in a small card, mobile feed, search result, or avatar-sized component.

The waste arrives in several forms. Users download more bytes than the display requires. CDN egress rises. Origin traffic may rise on cache misses. Decoding overly large images consumes device resources. On slower connections, the product itself can feel worse even as the infrastructure bill grows.

The better pattern is to generate and serve purposeful variants—for example, a square thumbnail for a browse grid, a medium-width image for a listing card, a larger compressed version for a product page, and the original only when the full-resolution asset is truly needed. Modern image services and CDNs can resize, crop, and convert formats dynamically, then cache the resulting variant at the edge. Google Cloud’s image optimization documentation specifically describes edge-based resizing, cropping, format conversion, and caching of transformed image variants. (docs.cloud.google.com)

This is not merely a bandwidth optimization. It reduces the cost of success in image-led products. If a popular item card is viewed 100,000 times, the difference between sending a 2 MB original and a 100 KB optimized thumbnail is not a small frontend refinement. It is roughly 190 GB less transferred across those views before accounting for cache behavior, format choice, and repeat loads.

2. Cursor pagination for feeds, chat, and orders

The founder also moved to cursor pagination for feeds, chat, and orders. This is important because unbounded lists are one of the easiest ways to make a fast prototype quietly expensive.

Offset-based pagination often looks simple: request page 1, then page 2, then page 3. But deep offsets can become progressively inefficient depending on the query plan and database. More importantly, teams frequently use offset pagination as an excuse to load far more records than the user needs. A user who sees the first dozen products does not need 300 products, their images, their seller metadata, and every related record delivered preemptively.

Cursor pagination generally starts from a stable sort field such as created_at plus a unique ID. The client asks for the next limited window after a cursor, rather than asking the database to skip an ever-growing number of prior rows. It is especially useful for chronological feeds, message threads, order histories, notifications, and audit logs.

A practical implementation should still consider product details:

1. Choose a deterministic sort order. Timestamp-only sorting can create duplicates or gaps when many records share the same timestamp; add a secondary unique field.
2. Return a small, deliberate page size. A feed card may need 20 records, not 200.
3. Fetch a lightweight projection. Do not load full descriptions, large relational graphs, or private fields for a browse surface.
4. Prefetch carefully. Fetch the next page only when scrolling behavior makes it likely to be used.
5. Preserve a path to refresh. New items appearing at the top of a feed should not cause confusing jumps or duplicate results.

The frontend can use the browser’s Intersection Observer API to load another page as a sentinel approaches the viewport. The W3C specification describes the API as an asynchronous way to observe element visibility and position, avoiding continuous polling and costly layout queries. (w3.org)

3. Removing polling where an event or user action is enough

Polling is easy to ship: every 10 seconds, call an endpoint and see if anything changed. It is also easy to underestimate. A single inactive user polling one endpoint every 10 seconds creates 8,640 requests a day. At 10,000 concurrently active or semi-active sessions, that becomes 86.4 million requests per day before counting retries, authentication, database work, cache misses, logging, and downstream calls.

Not every polling loop is bad. A low-frequency refresh for a noncritical dashboard can be a sensible trade-off. But polling is often used for chat updates, notification badges, order status, live inventory, or presence indicators when the product does not actually need second-by-second freshness for every user.

The founder’s decision to remove polling should be read as a prompt to classify every refresh loop:

• Does this surface require real-time delivery, or would refresh-on-open be enough?
• Could the server push only meaningful changes through webhooks, server-sent events, or WebSockets?
• Can the UI update optimistically after a user’s own action rather than immediately re-fetching?
• Can updates be batched or delayed while a tab is backgrounded?

Push is not free and adds operational complexity, but it avoids asking the same question repeatedly when nothing has changed. Google’s Gmail API documentation makes the broader principle explicit: server push can eliminate extra network and compute costs associated with polling resources for changes. (developers.google.com)

4. Request-scoped deduplication of server and authentication queries

Another reported win was request-scoped deduplication for server and authentication queries. This is a less visible optimization than image resizing, but it can be disproportionately valuable in modern server-rendered apps.

Consider a page containing a top navigation bar, a user menu, a permissions check, a recommendation module, a cart badge, and the main content area. If each component independently asks, “Who is the current user?” or re-fetches the same organization, permissions, or listing data, a single page view can produce repeated database and auth-provider calls.

The solution is not necessarily a huge global cache. Global caches introduce invalidation, privacy, and tenancy concerns. Request-scoped deduplication is simpler: within one incoming request or rendering pass, fetch a given resource once, share the result among the components that need it, and ensure identical work is not repeated.

This has several benefits beyond cost:

• Lower database and auth-provider load
• Faster server-side render time
• Fewer opportunities for inconsistent page state
• Simpler observability because one user action maps to fewer redundant spans
• More predictable behavior during traffic spikes

It also creates a valuable engineering habit: treat each network call as an intentional product decision, not as an invisible implementation detail.

5. Lazy-loading Google Places and reducing repeated nearby discovery

Location-aware products have a special cost profile because map and place functionality is often billed by usage event, SKU, or request class rather than by a flat monthly server price. Google Maps Platform uses a pay-as-you-go model tied to billable events for individual services, and its pricing varies by SKU and usage tier. (developers.google.com)

That makes a “load everything on page open” approach risky. Loading a map, autocomplete, place search, place details, routes, and nearby recommendations together may feel convenient during development, but it can turn an ordinary browse session into several paid interactions.

The founder’s choice to lazy-load Google Places is a strong example of aligning API usage with user intent. A visitor reading a product feed may not need place data until they tap a location field, choose delivery radius, open a map, or begin a search. Deferring the capability until that moment reduces calls from users who never use it.

Reducing repeated nearby discovery matters for the same reason. If the app recalculates local recommendations on every render, tab focus, filter adjustment, or tiny location change, the product is paying for repeated work without improving the experience proportionally. A better design may cache results for a short, context-appropriate period, reuse a session’s recent location state, require a meaningful movement threshold before refreshing, and only request richer place details for results the user actually opens.

The lesson extends beyond maps. Any metered enrichment API—AI inference, address verification, fraud scoring, product search, video processing, translation, or email validation—should be placed behind an explicit intent boundary. If you need to validate addresses or contacts in a signup or checkout flow, consider exposing it only at the appropriate point in the workflow rather than enriching every record preemptively.

Why the cost drop matters more than the headline percentage

A 53% reduction sounds impressive, but the business consequences are more important than the percentage itself. The founder’s modeled 100,000-MAU monthly cost dropped from about $15,495 to about $7,300—roughly $8,195 less each month, or approximately $98,340 per year if those assumptions held steady.

That difference can alter a company’s strategic options. It may extend runway, lower the revenue threshold needed to support acquisition, make a freemium plan viable, reduce the minimum viable take rate in a marketplace, or allow the team to invest in reliability and support rather than paying for avoidable requests.

For example, imagine a local marketplace earning an average of $0.12 per monthly active user through a mixture of ads, commissions, promoted listings, or subscriptions. At 100,000 MAU, that is $12,000 in monthly revenue. Under the original projected infrastructure cost, the company would be underwater on infrastructure alone before payroll, payment processing, customer support, refunds, taxes, sales, and marketing. Under the optimized projection, the product still needs a robust business model, but it has a much more plausible path to positive contribution margin.

This is why unit economics should not wait for a finance hire. The relevant question is not simply, “Can we get to 100,000 users?” It is, “What does an incremental active user cost us, what does that user contribute, and which product behaviors make that cost rise?”

A practical SaaS infrastructure cost modeling framework

The founder says the next step is replacing assumptions with production data. That is exactly right. A model is most useful when it starts as a hypothesis, then becomes a regularly updated operating tool.

Start with user actions, not vendor categories

Many teams begin with a vendor spreadsheet: database, CDN, compute, storage, auth, maps, observability. That is necessary, but it is not sufficient because it obscures what users actually do.

Instead, model costs from a small set of product actions:

This action-level view lets you calculate a blended cost per active user and a cost per key workflow. It also exposes an essential distinction: a passive reader, an engaged browser, a seller, and a buyer can have radically different infrastructure footprints.

Use ranges, not falsely precise forecasts

A model that says your 100,000-MAU bill will be exactly $7,300.14 is not more credible than one that says it is likely to land between $6,500 and $9,500 under stated assumptions. The apparent precision hides uncertainty around engagement, geography, image sizes, cache hit rates, error rates, vendor tiers, and feature adoption.

Build at least three scenarios:

1. Conservative usage: lower session frequency, stronger caching, limited adoption of expensive features.
2. Base case: expected engagement and product mix.
3. High-intent case: heavy browsing, many media views, map usage, messaging, retries, and feature adoption.

Counterintuitively, the high-intent scenario can be financially more important than a traffic-only upside case. Your best customers may be the most expensive customers to serve. That is acceptable only if their revenue contribution grows faster than their cost footprint.

Separate fixed, semi-variable, and variable spend

A helpful model divides monthly spend into three categories:

• Fixed costs: baseline monitoring plans, reserved infrastructure, minimum platform fees, domains, and tooling subscriptions.
• Semi-variable costs: database capacity, search clusters, and compute tiers that rise in steps rather than with every request.
• Variable costs: API calls, egress, image transformations, emails, AI tokens, event volume, storage operations, and per-user authentication charges.

This distinction tells you which optimizations matter now. At very low traffic, a cheaper paid plan may save more than a complicated cache. At high traffic, reducing per-session media bytes or third-party calls can overwhelm every small subscription optimization.

The hidden multiplier: engagement is not the same as MAU

MAU is useful for communicating scale, but it is a weak predictor of cost on its own. Two products with 100,000 MAU can have dramatically different bills.

One may have users who visit once a month, read a small static dashboard, and generate very few writes. Another may have users who scroll rich media feeds every day, run nearby searches, message sellers, upload listings, receive notifications, and repeatedly refresh live inventory. Calling both products “100,000 MAU” tells you almost nothing about their infrastructure economics.

A better model includes behavioral multipliers:

• Sessions per MAU per month
• Feed pages viewed per session
• Images loaded per page
• Average bytes per delivered image variant
• Search or map interactions per session
• Messages, orders, and notifications per active user
• Cache-hit rate by route and asset type
• Percentage of sessions using premium third-party APIs
• Database reads and writes per core action

These measures help avoid a common founder mistake: optimizing the average request while missing the expensive tail. Perhaps 5% of users generate half of all map requests, or a small seller cohort uploads huge media files, or a retry bug makes failed mobile clients hit the same endpoint repeatedly. The average hides the thing that needs fixing.

How to instrument the model with production data

The original poster correctly notes that assumptions must eventually be replaced by real usage. The transition should happen earlier than many teams think—even at a few hundred active users.

Track cost-adjacent metrics before the invoice arrives

Cloud invoices are usually delayed and aggregated. By the time a monthly bill reveals a problem, the implementation that caused it may be weeks old. Instrument proxy metrics inside the product:

• Image bytes delivered by route, variant, and device class
• Requests per user session and per screen
• Database queries per endpoint and per server-rendered page
• Duplicate fetches within a request lifecycle
• External API calls by feature flag and user action
• Cache hit ratio for APIs and media
• Poll frequency, active connections, and notification fan-out
• Queue jobs produced per order, message, or content upload
• Error and retry counts by client version

Then attach those metrics to releases. If a new discovery feature increases place searches by 40%, the team should be able to see that relationship in the same week—not infer it from a bill at the end of the month.

Create budgets and alerts around units, not just dollars

A billing alert at $1,000 is necessary but reactive. More actionable alerts include thresholds such as:

• More than 1.5 Places requests per browse session
• More than 10 database queries for a listing-card render
• More than 500 KB of images transferred for a first feed viewport
• Cache-hit rate below 80% on a high-volume endpoint
• A 20% week-over-week increase in auth-provider calls per MAU

These are engineering guardrails. They connect a measurable technical behavior to a future financial outcome.

Cloud providers also offer cost-management tools, budgets, and usage reporting, but those work best when product telemetry identifies the feature and release responsible for the spend. Google Cloud, for example, documents cost and usage management resources alongside its broader cost-optimization guidance. (docs.cloud.google.com)

Do not optimize blindly: preserve experience and reliability

Cost cutting can easily become product degradation if it is approached as “make every request cheaper.” The goal is to eliminate waste, not to make a local social-commerce experience feel broken, stale, or low quality.

Responsive images should not become blurry product photos. Lazy-loading should not produce empty screens as users scroll. Caching nearby results should not show people a business 30 miles away after they have moved. Reducing polling should not leave buyers unaware that an order status changed. Deduplicating queries should not accidentally reuse data across tenants or users.

A sound optimization process uses explicit product guardrails:

1. Define the user-visible metric that must not regress, such as page-load time, search success, listing conversion, message-delivery latency, or checkout completion.
2. Ship the optimization behind measurement or a feature flag when possible.
3. Compare before-and-after behavior by device, geography, connection type, and user cohort.
4. Keep correctness, privacy, and authorization boundaries intact.
5. Retain a rollback path.

This is also where founders should be skeptical of simplistic “replace vendor X” advice. A lower unit price is meaningless if the alternative worsens coverage, reliability, developer productivity, compliance, or conversion. Cost per request is one variable in total cost of ownership.

When to optimize before adding features

The r/SaaS post is notable because the founder spent several iterations on efficiency instead of building more features. That can feel uncomfortable in startup culture, where feature velocity is often treated as progress. Yet infrastructure cost work can be feature work when it improves load time, mobile usability, reliability, and pricing flexibility.

There are three moments when this kind of optimization deserves priority:

Before paid acquisition or a launch campaign

Do not pay to acquire users into a product that sends oversized assets, makes redundant third-party calls, or refreshes inactive screens continuously. Marketing can amplify a weak cost structure faster than engineering can fix it.

Before launching a high-cost capability broadly

Maps, generative AI, high-resolution media, transcription, enrichment, live collaboration, and complex search can each create a new variable-cost curve. Prototype the feature, but gate it, measure it, and model the high-engagement cohort before treating it as universal.

When gross margin is unclear

If you cannot explain the approximate infrastructure cost of a typical active customer, power user, seller, or transaction, you are operating with a blind spot. You do not need perfect attribution; you need enough directional accuracy to recognize whether increased usage helps or hurts the business.

A founder checklist for affordable growth

Use this checklist before treating traffic growth as an unqualified success:

• Model costs at your next two meaningful milestones, not only at current usage.
• Build from user actions and engagement assumptions rather than a generic “per MAU” number.
• Audit every image surface for dimensions, quality, format, caching, and lazy loading.
• Put strict limits on feed, chat, notification, and order-history queries.
• Eliminate duplicate server-side data fetching within a request.
• Identify polling loops, their interval, their active-user count, and whether they are truly necessary.
• Delay metered API calls until the user demonstrates intent.
• Cache safely with explicit expiry and invalidation rules.
• Add observability for calls, bytes, cache misses, retries, and external API use by feature.
• Compare incremental user revenue with incremental user cost by cohort.
• Test optimizations against conversion, correctness, latency, and reliability—not only the cloud bill.

The objective is not to build the cheapest possible application. It is to build an application whose cost curve stays compatible with the value it creates.

Conclusion: model the cost of being right

The strongest takeaway from this founder’s analysis is that successful usage is a technical and financial event. A product can be popular, fast, and feature-rich while still carrying a cost structure that makes scale painful.

The reported reduction from roughly $15,495 to $7,300 per month at 100,000 modeled MAU did not come from one heroic infrastructure rewrite. It came from making the product behave more intentionally: appropriate image sizes, bounded data retrieval, fewer needless refreshes, less duplicated backend work, and more disciplined use of metered location services. (reddit.com)

For founders, marketers, and product teams, that creates a useful operating principle: before chasing the next growth channel, calculate what a successful campaign will make each part of your stack do. Then make sure the business can afford the answer.

FAQ

What is SaaS infrastructure cost modeling?

SaaS infrastructure cost modeling is the practice of estimating how hosting, databases, bandwidth, third-party APIs, storage, authentication, observability, and other technical costs change as product usage grows. A useful model links costs to real user actions, such as feed browsing, searches, uploads, messages, and orders.

Why is MAU alone a poor infrastructure-cost metric?

MAU does not capture engagement intensity. Two products with the same MAU can have very different costs depending on sessions per user, images viewed, API calls, messages sent, data transferred, and cache efficiency. Model behavioral metrics alongside MAU.

How can responsive images reduce SaaS costs?

Responsive images reduce unnecessary image bytes by serving dimensions and formats appropriate to the screen and component. That can reduce CDN egress, origin load, page weight, and mobile load time, especially in feed-based or marketplace products.

Is polling always a bad architecture choice?

No. Polling can be simple and appropriate for low-frequency, noncritical updates. It becomes costly when many active or backgrounded clients repeatedly ask for changes that rarely occur. Evaluate refresh frequency, real-time requirements, and whether events or user-triggered refreshes would be more efficient.

When should a startup start modeling infrastructure costs?

Start before a major launch, before paid acquisition, or before enabling a metered feature broadly. Even an early model based on reasonable assumptions can reveal whether a seemingly small product decision creates an unsustainable per-user cost curve.