DEV Community: Chinecherem Mba

Your Cloud Credits Are Hiding Your Next Burn Rate

Chinecherem Mba — Mon, 12 Oct 2026 11:51:41 +0000

Your startup used $2,000 of cloud infrastructure last month.

The amount payable was zero.

Both numbers are correct. They answer different questions.

One tells you what the system costs to operate. The other tells you how much of that cost the business must fund.

Cloud credits give startups room to build. They reduce the initial cash required to launch a product, test an architecture or serve early customers. But they can also obscure a growing funding requirement when leadership focuses only on what leaves the bank account.

A workload does not become inexpensive because promotional credits cover the invoice.

The question is not just how many credits remain in your billing console. It is how much cash the business will require when those credits stop covering the workload.

The bill has three numbers

A useful cloud cost report separates the cost before promotional credits, the credits applied and the amount payable.

Measure	What it tells you
Cost before promotional credits	What the workload costs at applicable prices, including relevant pricing discounts
Promotional credits applied	How much of that cost the credit award covers
Amount payable	The remaining amount the company must fund according to its payment terms

For a simplified invoice without taxes or other adjustments:

Amount payable = cost before promotional credits − credits applied

A $2,000 workload offset by $2,000 in credits produces an amount payable of zero. The workload still costs $2,000.

That distinction matters when a founder calculates burn, when engineering evaluates database tiers, and when finance models the next two quarters.

If pricing discounts apply, include them in the baseline. The objective is to understand workload cost without promotional support, not inflate it by using undiscounted list prices.

Payment timing also matters. An amount payable on an invoice does not necessarily leave the bank account immediately.

The eligibility and expiry trap

Credits do not behave like cash.

Their usefulness depends on the charges they cover, the period in which they can be used and any limits attached to the award.

Three things can expose the business to payments:

Exhaustion: Eligible charges consume the available balance.
Expiry: The award ends while some credits remain unused.
Coverage restrictions: Certain charges are not covered, or are only partly covered.

AWS’s promotional credit terms specify eligible charges, exclusions and expiry treatment. Google Cloud’s startup programme terms also restrict credits to qualifying usage and leave customers responsible for uncovered charges.

Do not assume that one programme’s rules apply to another. Check the specific award, including its effective date, expiry date, applicable services and coverage limits.

Billing-cycle treatment matters too. AWS’s current general terms allow redeemed credits to cover eligible charges incurred during the billing cycle in which they expire.

“$12,000 remaining” is therefore incomplete information. The business also needs a timeline showing how that balance can be used.

What $12,000 in credits actually buys

Consider a startup with:

$12,000 in promotional credits available at the start of Month 1.
A $2,000 cloud workload in Month 1.
Full coverage of all modelled charges through the end of Month 4, subject to the remaining balance.
Any unused credits expiring after Month 4.
No additional credit awards.

We will compare flat spending with cost growing by 50% each month.

All figures are synthetic. The growth rate is a stress test, not a forecast. It describes infrastructure cost growth, which does not necessarily equal customer or traffic growth.

Taxes, payment fees and ineligible charges are excluded. For simplicity, the model assumes charges are paid in the same month they are incurred.

Scenario A: Flat spending

Month	Cost before credits	Credits applied	Amount payable	Unused credits expired
1	$2,000	$2,000	$0	$0
2	$2,000	$2,000	$0	$0
3	$2,000	$2,000	$0	$0
4	$2,000	$2,000	$0	$4,000
5	$2,000	$0	$2,000	$0
6	$2,000	$0	$2,000	$0

By the end of Month 4, the startup has used $8,000 of its award. The remaining $4,000 expires.

Month 5 is the first month with an uncovered charge.

Dividing the initial $12,000 balance by the $2,000 monthly cost suggests six months of coverage. The expiry rule reduces credit coverage to four months.

The workload does not become more expensive in Month 5. The business becomes responsible for paying for it.

Scenario B: Cost grows 50% each month

