why I keep saying no to another subscription

Every time a new subscription comes up for one of our products, I run the same test before I say yes. Could we build the piece we actually need ourselves, on what we already have running? Most of the time, the answer is yes, and I skip the subscription.

I put the rule to myself plainly a while back. I don't want to have countless subscriptions and services that my products depend on. If it's something we could put together ourselves, I'd rather do that. That is the whole rule. It is not a rule against paying for anything. It is a default toward building first and paying only when paying is actually justified.

the test before I say yes

The test is not complicated. Before we pay for a tool, I ask whether we could build the piece we actually need ourselves, on what we already have running. If a paid service really is better, that has to be a specific reason. A real feature only that service provides, or a cost comparison that actually holds up once I do the math. It cannot just be the assumption that building sounds like more work up front, because in my experience it usually is not more work. It is just work I have to do instead of work someone else already did for me.

paying for the right things

This is not a rule against paying for anything. I already pay for plenty of tools. Payment processing. The AI model providers we build on. Hosting. The database platform itself. Any tool that does something genuinely differentiated, something we could not reasonably build ourselves, is worth paying for.

I wrote about drawing this same line for our internal documentation: pay for the things a vendor is actually better at, and build the things that are really just a generic capability charged as a subscription.

the subscription I walked away from

The clearest example of this rule in practice is a subscription I walked away from entirely. We had been using a large marketing and sales platform, HubSpot, to handle web forms, some automated emails, and a simple list of contacts. It covered a lot of ground. That was part of the problem.

When HubSpot came up again as the default option for a new form we needed, I said no. We were done paying for it, and not just for that one form. No new feature going forward would assume we still had it.

The reasoning was the same test from the top of this post. The ongoing cost and the operational weight of keeping HubSpot running did not hold up against what we were actually using it for. Forms that post to a database. Transactional email for one-off system messages. A simple internal view of who our contacts are. None of that required a large third-party platform. It required building each piece small and specific to what we needed, on the stack we already run, instead of paying for one big bundle we mostly were not using.

We are not paying for it anymore.

the discipline is asking every time

I think a lot of software gets bought by default, because subscribing is the easy path and building takes real time up front. I would rather spend that time once, on something that fits exactly what we need, than keep paying every month for something that mostly does not.

That does not mean I get this right every time, or that every subscription is worth cutting. It means the question gets asked before the subscription starts, not years into paying for it. Could we build this ourselves. If a vendor's answer is genuinely better, pay for it and move on. If it is not, build the small thing you actually need.