The Stack You Built Yourself: Notion, Airtable and Zapier

Somebody capable joined early and did not want to pay for a CRM. They built one: an Airtable base with the right fields, Notion for the documents, and a set of Zaps holding it together. It fits the business exactly, it cost almost nothing, and it works. Two years later it still works, and the person who built it cannot take two weeks off without something quietly stopping.

It is worth starting here, because the DIY stack usually gets written about condescendingly and the people who build it are typically the most capable operators in the company.

It fits exactly. No product is shaped like your business. This one is, because it was built around what you actually do rather than what a vendor assumed.

It changes at your speed. A new field takes a minute. A new process takes an afternoon. Nothing to request, nobody to wait for.

It is cheap and honest about it. The invoice matches what you use.

And critically, when the process is still changing weekly, this is the correct choice. No product fits a moving target, and buying one early usually means bending your process to fit somebody else's assumptions before you know your own.

Entry-tier pricing from the registry our comparison pages use, at six people.

The third figure is the real one, and it is the reason this post exists. Every other stack on this blog is expensive in money. This one is cheap in money and expensive in exactly the resource a small company has least of.

Products come with things you did not ask for and only notice when they are absent.

Somebody else is on call. When a real product breaks, a vendor fixes it. When your Zap breaks, the person who built it fixes it, and they find out because something downstream went wrong.

Permissions and history. A CRM knows who changed a deal and when. Airtable knows a cell changed. This is fine until a disagreement about what happened, and then it is not.

Silent failure. An automation that stops running does not announce itself. It is discovered later, usually by a customer who did not get something, and the gap between the failure and the discovery is where the damage is.

The documentation that does not exist. The stack is understood rather than written down. It works because one person holds the model in their head.

This is the argument that actually changes minds, and it is not about money at all.

The DIY stack is usually built by one person and understood by one person. That is not a criticism of them, it is a property of how it got built: incrementally, in response to specific needs, with the reasoning living in their head rather than in a document.

There is a subtler cost. The person maintaining it is usually your most capable generalist, and every hour on plumbing is an hour not spent on work only they can do. The stack is not just risky, it is consuming the person you most need doing something else.

The decision is not build versus buy in the abstract. It is whether the conditions that made building right are still true.

The process has stopped changing. This is the big one. You built it because the process was moving; if it has settled, the flexibility you are paying a person to maintain is no longer buying anything.

People outside the core team need to use it. A tool understood by its builders is fine for its builders. New joiners need something that explains itself.

A failure has been customer-visible. Once a broken automation has cost you something in front of a customer, the risk has stopped being theoretical.

Nobody can draw it. If no one can sketch how the pieces connect on a whiteboard, the complexity has exceeded the model.

The mistake is treating the migration as a replacement. Most of what you built is knowledge, not software, and it is worth more than the Zaps.

Keep the field list. The fields you added over two years encode what actually matters in your business. That is a better specification than anything you would write from scratch.

Keep the process, not the implementation. Write down what each automation does and why before switching anything off. The why is the part that lives in one person's head.

Keep Notion for what it is excellent at. Docs and knowledge are a genuinely different job from records and process, and this post is not arguing you should stop writing things down.

Move the system of record first. The database is where the risk is concentrated. Documents can follow later or never.

The general sequence is in the GTM stack consolidation playbook, and the individual comparisons are on the Notion, Airtable and Zapier pages. What is specific to the DIY stack is that the thing you are replacing is not really software. It is one person's accumulated understanding of how the company runs, and the migration is worth doing partly because writing that down is valuable whether or not you switch.