Month	Cost before credits	Credits applied	Amount payable	Remaining credit balance
1	$2,000.00	$2,000.00	$0.00	$10,000.00
2	$3,000.00	$3,000.00	$0.00	$7,000.00
3	$4,500.00	$4,500.00	$0.00	$2,500.00
4	$6,750.00	$2,500.00	$4,250.00	$0.00
5	$10,125.00	$0.00	$10,125.00	$0.00
6	$15,187.50	$0.00	$15,187.50	$0.00

The credit balance runs out during Month 4. Monthly totals do not establish the exact day.

The first uncovered charge is $4,250. By Month 5, the business must fund the full $10,125.

Across six months, Scenario B incurs $41,562.50 in infrastructure costs before credits. After applying the $12,000 award, the amount payable is $29,562.50.

Scenario A incurs $12,000 before credits and requires $4,000 in payments. Only $8,000 of its award is used before expiry.

The same starting credit balance produces different funding requirements.

The first uncovered month is only the beginning

A forecast that says “credits end in Month 4” leaves out the size of the transition.

In Scenario B, credits still cover part of Month 4. Month 5 receives no promotional coverage. The cost continues growing in Month 6.

A useful forecast identifies:

The first month with any uncovered charges.
The first month with no promotional coverage.
The amounts payable in the following months.
When those payments are expected to leave the bank account.

Those details give a team time to prepare for more than the first uncovered invoice.

Zero payment does not mean zero cost per customer

Suppose the startup serves 1,000 active customers in Month 1.

Its $2,000 cloud cost represents $2 per active customer. Because credits cover the bill, its cloud amount payable per customer is zero.

Both measures are useful:

Measure	Month 1 result	Purpose
Cloud cost per customer before promotional credits	$2.00	Assess the infrastructure cost of serving customers without promotional support
Cloud amount payable per customer	$0.00	Understand current funding requirements

Neither measure establishes the product’s gross margin. Payment processing, support and other delivery costs may still apply.

For a $5 monthly subscription, a $2 cloud cost consumes 40% of subscription revenue before considering those other costs. Credits can reduce the current cloud payment, but they do not establish that the product will remain profitable after coverage ends.

The denominator also needs care. Use a consistent definition of an active customer or completed transaction. Allocate shared infrastructure costs before comparing products.

Rising total spending does not automatically mean worsening efficiency. If customer growth outpaces cloud cost growth, average cost per customer may improve.

Reproduce the transition in Python

The following model uses Python’s standard library to reproduce both scenarios.

It records costs, credits applied, amounts payable, expired credits and the remaining balance. It also prints the first uncovered month.

from decimal import Decimal, ROUND_HALF_UP

ZERO = Decimal("0.00")
CENT = Decimal("0.01")


def forecast_credits(
    starting_cost: Decimal,
    growth_rate: Decimal,
    credit_balance: Decimal,
    expiry_month: int,
):
    cost = starting_cost
    balance = credit_balance
    results = []

    for month in range(1, 7):
        # All modelled charges qualify while the award is valid.
        applied = (
            min(cost, balance)
            if month <= expiry_month
            else ZERO
        )

        payable = cost - applied
        balance -= applied

        # Unused credits expire after this month's coverage.
        expired = balance if month == expiry_month else ZERO
        balance -= expired

        results.append({
            "month": month,
            "cost_before_credits": cost,
            "credits_applied": applied,
            "payable": payable,
            "expired": expired,
            "closing_credit_balance": balance,
        })

        cost = (
            cost * (Decimal("1.00") + growth_rate)
        ).quantize(CENT, rounding=ROUND_HALF_UP)

    return results


scenarios = [
    ("Flat spending", Decimal("0.00")),
    ("50% monthly cost growth", Decimal("0.50")),
]

