The Hidden Cost of Every SaaS Tool You Add to Your Stack

A scheduling tool I’d been using told me my free trial ended in two weeks, and that I’d need to pay to keep a booking link. Their pricing page said the tier I was on was free. I don’t think anyone was being dishonest — pricing pages and billing systems drift apart at every company — but it prompted a question I’d been avoiding.

How many tools am I paying for, and what is each one actually doing?

The audit is uncomfortable

I went through the list. Scheduling. Email. Analytics. Form handling. A link shortener I’d signed up for during a trial and never cancelled. Individually all defensible, most under twenty dollars a month. Together they were a real number, and roughly a third of them existed to solve a problem I could describe in two sentences.

That last part is what stuck with me. Not “these are expensive” — they mostly aren’t. But that I’d stopped noticing the difference between a tool that does something genuinely hard and a tool that wraps something simple in a nice interface and a monthly invoice.

Scheduling turned out to be a good example of both at once.

What’s actually hard about scheduling

The naive version is a form. Someone picks a time, you get an email, done. If that’s all it were, nobody would pay for it.

What you’re really paying for:

Timezones. Not the conversion — that’s a solved problem in every language’s standard library. The hard part is that you author your availability in your own timezone and every visitor reads it in theirs, and getting that boundary wrong is invisible until someone shows up at three in the morning. Add daylight saving, which different countries start and end on different dates, and which India doesn’t observe at all, and you have a class of bug that only appears twice a year.

Not double-booking yourself. Which means reading your actual calendar, which means OAuth against a calendar provider, which means token refresh, revocation handling, and staying compatible with an API you don’t control.

The long tail. Reminders. Reschedules. Cancellations. Calendar invites that land properly in the guest’s own calendar. No-show reduction. None of it is intellectually difficult and all of it is work.

That’s a real product. If you’re taking twenty bookings a week from strangers, pay for it and don’t think about it again.

What I actually needed

I take a handful of calls a month, mostly from people who’ve already read something I wrote. I don’t need automated confirmation — I want to look at each request before it becomes a commitment.

Once I wrote that down, the problem got much smaller. No calendar sync, because I’m the one confirming and I can look at my own calendar first. No automated reminders, because at this volume I send them myself. No reschedule flow, because that’s an email.

What was left: show my availability in the visitor’s timezone, let them pick, tell me about it, don’t offer a slot twice.

That’s an afternoon. Not because I’m fast, but because it’s genuinely small once you strip away the parts you don’t need.

The part I’d have got wrong if I’d rushed

Two things, and neither is about scheduling.

The first is timezones, which I’d flagged as the risk before writing anything. The thing that made it manageable wasn’t clever code — it was noticing that India hasn’t observed daylight saving since 1945, which means my side of the conversion is a fixed offset with no seasonal edge cases at all. The visitor’s side needs no arithmetic either, because the browser already knows their zone and will render an instant correctly, DST included. The whole problem collapses if you store instants rather than wall-clock times and let each end format for itself. Most timezone bugs I’ve seen come from storing “6 PM” somewhere and trying to remember whose 6 PM it was.

The second was privacy, and I nearly missed it. The booking page needs to know which slots are taken. The obvious way is to read the bookings and filter. But bookings contain names, emails, and whatever someone typed into the notes field — and a client-side read means that data is one devtools tab away from anyone who opens the page. What the page actually needs is a list of unavailable times. Nothing else. So that’s what it reads: a separate index holding only instants and a status, with no personal data in it at all.

Nobody would have noticed for months. It would have been a genuine breach of other people’s information, sitting there because I reached for the convenient query instead of asking what the page was entitled to know.

The rule I’m using now

I’m not suggesting you build your own everything. That’s a different failure, and an expensive one — I’ve watched people spend three weeks rebuilding something they could have paid nine dollars a month for, then maintain it forever.

The question I’m asking before renewing anything:

Am I paying for the hard part, or the wrapper around the easy part?

If a tool is absorbing genuine complexity — payment compliance, deliverability, calendar sync, anything with a spec behind it — pay, gladly, and stop thinking about it. That’s the best money in software.

If the tool exists because someone put an interface on a small amount of logic, and your usage sits well inside the simple case, it’s worth an honest hour asking what you’d actually have to build.

Sometimes the answer is “more than I thought” and you renew with a clear conscience. That’s a good outcome too — you now know what you’re buying.

The unexpected benefit

The version I built does less than the tool it replaced. No calendar sync, no automatic confirmation, no reminders.

But it does exactly what I want, which is: I see every request before it becomes a commitment, and I can decline one without an awkward cancellation email. That was never a feature I could have bought. It’s a preference about how I want to work, and it only became available once I stopped treating “how scheduling works” as something decided elsewhere.

That’s the part I didn’t expect. Not the money — the money is trivial. It’s that every tool you adopt quietly imports someone else’s assumptions about how your work should run, and you usually only notice when one of those assumptions doesn’t fit.