The Custom CRM You Didn't Need: When A Spreadsheet Would Do

You have 47 contacts. You built a custom CRM to manage them. It took 30 hours across three weekends, lives in Airtable with six linked tables and a dozen views, and it does roughly 40% of what HubSpot's free tier does out of the box. But it's yours. You designed the schema. You chose the field types. You built the automations. You have 47 contacts.

The Pattern

The build-versus-buy decision is one of the most studied problems in software engineering, and the conclusion has been the same for decades: build only when your requirements are genuinely unique and no existing solution comes close. For enterprise software teams with unusual workflows and thousands of users, that threshold gets crossed sometimes. For a solo operator managing a contact list, a project tracker, or a content calendar — it essentially never does.

But the custom system gets built anyway. The trigger is usually a moment of friction with an existing tool. Your spreadsheet doesn't sort contacts by "last interaction date" the way you want. Notion's CRM template doesn't have a field for your proprietary lead-scoring rubric — the one you invented last Tuesday and haven't validated against any actual outcomes. Airtable's free tier limits you to 1,000 records, which you'll never hit, but the limit feels constraining on principle. The friction is real but minor. The response — building a custom system from scratch — is disproportionate in the way that swatting a fly with a sledgehammer is disproportionate. Effective, technically, but revealing about the builder's actual motivations.

The customization death spiral follows a predictable arc. Week one: the basic system works. You have contacts, companies, and a status field. It does what you need. Week two: you add a "last contacted" automation, a Slack integration that pings you when a contact goes cold, and a formula field that calculates days since last interaction. Week three: you add a pipeline view, a Kanban board, email templates linked to deal stages, and a reporting dashboard. Week four: you're debugging why the Slack notification fires twice and the formula field returns NaN for contacts missing a creation date. You have not, during any of these weeks, actually contacted anyone new. The CRM is growing. The contact list is not.

The data volume reality check is the test most custom system builders skip. How many records does this system actually manage? Not "how many could it manage" or "how many will it manage when the business scales" — how many does it manage right now? For most solo operators building custom CRMs, the answer is somewhere between 20 and 200. A Google Sheet handles 200 contacts without breaking a sweat. It sorts them, filters them, lets you add notes, and never requires debugging. It doesn't have a Kanban view, which is fine because 200 contacts don't need a Kanban view. They need a list, sorted by whatever matters most this week.

This pattern extends well beyond CRMs. The personal project tracker built in Notion with linked databases, rollups, and relation fields — for someone managing three projects. The custom inventory system for a collection of 80 items. The content calendar with automated publishing workflows, editorial status tracking, and multi-channel scheduling — for a blog that publishes once a week. In each case, the tool's complexity exceeds the problem's complexity by an order of magnitude. The system can handle a thousand records and a ten-person team. It serves one person with a few dozen entries. [VERIFY: Notion reports that the average personal workspace uses fewer than 5% of available database features — suggesting most complexity goes unused.]

The Psychology

The spreadsheet stigma is real and worth naming directly. Spreadsheets are "basic." They're what your parents use. They're what people who don't know about better tools use. Custom systems — with their linked databases, automated workflows, and purpose-built interfaces — are "professional." This is vibes, not analysis. A spreadsheet that gets used every day beats a custom system that gets built, admired, and abandoned. But the social signal of the custom system is stronger, and social signals drive more behavior than most people want to admit.

There's also a craftsmanship satisfaction that's genuinely earned and entirely beside the point. Designing a database schema is a real skill. Choosing the right field types, defining relationships between tables, building views that surface the right information at the right time — this is legitimate information architecture. The problem isn't that the work is fake. The problem is that the work is real and unnecessary. You are doing real engineering in service of a need that could be met by a tool you already have. The engineering is the reward. The system is the excuse.

The "but it's tailored to my workflow" argument is the most persistent defense, and it collapses under the gentlest scrutiny. Your workflow doesn't need tailoring. Your workflow needs executing. The difference between a generic CRM and a custom CRM is that the generic one has features you won't use, while the custom one has features you built and also won't use — but now you're responsible for maintaining them. The tailoring itself is the procrastination. Every hour spent perfecting the system's fit to your workflow is an hour not spent doing the work the system was supposed to enable.

The aspiration gap drives the rest. You're not building a CRM for the 47 contacts you have. You're building a CRM for the 4,700 contacts you imagine having someday. The system is designed for a future version of your business that may never arrive — and if it does arrive, you'll have different needs than you can predict today. Building for the aspirational version is architecture cosplay in its purest form: wearing the infrastructure of a larger operation without the operations to justify it. The person with 4,700 contacts isn't using a custom Airtable build. They're using Salesforce, because at that scale the buy decision is obvious.

There's a completion-resistance mechanism here too. A spreadsheet can be set up in ten minutes. That's not enough time to feel like you've done something substantial. A custom system takes weeks and produces a tangible artifact — tables, views, automations, a little machine that hums along. The spreadsheet feels disposable. The custom system feels like an achievement. The achievement is real. It's just not the achievement you needed.

The Fix

Before building anything custom, spend 30 minutes trying to solve the problem with a spreadsheet. Not a fancy spreadsheet — a basic one. Columns for the fields you actually use, rows for your actual records, and a filter or two for the views you need most. If the spreadsheet works, stop. The urge to build something better is not a requirement. It is a preference, and preferences should not be confused with needs.

If the spreadsheet genuinely doesn't work — if the data relationships are too complex for flat rows and columns, if the volume exceeds what a spreadsheet can handle responsively, if you need concurrent multi-user access with role-based permissions — then an off-the-shelf tool is the next step, not a custom build. Free CRMs exist. Free project managers exist. Free content calendars exist. They're built by teams of engineers who've already solved the edge cases you haven't thought of yet. They handle the cases your custom system handles, plus a thousand others, and they're maintained by someone who isn't you.

Custom builds are justified in a narrow set of circumstances: genuinely unique workflows that no existing tool can accommodate, data structures that spreadsheets can't represent and off-the-shelf tools don't support, or scale that exceeds what simpler tools can handle — meaning hundreds of thousands of records, not hundreds. If you don't meet at least one of these criteria, you don't need a custom system. You need to use the boring tool that already exists and redirect those 30 hours toward the work the tool was supposed to support.

The litmus test is blunt: describe what your custom system does that a spreadsheet or free tool can't. Not "it's more organized" — a spreadsheet is organized if you organize it. Not "it automates notifications" — you can check the spreadsheet once a day; the cognitive overhead is the same. Not "it scales" — it doesn't need to scale. Describe a specific, concrete capability that justifies the build time. If you can't name one in a single sentence, the custom system is a hobby project wearing a productivity costume. Call it what it is, enjoy it for what it is, and stop pretending it's a business tool.

The hardest version of this fix is retroactive. If you've already built the custom system — the Airtable CRM, the Notion project tracker, the custom content calendar — audit it honestly. How many of the features do you use weekly? How many hours per month do you spend maintaining it versus using it? If the maintenance-to-usage ratio is above 1:1, migrate to something simpler. Export the data to a spreadsheet, cancel the premium tier, and see if anything actually breaks. The answer, in most cases, is nothing breaks — because the system was never load-bearing. It was decorative. And decorative infrastructure is the definition of architecture cosplay.

This is part of CustomClanker's Architecture Cosplay series — when infrastructure is procrastination.