for name, growth in scenarios:
    rows = forecast_credits(
        starting_cost=Decimal("2000.00"),
        growth_rate=growth,
        credit_balance=Decimal("12000.00"),
        expiry_month=4,
    )

    first_uncovered = next(
        (
            row["month"]
            for row in rows
            if row["payable"] > ZERO
        ),
        None,
    )

    total_payable = sum(
        (row["payable"] for row in rows),
        ZERO,
    )

    print(f"\n{name}")
    print(f"First uncovered month: {first_uncovered}")
    print(f"Six-month amount payable: ${total_payable:,.2f}")

    for row in rows:
        print(
            f"Month {row['month']}: "
            f"cost=${row['cost_before_credits']:,.2f}, "
            f"credits=${row['credits_applied']:,.2f}, "
            f"payable=${row['payable']:,.2f}, "
            f"expired=${row['expired']:,.2f}, "
            f"balance=${row['closing_credit_balance']:,.2f}"
        )

The flat scenario identifies Month 5 as the first uncovered month and produces $4,000 payable over six months.

The growth scenario identifies Month 4 as the first uncovered month and produces $29,562.50 payable.

This is a simplified, single-award model. It assumes full coverage of eligible costs until the balance runs out or the award expires. It does not implement provider-specific rules for multiple awards, partial coverage, account sharing or service restrictions.

For an operational forecaster, use a billing file and a credit ledger.

The billing file should preserve costs before promotional credits and credit adjustments separately. The ledger should record each award’s balance, validity period, eligibility and coverage limits.

Apply the provider’s allocation rules and reconcile the results against actual invoices. Do not subtract credits twice from a billing export that already includes them.

The credit transition changes company runway

Cloud coverage is not company runway.

Consider the same startup with $60,000 in starting cash and $10,000 in monthly net cash burn excluding cloud payments.

That non-cloud burn represents other cash expenses minus cash receipts. Hold it constant in both scenarios.

Closing cash = opening cash − non-cloud net cash burn − cloud payment

Month	Non-cloud net cash burn	Scenario A: projected closing cash	Scenario B: projected closing cash
1	$10,000	$50,000	$50,000
2	$10,000	$40,000	$40,000
3	$10,000	$30,000	$30,000
4	$10,000	$20,000	$15,750
5	$10,000	$8,000	−$4,375
6	$10,000	−$4,000	−$29,562.50

Negative figures represent cumulative funding gaps if all assumed outflows continue. They are not actual spendable bank balances or a determination of insolvency.

Under flat cloud spending, the company can fund the modelled payments through Month 5 but encounters a shortfall in Month 6.

Under 50% monthly cloud cost growth, the shortfall begins in Month 5.

Dividing current cash by current net burn gives six months:

$60,000 ÷ $10,000 = 6 months

That estimate misses the additional payments once promotional coverage ends.

The issue is that the burn rate changes over the forecast period. A month-by-month cash model makes that change visible.

A precise cash-out date would require the timing of receipts and payments within each month.

Architecture decisions made while credits cover the bill

Subsidised usage can make an expensive design feel easier to accept.

A team may provision a search cluster before measuring its requirements. It may select a database tier without examining access patterns. It may leave staging environments running because there is no immediate payment attached to them.

These choices are not automatically wrong. The question is whether their value justifies their ongoing cost.

A managed service might improve recovery, reduce operational work or help a team deliver sooner. Those benefits belong in the comparison alongside its price.

If a tool costs $1,500 per month, evaluate what the business receives for that amount and what an alternative would cost to operate. Do not assume saved engineering hours translate directly into cash savings.

Also consider reversibility. Moving a data layer, changing a service dependency or rebuilding an operational process takes time. That work becomes harder to fund if the team waits until an uncovered invoice arrives.

Review significant architecture decisions against their cost before credits and their expected cost after expiry.

Use the credit period to prepare

The period before expiry gives the team room to act.

Review idle resources, unnecessary data movement and capacity that exceeds demand. Schedule non-production environments around actual usage. Examine retention policies against retrieval costs and recovery requirements.

Before purchasing commitments, check their payment schedule and whether the award covers the relevant charges. A lower unit price is useful only if the commitment fits the workload and the company can fund it.

Keep the credit balance, cost forecast and company cash forecast in the same conversation.

Do not spend more simply to exhaust an expiring award. Unused credits are not cash that can be recovered. Additional usage should serve a business purpose and come with a plan for any continuing costs.

