DEV Community: Juan Carlos Pascual

How Much Should You Spend on Subscriptions?

Juan Carlos Pascual — Thu, 03 Sep 2026 11:58:35 +0000

Ask someone what they spend on subscriptions each month and you usually get a number that is too low. Not because they are lying — because the spending is designed to be forgettable. Small amounts, automatic payments, spread across a dozen services and two or three cards.

The honest answer to "how much should I spend" starts with "how much do I spend", and most people have never added it up.

Why the total surprises people

Monthly framing hides the real cost. "$12.99 a month" reads as small. The same service is $156 a year and $780 over five years. Your brain files the first number and ignores the other two.
Free trials that quietly converted. You meant to cancel before the trial ended. The reminder never came, or it did and you were busy.
Price creep. Streaming and software prices have risen steadily for years. What you signed up for is rarely what you pay now, and the increases arrive one email at a time.
Forgotten subscriptions. Something you used once, attached to a card you barely check.
Overlap. Three streaming services when you mostly watch one. Two cloud storage plans. A music service you also get bundled with something else.

There is no magic percentage

You will see rules of thumb — "keep subscriptions under 5% of take-home pay" and so on. They are not wrong exactly, but they are arbitrary. A freelancer whose subscriptions are all work tools has a very different picture from someone paying for five entertainment services.

A more useful test is per-subscription: does this one earn its place? For each line on your list, ask when you last used it and what you would miss if it vanished tomorrow. Anything you cannot answer confidently is a candidate to cut.

A process that works

List everything. Streaming, music, cloud storage, apps, news, gym, meal kits, memberships — and, if you want the full picture, your phone and broadband. You cannot manage what you have not seen.
Convert it all to a yearly number. A weekly charge is ×52, a quarterly one is ×4. The annual total is the one that tells the truth.
Apply a 30-day rule. If you have not used it in the last month, cancel it. You can almost always resubscribe later, and most people never do.
Switch the keepers to annual billing. For services you are sure about, annual plans are usually 15–20% cheaper than paying monthly.
Share family plans. Music and streaming family tiers cost far less per person when split with the people you live with.
Rotate instead of stacking. Keep one streaming service at a time and switch every few months rather than paying for all of them at once.

Then check it again in six months

Subscriptions grow back. New trials, a service a friend recommended, a tool you needed for one project and forgot. A twice-a-year review keeps the total honest.

Add yours up

The subscription cost calculator lets you list every subscription with how often you are billed, and shows the real total per month, per year, and over five years. Your list is saved in your own browser, so you can come back and update it. Enter your monthly income too and it shows what share of it is going to subscriptions — often the number that prompts the first cancellation.

SaaS Churn Benchmarks — What Counts as Good

Juan Carlos Pascual — Wed, 02 Sep 2026 12:33:03 +0000

Churn is the number every subscription business watches, and also the one most often quoted without saying which churn. "We're at 5%" could be a healthy month or an existential problem depending on what is being measured. Here is how the pieces fit together.

Two families: customers and revenue

Customer churn (also called logo churn) is simple: customers lost in a period ÷ customers you had at the start. If 500 customers became 475, that is 5% customer churn for the month.

Revenue churn measures money, not headcount, and it splits into two versions that tell different stories.

Gross revenue churn = (revenue lost to cancellations + revenue lost to downgrades) ÷ revenue at the start of the period. It only ever counts losses. It cannot be negative.
Net revenue churn starts from the same losses but subtracts the extra revenue from existing customers who upgraded. When upgrades outweigh losses, net revenue churn goes below zero — your existing customer base is growing on its own.

A business can have ugly gross churn and still post negative net churn if a core of customers keeps expanding. That is common in tools that grow with a customer's usage. It is also why you should always ask which number someone means.

Retention is the same idea, counted upward

Retention metrics are churn viewed from the other side.

Gross revenue retention (GRR) = the share of starting revenue you keep after downgrades and cancellations. It caps at 100%.
Net revenue retention (NRR) = GRR plus the revenue from upgrades. It can exceed 100%.

NRR above 100% is the single clearest sign of a durable business: it means that even with zero new sales, revenue would grow next year.

Rough targets

These are norms for a company selling to small and mid-sized businesses. Enterprise-focused companies run much lower churn; very early-stage companies swing wildly month to month and should look at a rolling three-month average.

Metric	Healthy	Watch	Poor
Gross revenue churn (monthly)	under 3%	3–6%	over 6%
Net revenue churn (monthly)	0% or below	0–3%	over 3%
Customer / logo churn (monthly)	under 3%	3–6%	over 6%
Net revenue retention	105%+	90–105%	under 90%
Gross revenue retention	90%+	80–90%	under 80%

