On this page
Three questions, in order, settle almost every one of these. And the honest answer is "skip" far more often than any comparison article will tell you — including the ones on this site, because a comparison is structurally incapable of recommending that you buy nothing.
The three questions
| # | Question | If no |
|---|---|---|
| 1 | Have you done this manually at least five times? | skip — you do not know what you need yet |
| 2 | Does it sit on the thing you sell? | buy, if anything |
| 3 | Is it expensive when it fails quietly? | buy, and do not build it |
Most candidates stop at question one. That is the finding, and it is unpopular because it means the answer to "which tool should I use for this" is frequently "none, yet".
Why five times by hand?
Because the first three times are not the process. They are you finding out what the process is.
Automating at attempt two encodes a workflow you have not finished designing, and the automation then becomes the reason you stop changing it. The cost is not the tool — it is that you have frozen the wrong version and made it expensive to unfreeze.
By the fifth repetition, three things are true that were not true at the second: you know which steps actually matter, you know which ones you skip when you are busy, and you know how often it happens. All three change what you would build or buy.
There is a second benefit people miss: doing it manually five times often reveals that it happens twice a month, not daily, and the automation is not worth anyone's afternoon.
When should you build?
Narrower than most developers want to hear.
Build when it is close to what you sell and the bought version would constrain it. A shop whose checkout is the product is worth owning. A shop whose checkout is a necessary inconvenience is not.
Build when the recurring cost is large relative to the work. Large, and relative. A €30 a month tool replaced by two days of work pays back in under two years, which is not a good trade for most people once maintenance is counted.
| Thing | Usually |
|---|---|
| Your core product | build |
| The checkout, if you sell files | either, see below |
| Payments, auth, email delivery | buy |
| Analytics | buy, or use what is included |
| Internal automation | skip until it is painful |
The checkout row is genuinely contested, which is why it has its own article: Shopify or your own checkout works through where it flips.
The whole list
67 tools, what each costs and when you actually need it. Updated twice a year.
When is buying obviously right?
When failure is expensive and someone else is on call.
Payments, authentication and email delivery are the canonical three. All of them are solved, all of them are unforgiving, and all of them have a failure mode where nothing appears broken while money or trust quietly leaks. Building any of them to save a subscription is one of the best-documented mistakes in this field.
The test in question three is specifically about quiet failure. A thing that breaks loudly gets fixed. A thing that stops delivering emails on a Tuesday and tells nobody costs you a month of signups before you notice.
What does "skip" look like in practice?
Doing it by hand, or not doing it.
Skipping is the most common correct answer and the least often chosen, because it does not feel like progress. Buying a tool produces a dashboard and a sense of having addressed something. Doing the task by hand for another two months produces nothing to look at.
But the real cost of a skipped tool is zero, and the real cost of an adopted one is the subscription, the setup, the thing you now check, and the migration when you leave. Nobody subscribes to six tools on purpose is what the accumulated version of that looks like.
Why do comparison articles not say this?
Structure, not dishonesty.
A piece comparing five tools exists to help you pick one. "None of these, do it by hand" is not something that format can conclude without undermining itself, so it does not get said — even when the writer believes it.
Which is worth knowing when you read one. The honest correction is to add a sixth option to every comparison you read, labelled not yet, and to check whether it would win on question one before reading any further.
Is there a fourth option?
Yes: defer with a trigger.
Rather than deciding now, write down what would make the answer obvious. "If this takes more than an hour a week, I will automate it." "If I get a second complaint about this, I will pay for the tool."
That converts an open question into a closed one and stops it reappearing every time you are procrastinating. It is also the only version of this decision that improves on its own, because the trigger either fires or it does not, and both outcomes are information.
Where this came from
A decision process rather than a measurement. The three questions are ordered by how often they settle the matter, and the "five times" threshold is a working rule rather than a researched number — it is offered as one.
The AI Mastery Playbook covers building systems around decisions like this instead of remaking them each time.
Tools in this piece
| Tool | What it does | Price |
|---|---|---|
| Vercel | Hosting. Puts a project live on a real address with one command. | Free tier |
| Supabase | Database, accounts and file storage in one, with no backend work. | Free tier |
| Stripe | Payments and subscriptions. The standard, and integrating it is a matter of asking. | Free, percentage per sale |
| Zapier | The most integrations, the highest price. | Free tier, then ~$20+/mo |
| Make | Visual automation between tools, lower barrier than n8n. | Free tier |
| n8n | Workflow automation you can host yourself. Plenty of control. | Free self-hosted, cloud ~€20/mo |
Every tool has its own page with the price, who should skip it and what to check before paying. Some links are affiliate links.
Questions people ask
How do you decide whether to build or buy a tool?
Ask three things in order: have you done this manually at least five times, does it sit on the thing you sell, and what does it cost if it breaks and nobody notices. Most candidates fail the first question, which means the answer is neither build nor buy.
When should you build it yourself?
When it is close to the thing you sell and the off-the-shelf version would constrain it, or when the recurring cost is large relative to the work. Building something peripheral to save a subscription is almost always a bad trade.
When is buying obviously right?
When the thing is a solved problem outside your core, where a failure is expensive and someone else is on call. Payments, email delivery and authentication are the standard three, and building any of them to save money is a well-documented mistake.
What does 'skip' actually mean?
Doing the task by hand, or not doing it at all. It is the most common correct answer and the least often chosen, because it does not feel like progress and nobody writes articles recommending it.
Is automating a manual process always worth it?
Only once the process is stable. Automating something you have not run by hand several times encodes a workflow you have not finished designing, and the automation then prevents you from changing it.
Why do comparison articles rarely say 'skip'?
Because a comparison exists to help you choose between options, and 'none of these' is not an option it can recommend. That is a structural bias rather than dishonesty, and it is worth correcting for.