When the credits stop paying

Cloud credits can fund experiments and reduce early cash pressure. They can give a startup time to learn what customers need and how to deliver it.

That advantage is more valuable when the business understands the cost of continuing after the support ends.

This is the question Runway Architect keeps returning to:

When the credits stop paying, can the business afford the system it has built?

The best time to answer is while the credits are still covering the bill.

The Cloud Bill Stayed Flat. The Naira Cost Did Not

Chinecherem Mba — Sat, 10 Oct 2026 01:40:57 +0000

Your startup can spend the same $1,000 on cloud infrastructure every month and still lose months of runway.

No new servers. No increase in traffic. No change in the provider’s prices.

The exchange rate moves. The same infrastructure takes more naira to keep running.

For a business earning in naira and paying for cloud services in dollars, a flat dollar bill tells only part of the story.

The cost of standing still

Consider a startup with a $1,000 monthly cloud bill.

Exchange rate	Dollar bill	Naira needed
₦1,200/$	$1,000	₦1,200,000
₦1,500/$	$1,000	₦1,500,000
₦1,800/$	$1,000	₦1,800,000

At ₦1,800 to the dollar, the startup needs an extra ₦600,000 each month for the same workload. Its naira cloud expense has risen by 50%.

These figures are hypothetical stress tests, not historical rates or forecasts. The table isolates currency conversion. Fees and taxes are excluded.

In an actual payment, the conversion rate may be only part of the cash outflow.

Settlement friction changes what leaves the account

A reference exchange rate does not necessarily equal the rate available through your payment provider.

The amount required to settle a dollar invoice can include a conversion spread, funding fees and processing charges. Their size and calculation depend on the payment route.

Consider this separate illustration:

Component	Assumption	Naira amount
Invoice converted at reference rate	$1,000 × ₦1,800/$	₦1,800,000
Conversion spread	5% of ₦1,800,000	₦90,000
Processing fee	1% of ₦1,800,000	₦18,000
Total settlement outflow	Sum of the three amounts	₦1,908,000

Both percentages apply independently to the original ₦1.8 million. They are illustrative assumptions, not quoted provider charges. Taxes are excluded.

The effective settlement cost is ₦1,908 per dollar of invoice value.

Keep two measures separate:

Conversion rate = naira exchanged ÷ dollars purchased

Effective settlement cost per invoice dollar = total naira settlement outflow ÷ dollar invoice value

The second measure includes the fees in this example. Do not add them again when using it to calculate total cash outflow.

Keep taxes as separate ledger entries with their basis and treatment recorded. Verify VAT, withholding and any credit eligibility for the specific invoice and entity. A combined “tax and processing” percentage hides information the forecast needs.

Use payment records to reconcile actual cash outflow. Preserve the underlying conversion rate and charges so you can explain why it differs from the reference rate.

Separate currency exposure from engineering performance

Before responding to a higher bill, identify what changed.

Driver	What to investigate
Usage	Compute hours, storage, data transfer and requests
Provider pricing	Rates, discounts and commitments
Service mix	Movement between services, regions or tiers
Currency conversion	Naira required to purchase the invoice currency
Settlement charges	Funding fees, processing charges and applicable taxes

Keep the original dollar amount alongside the naira amount.

Imagine engineering reduces the bill from $1,000 to $800. At ₦1,200/$, the original bill cost ₦1.2 million. At ₦1,800/$, the reduced bill costs ₦1.44 million, before fees and taxes.

Dollar spending fell by 20%. Naira spending rose by 20%.

The optimisation worked. Currency movement outweighed the saving.

A report showing only naira can hide engineering progress. A report showing only dollars can hide growing pressure on a naira cash balance.

Bring the cost down to one transaction

The FinOps Foundation’s unit economics framework connects technology spending with the value it creates. For a transaction-based product, cost per completed transaction makes that relationship easier to examine.

Assume our startup completes 100,000 transactions each month. The entire $1,000 cloud bill supports that service.

Cloud cost per completed transaction = allocated cloud cost ÷ completed transactions