A monthly churn rate compounds fast. 5% a month is not "95% retained" over a year — it is closer to 54%. Small improvements in a monthly rate are worth a lot.

Churn is downstream of a few other numbers

If churn is creeping up, the metrics around it usually explain why:

Falling ARPA (average revenue per account) alongside steady logo churn means your remaining customers are smaller — you may be losing the good ones.
A low Quick Ratio — new plus upgrade revenue divided by cancelled plus downgrade revenue — under about 2 means you are refilling a leaky bucket rather than growing.
Rising CAC payback stretches the time before a customer is profitable, so churn hurts more per lost account.

See where your numbers land

Put one month of revenue movement and customer counts into the SaaS metrics calculator. It works out gross and net churn, NRR, GRR, LTV, CAC and the Quick Ratio together, and flags each against these benchmarks — which is more useful than any single figure on its own.

How to Estimate LLM API Costs Before You Build

Juan Carlos Pascual — Tue, 01 Sep 2026 10:57:41 +0000

The good news about language model APIs is that pricing is simple on paper: you pay per token. The trap is that "per token" hides a few multipliers that decide whether a feature costs $50 a month or $5,000.

Here is how to get a defensible number before you commit.

The basic formula

Text is split into tokens — chunks of roughly three to four characters. You pay for two things:

Input tokens: your prompt, including the system instructions and any context you attach.
Output tokens: what the model generates back.

Both are usually priced per million tokens, and output is typically three to five times the input rate because generating text is more work than reading it.

cost per request = (input tokens ÷ 1,000,000 × input price)

(output tokens ÷ 1,000,000 × output price)

Multiply by how many requests you expect, and you have a monthly figure.

A rough sizing guide while you are sketching: 1,000 tokens ≈ 750 words ≈ 4,000 characters of English. Code and other languages run higher.

What a naive estimate misses

The formula above assumes one clean request per call. Production is messier:

Retries and failures. Timeouts, rate limits, malformed responses — each retry is another paid request.
Tool-calling round trips. An agent that calls three tools before answering is four full requests, each resending the growing conversation.
Thinking tokens. Extended reasoning is billed as output, and it can be several times the length of the visible answer.
Images and audio in the input, which are converted to tokens at their own rates.

Many teams budget 20% to 50% above the naive number to absorb this.

The levers that move the bill

In rough order of impact:

Model choice. Use a small, cheap model for the easy calls — classification, routing, short extractions — and a larger one only where quality visibly depends on it. This is often a 10x difference.
Output length. Cap the maximum response. A prompt that returns a 2,000-token essay when 200 words would do is overpaying on the expensive half of the bill.
Prompt caching. If every request resends the same large system prompt or document, most providers can cache it and re-read it at around 10% of the input price. For chat and agent apps this is a big saving on the input side. Discounts and any one-off write cost vary by provider.
Trim the prompt. A long, unchanging preamble is cheap once and expensive across a million calls. Shorter instructions, and only the context the task needs.
Batch what is not urgent. Many providers run non-real-time work asynchronously at around half price.

Work an example

Say a support-triage feature: 1,500 input tokens and 500 output tokens per request, 100,000 requests a month, on a mid-tier model at $2 / $10 per million tokens.

Input: 1,500 × 100,000 = 150M tokens × $2 = $300
Output: 500 × 100,000 = 50M tokens × $10 = $500
About $800 a month before retries and margin.

Now add 40% caching on the input (a fixed system prompt), and the input side drops toward $190 — a $110 saving for one config change.

Size yours

The LLM API cost calculator takes the per-million-token prices, your request volume and average tokens in and out, and returns cost per request, per 1,000 requests, per day, per month and per year, with the input and output halves broken out. It has a caching slider so you can see that lever directly. Copy the current prices from your provider's pricing page — LLM pricing changes often, so the presets are a reference point, not a quote.

How to Set Your Freelance Rate Without Guessing

Juan Carlos Pascual — Mon, 31 Aug 2026 18:01:54 +0000

Most people set their first freelance rate by taking their old salary, dividing by 2,000, and maybe rounding up. It feels reasonable. It is also how a lot of freelancers end up working harder than they did as employees for less money.

The problem is not the arithmetic. It is everything the arithmetic leaves out.

Start from what you want to keep, not from a rate

Work backwards. The number that matters is your target take-home income: the money you want left over after the business has paid for itself and you have paid your taxes. Pick a real figure. A common starting point is what a salaried job in your field would pay, because that is the bar you are choosing to leave.

Everything else is a deduction between that number and the rate you charge.

The four things that eat the gap

1. Time you cannot bill

You do not get paid for finding clients, writing proposals, sending invoices, chasing late payers, doing your books, or learning the skills that keep you hireable. You also do not get paid to redo work a client changed their mind about.

