We were paying $99 a month for an app we used about 5% of.
Ninety-five percent of its features were bloat we never touched. The 5% we actually needed was a single workflow: pull data from a few sources, transform it, and drop a report somewhere the team could see it. That was it. That was the whole thing we were renting a Ferrari to do.
One weekend I decided to find out if I could just build the 5%. By Sunday night the subscription was cancelled. Here's the scrappy build, and the lesson that's saved us a lot more than $99 since.
A huge number of SaaS subscriptions are paying for a platform when you only need a script. If your real usage is one simple workflow, you can often replace the tool with a weekend of glue code and a bit of automation.
The build was unglamorous: a few API calls, a transform step, a scheduled job, and a place to put the output. No fancy architecture. It runs on a cron and costs me almost nothing.
The point isn't that I'm clever. It's that the gap between "$99/month tool" and "a hundred lines of code" is often smaller than the pricing page wants you to believe.
Here's the thing about most paid tools: you buy them for one feature and pay for ninety.
Our app did dashboards, alerting, collaboration, integrations, an entire kitchen sink. We used exactly one path through it: fetch, transform, report. Every month we paid for the kitchen and used the toaster.
This is incredibly common, and it's how SaaS pricing works on purpose. You're priced for the platform, not your usage. When your real need is a narrow slice, that slice is often trivial to rebuild — and the rest is just margin you're funding. Wiring up a few API calls cleanly is mostly a matter of reading the docs carefully, and references like the MDN Web Docs cover the fetch-and-transform basics this kind of glue code depends on.
The first question I asked wasn't "can I build this?" It was "what do we actually use?" The answer was small enough to fit on a sticky note. That's the signal that a weekend tool might win.
Nothing impressive, and that's the point. The whole thing was four pieces wired together:
The core looked roughly like this:
async function run() {
const raw = await Promise.all(sources.map(fetchSource));
const report = transform(raw);
await writeToSheet(report);
await postSummary(report);
}
That's the shape of it. The $99 app's one useful workflow, in a function I could read top to bottom. The automation — the part that made it feel like a product — was just the cron trigger doing the same thing every morning while I slept.
Most "we need a tool for this" problems are really "we need a script for this" problems wearing a subscription.
It wasn't all smooth. Saturday morning I burned two hours on auth for one of the data sources, because their docs were wrong and the token format wasn't what the examples showed. Classic. Getting unstuck there came down to the debugging method I now use on everything — form a testable guess, then narrow down instead of flailing.
Saturday afternoon the transform was fiddly — the source data was messier than the polished app had let me see. The paid tool had been quietly cleaning data I didn't know was dirty. That's a real thing you're paying for, and worth respecting.
By Sunday it worked end to end. Sunday evening I let it run on the cron, watched the report land in the shared sheet, and the summary appear in the channel. Then I opened the billing page and cancelled. That click felt very good.
I'm not telling you to cancel everything and rebuild it. Sometimes the tool is genuinely worth it. The honest decision comes down to a few questions:
| Build the weekend tool when… | Keep paying when… |
|---|---|
| You use 5–10% of the product | You use most of its features |
| Your workflow is one clear path | You need many workflows |
| The data is reasonably clean | The tool's real value is data cleaning |
| You can maintain it | Nobody will own the code |
| Downtime is low-stakes | It's mission-critical and needs support |
The trap on both sides is real. Build when you shouldn't and you've created an unmaintained liability. Keep paying when you shouldn't and you're funding ninety features for one. The skill is telling which situation you're in — and "what do we actually use?" answers it faster than any spreadsheet. Knowing when not to build is the same restraint that, over time, becomes what people actually mean by a senior developer.
A few hard-won notes if you want to do this:
Cancelling one subscription was satisfying. But the real value of that weekend was the habit it started, and the habit has paid off far more than the original $99.
After that build, I did something I'd never bothered to do: I listed every recurring tool we paid for and wrote down, honestly, what we actually used each one for. The list was uncomfortable. There was a tool we'd onboarded for a project that ended a year ago and never cancelled. There were two tools whose jobs overlapped almost completely. There was a "team plan" sized for a team twice as large as ours. And there were a few where, like the $99 app, we used a sliver of a sprawling product.
Not all of them were candidates for a weekend tool. Some were genuinely worth every dollar — the ones we used broadly, the ones that did invisible hard work, the ones where downtime would hurt. But several weren't, and naming them was the whole point. A couple we cancelled outright because we'd stopped using them. One we downgraded to a smaller plan. Two we consolidated into one. And one more became a weekend project like the first.
The lesson generalized into a rule I now run quarterly: for every recurring tool, ask what you actually use, and whether that sliver is a platform or a script. Most software pricing is built on the assumption that nobody audits this — that subscriptions are sticky and forgettable, and that the gap between your usage and your bill is invisible. A developer's superpower is that the gap isn't invisible to us. We can read the pricing page and see the script hiding inside the platform. You don't have to rebuild everything. You just have to look, honestly, at what you're renting versus what you're using — and occasionally, on a slow weekend, close the gap yourself.
If you like this kind of scrappy, build-vs-buy thinking, it's a recurring theme in what I write — try the audit on one tool before your next renewal and see what the honest answer turns up.
Q: Isn't a paid tool more reliable than my weekend script? Often, yes — that's part of what you pay for. The trade is worth it when your workflow is simple and low-stakes. For something mission-critical, the SLA you're buying is real value.
Q: What if my needs grow later? Then you re-evaluate. A weekend tool is cheap to throw away. If your needs outgrow it, that's a good problem and you can always go back to a platform. Start small; scale when reality demands it.
Q: How do I justify the build time vs. the subscription? Multiply the monthly cost by twelve, then by however many years you'd keep it. A $99/month app is over a thousand dollars a year. A weekend often clears that bar on day one.
Q: What's the most common mistake? Underestimating the invisible work the paid tool was doing — usually data cleaning and edge-case handling. Build a prototype, run it against real data, and find the mess before you cancel anything.
I replaced a $99/month app with a function I can read in one sitting, because we only ever needed 5% of what we were renting.
The gap between a SaaS subscription and a script is often just one honest question: what do we actually use? When the answer fits on a sticky note, a weekend of glue code and a little automation can win.
Before your next renewal, pull up the tool and ask which features you actually touch. If the list is short, your weekend just found a project. What subscription would you cancel if the build were easy?
One person, output that looks like five. It isn't about working more hours — it's about a kind of leverage teams rarely have.
One idea a week to a published issue in under an hour. The boring system behind a newsletter I never dread sending.
Behind a lot of lean, profitable companies is the same small stack of AI tools. Here's what's actually running the show.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!