Exchange rate	Monthly naira cloud cost	Cloud cost per completed transaction
₦1,200/$	₦1,200,000	₦12
₦1,500/$	₦1,500,000	₦15
₦1,800/$	₦1,800,000	₦18

These figures continue the currency-only example, excluding settlement fees and taxes.

Dollar cloud cost stays at $0.01 per transaction. Naira cloud cost rises from ₦12 to ₦18.

Suppose the startup earns a ₦30 fee per completed transaction. Infrastructure consumes 40% of that revenue in the first scenario and 60% in the third.

The amount remaining after cloud cost falls from ₦18 to ₦12 per transaction. That remainder still has to cover every other cost before the business can produce a profit.

It is not gross margin. This calculation subtracts only cloud cost. It also measures average cost per transaction, not the marginal cost of processing one more transaction.

Define the denominator with care. Retries and failed requests consume resources, but they are not completed business transactions. Counting them as successful outcomes makes the cost per outcome appear lower.

Where products share infrastructure, allocate the relevant costs before calculating individual unit costs.

Pricing needs a trigger for review

Fixed naira prices create margin pressure when dollar costs rise and other factors do not offset the increase.

That does not make an immediate price increase the right response. Higher prices can affect demand, retention and collections.

Three options deserve examination:

Contract reviews: For negotiated business contracts, consider agreed review intervals or adjustment clauses where commercially and legally appropriate. Specify the reference measure and review process.
Usage-based packaging: Examine whether resource-intensive features, storage or data transfer should have limits or separate charges. Compare expected savings with the effect on customers.
Review thresholds: Set a trigger for engineering, finance and product to investigate together. A rising cloud-cost-to-revenue ratio can initiate a review without automatically initiating a price increase.

The purpose is to give the business time to respond before a payment becomes difficult to fund.

Follow the currency of the cash

A startup holding naira must spend more of that balance to buy the same $1,000 when the naira-per-dollar rate rises.

A startup paying from dollar reserves still spends $1,000.

A higher naira equivalent does not automatically mean a higher dollar cash outflow.

Dollar reserves do not remove every exposure. Naira revenue buys fewer replacement dollars at the higher rate. Meanwhile, unchanged naira expenses translate into fewer dollars, which may partly offset the effect. Future local price increases could reduce that offset, but their timing and magnitude are uncertain.

Track the currencies in which the company earns, spends and holds cash.

“We raised in dollars” is insufficient if the money has already been converted to naira. The company can still face a mismatch between naira reserves and future dollar obligations.

Put the effect on runway

Keep the same startup and assume:

100,000 completed transactions per month at ₦30 each.
All ₦3 million of monthly revenue is collected in the same month.
₦4 million in other monthly cash expenses, held constant.
A $1,000 monthly cloud payment.
₦24 million in available cash, all held in naira.

The company buys dollars each month to pay for cloud services.

To isolate currency exposure, the following table and code exclude settlement fees and taxes. The earlier settlement example is separate.

Monthly net cash burn = monthly cash expenses − monthly cash receipts

Runway in months = available cash ÷ positive monthly net cash burn

Exchange-rate scenario	Total monthly cash expenses	Monthly net cash burn	Estimated runway
₦1,200/$	₦5,200,000	₦2,200,000	10.9 months
₦1,500/$	₦5,500,000	₦2,500,000	9.6 months
₦1,800/$	₦5,800,000	₦2,800,000	8.6 months
₦2,100/$	₦6,100,000	₦3,100,000	7.7 months

Between the first and fourth scenarios, estimated runway falls by about 3.2 months.

No additional cloud usage. No lost customers. The dollar bill stays flat.

This is a static sensitivity model. It assumes each rate and the monthly cash flows remain constant. It excludes growth, new funding, one-off payments and changes in collection timing. It is not a forecast of when a particular company will run out of cash.

Reproduce the calculation

This Python example uses the standard library. It varies the exchange rate while holding the workload and dollar bill constant.

from decimal import Decimal