Add it up honestly and most sustainable freelancers bill 55% to 70% of the hours they work. Not 100%. If you plan a 40-hour week, 24 to 28 of those hours are billable in a good week.

2. Time off nobody pays for

An employed job quietly includes paid holidays and sick days. As a freelancer, a week off is a week with no income. Start from 52 weeks and subtract your holiday plus a buffer for illness — something like 46 working weeks is realistic.

3. Costs an employer used to absorb

Your old employer paid part of your payroll taxes, contributed to a pension, bought your laptop, covered software licences and insurance, and rented the desk you sat at. Now that is all you. Total up a realistic yearly figure for software, hardware amortised over a few years, an accountant, insurance and a workspace.

4. Tax on the profit

Whatever is left after costs is profit, and profit is taxed — income tax plus self-employment or social security contributions. The effective rate varies a lot by country and income, but 25% to 40% is a common range. Confirm yours with an accountant.

Put it together

The maths, in order:

Working hours = weeks worked × days per week × hours per day
Billable hours = working hours × your billable percentage
Revenue you need = ( target income ÷ (1 − tax rate) + yearly costs ) × (1 + a profit buffer)
Hourly rate = revenue you need ÷ billable hours

The profit buffer in step 3 — 10% to 20% — covers the gaps between contracts, the client who pays 60 days late, and money to reinvest. Without it, one slow month erases your margin.

Run these numbers and the rate almost always comes out higher than the salary-divided-by-2,000 shortcut. That is the point. The shortcut was ignoring tax and unbillable time.

Sanity checks

Watch the effective rate. Divide the revenue you need by every hour you work, not just the billable ones. That is the honest figure for what an hour of your time actually has to earn.
If the number feels uncomfortable to say out loud, that usually means your previous rate was too low, not that this one is wrong.
Quote a day rate for longer jobs. Clients anchor to it more easily than a large hourly figure.

When you are comparing against a salary

If a client offers you a permanent role, or you are weighing a contract against a job, convert both to the same basis before deciding — an hourly to salary conversion with your real hours and weeks. Remember the contract rate should sit well above the salary's hourly-equivalent to be worth it, for all the reasons above.

Then run your own situation through the freelance rate calculator and adjust the inputs until the plan holds together.

What 99.9% Uptime Actually Means

Juan Carlos Pascual — Sat, 29 Aug 2026 13:23:55 +0000

"Three nines" sounds strict. 99.9% available — surely that is basically always up? It works out to nearly nine hours of downtime a year, or about 43 minutes in a 30-day month. Whether that is fine or alarming depends entirely on what your service does.

The nines, in real time

Uptime	Name	Downtime per month	Downtime per year
99%	two nines	7h 12m	3d 15h 36m
99.9%	three nines	43m 12s	8h 45m 36s
99.99%	four nines	4m 19s	52m 34s
99.999%	five nines	26s	5m 15s

Two patterns jump out. First, the jump from 99% to 99.9% removes almost four days of yearly downtime — a big, usually worthwhile improvement. Second, every nine after that cuts the remaining budget by about 90%, and the absolute savings get smaller while the engineering effort to achieve them grows sharply.

Why each nine is so expensive

Going from 99.9% to 99.99% means your yearly outage allowance drops from nearly nine hours to under an hour. In practice that requires:

redundancy across independent failure domains, not just a spare server
automated failover that is regularly tested, not a runbook someone follows at 3am
a deploy process tight enough that releases rarely cause incidents
on-call coverage with people who can actually fix things
monitoring that catches problems in seconds, not when a customer emails

Each of those adds cost and operational complexity. Most products do not need more than three nines. Picking a target higher than your users require mostly buys you stress and a larger infrastructure bill.

SLA, SLO, and what you actually measured

SLA — the availability you promise in a contract, often with refunds or credits if you miss it.
SLO — the internal target your team works to. Set it stricter than the SLA so you have a safety margin before penalties kick in.
Actual uptime — what you measured over the period. The gap between this and your SLO is your early-warning signal.

One more contract detail: many SLAs exclude announced maintenance windows from the downtime calculation. Read the definition of "downtime" and "excluded events" before you compare your measured number to the promise.

Pick the target from the cost of being down

The right availability target is a business decision, not an engineering one. Work out what an hour of downtime actually costs you — lost revenue, staff who cannot work, recovery effort — and compare that to the cost of the next nine. If an outage costs a few hundred dollars an hour, chasing five nines makes no sense. If it costs tens of thousands, three nines is probably not enough.

Do the maths

The uptime / SLA calculator converts any availability percentage into exact downtime per day, week, month and year, and also works backwards from a measured outage to the percentage it produced. Pair it with the cost of downtime calculator to put a dollar figure on each minute — the number that tells you how much reliability is worth buying.