I Built a Weekend Tool That Replaced a $99/Month App

I Built a Weekend Tool That Replaced a $99/Month App

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.

The short version

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.

Photo by Mikhail Nilov on Pexels

The 5% problem

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.

What I actually built

Nothing impressive, and that's the point. The whole thing was four pieces wired together:

1. Fetch: a few API calls to the data sources, with credentials in environment variables.
2. Transform: a single function that reshaped the raw data into the report format we cared about.
3. Output: wrote the result to a shared sheet and posted a summary to a team channel.
4. Schedule: a cron job to run the whole thing every morning.

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.

The weekend, honestly

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.

Photo by Nemuel Sereti on Pexels

When to build vs. when to keep paying

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:

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.

What I'd tell you before you try it

A few hard-won notes if you want to do this:

• Audit your real usage first. If it's a narrow slice, you're a candidate. If it's broad, walk away.
• Respect the invisible work. Data cleaning, edge cases, and reliability are why the tool costs money. Budget for rebuilding those, not just the happy path.
• Use environment variables for secrets, never hardcoded keys. A weekend tool with a leaked credential isn't a savings.
• Make it boring and maintainable. The goal is something a teammate can read in five minutes, not a clever monument only you understand.
• Decide who owns it. A weekend tool with no owner becomes next year's mystery outage.

The bigger pattern: audit everything you rent

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.

The bottom line

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?

Key Takeaways

• Audit your SaaS usage to identify the 5-10% of features you actually use—most subscriptions are priced for the full platform, not your narrow workflow
• Replace simple, low-stakes workflows with a weekend script if the core need is just fetch-transform-report (e.g., API calls + cron job + shared output)
• Budget time for invisible work like data cleaning and edge cases—paid tools often handle these silently, and your script must too to avoid hidden costs
• Use environment variables for secrets, write maintainable code (not clever code), and assign an owner to avoid creating unmanaged technical debt
• Run a quarterly audit: list every recurring tool, document actual usage, and cancel/downgrade/consolidate where the gap between usage and cost is widest
• The decision framework: build when usage is narrow and low-stakes; keep paying when the tool’s value is broad, mission-critical, or includes hard-to-replicate work