cloud_usd = Decimal("1000")
transactions = 100_000
revenue_per_tx_ngn = Decimal("30")
cash_ngn = Decimal("24000000")
other_expenses_ngn = Decimal("4000000")

# Hypothetical conversion rates. Fees and taxes are excluded.
rates = [
    Decimal("1200"),
    Decimal("1500"),
    Decimal("1800"),
    Decimal("2100"),
]

# Assume all revenue is collected in the same month.
monthly_receipts_ngn = transactions * revenue_per_tx_ngn

for rate in rates:
    cloud_ngn = cloud_usd * rate
    unit_cost_ngn = cloud_ngn / transactions
    revenue_remaining_after_cloud_pct = (
        (revenue_per_tx_ngn - unit_cost_ngn)
        / revenue_per_tx_ngn
    ) * 100

    total_expenses_ngn = other_expenses_ngn + cloud_ngn
    net_burn_ngn = total_expenses_ngn - monthly_receipts_ngn

    runway = (
        f"{cash_ngn / net_burn_ngn:.1f} months"
        if net_burn_ngn > 0
        else "No net cash burn under these assumptions"
    )

    print(
        f"FX: NGN {rate:,.0f}/USD | "
        f"Cloud/transaction: NGN {unit_cost_ngn:.2f} | "
        f"Revenue left after cloud: "
        f"{revenue_remaining_after_cloud_pct:.1f}% | "
        f"Monthly net burn: NGN {net_burn_ngn:,.0f} | "
        f"Runway: {runway}"
    )

For an actual cash forecast, add the relevant settlement charges and tax cash flows explicitly, avoiding double counting. For mixed-currency reserves, track each balance and when conversions occur.

A discounted commitment can still become unaffordable

AWS Savings Plans and Google Cloud committed use discounts exchange commitments for lower eligible usage prices. Terms and savings depend on the product, workload and payment option.

A currency movement does not erase the discount against equivalent on-demand usage at the same exchange rate.

Suppose a fully used commitment reduces an eligible $1,000 monthly cost to $700. Then suppose the naira-per-dollar rate rises from ₦1,200 to ₦1,920, an increase of 60%.

Comparison	Monthly naira cost
Original $1,000 cost at ₦1,200/$	₦1,200,000
Discounted $700 cost at ₦1,920/$	₦1,344,000
Undiscounted $1,000 cost at ₦1,920/$	₦1,920,000

The discounted cost is 12% above the original naira cost. It is still 30% below the new undiscounted cost.

The saving remains. Affordability has changed.

The risk is committing to payments the company cannot comfortably fund or usage it may not need. Review utilisation, payment timing and cash capacity together. An upfront dollar payment and a future monthly dollar payment have different exposure to subsequent currency movements.

Evaluate hosting alternatives against the full cost

Predictable workloads can justify comparing hyperscalers with dedicated infrastructure or regional providers. That comparison should include more than the server invoice.

Account for migration work, staffing, connectivity, data transfer, backups, recovery testing, security and the cost of downtime.

A local database connected to public-cloud application services may introduce latency, network dependencies or additional transfer charges. Those effects need measurement before migration.

A naira invoice also does not guarantee stable naira prices. Examine the provider’s repricing terms and underlying currency exposure.

Hybrid infrastructure may fit a workload. It is not a guaranteed route to lower cost or equivalent reliability.

Before taking on a migration, address waste in the current environment. Review unattached disks and forgotten staging resources after confirming ownership and retention needs. Schedule non-production capacity around actual usage. Set storage lifecycle policies against retrieval costs, retention obligations and recovery targets.

Every saving should preserve the service the business needs.

Architecture must survive the business’s reality

Can the business continue to afford the technical system it depends on?

A system can meet its performance targets while the assumptions used to fund it stop working.

For a startup earning in naira and settling in dollars, currency exposure belongs in infrastructure planning. It affects the cost of serving customers, the cash needed to operate and the time available to build.

That is the connection I want Runway Architect to make visible.

Your cloud dashboard tracks what your application consumed. Your business must account for what it costs to stay alive.