The "I Could Build That" Fallacy

You saw someone's AI workflow on Twitter — an n8n pipeline that scrapes job listings, scores them with GPT-4, filters by your criteria, and sends a daily digest to Slack. Forty-seven nodes. Beautiful screenshot. Your immediate thought: "I could build that." You're probably right. You could build it. That's not the interesting question. The interesting question is whether you should spend 30 hours building something you could buy for $29/month, and whether you'll actually finish it, and whether it'll still be running in three months.

The "I could build that" impulse is nearly universal among technical people. It's part of how we process the world — we see a system, decompose it mentally, and assess our ability to replicate it. That assessment is usually accurate. If you're comfortable with APIs, webhooks, and prompt engineering, you could build most of the AI workflows you see demoed online. But ability is a necessary condition, not a sufficient one. The question that ability answers — "can I?" — is trivially easy compared to the question it obscures: "should I?"

The Pattern

The pattern starts with exposure. You encounter someone's working system — a blog post, a Twitter thread, a YouTube video. The system does something useful. It's built with tools you know or could learn. The person who built it doesn't seem dramatically more skilled than you. Your brain, reasonably, files this under "things I could do."

Then the pattern escalates. "I could build that" shifts to "I should build that" without the intermediate step of evaluation. The shift happens because building feels productive. It feels like the right kind of work — creative, technical, forward-looking. Nobody feels lazy while building an automation pipeline. The feeling of productivity is so strong that it substitutes for the analysis of whether the productivity is aimed at something valuable.

I've done this more times than I'd like to admit. In 2025, I spent roughly 40 hours building a custom content pipeline — RSS ingestion, AI summarization, topic classification, automated newsletter generation. The pipeline works. I've used it maybe five times. The equivalent service from a tool like Readwise plus Buttondown would cost about $15/month and would have been running the entire time I spent building. I didn't build that pipeline because I needed it. I built it because building it was more interesting than evaluating alternatives.

The pattern repeats across every technical community I've observed. Users on r/selfhosted and r/n8n regularly post elaborate automation workflows that took weeks to build and replace a manual process that took minutes per week. The math doesn't work, but the posts get upvoted because the community values the build, not the ROI. There's nothing wrong with building for fun — the problem is when you tell yourself it's for productivity.

The Psychology

Three cognitive biases drive the "I could build that" fallacy, and they stack.

The planning fallacy makes you underestimate build time by 2-5x. "I could build that in a weekend" is the canonical expression. What you mean is: you could build a version that handles the happy path in a weekend. Making it handle errors, edge cases, authentication refreshes, API changes, rate limits, and the twelve other things that distinguish a demo from a daily driver — that's not a weekend. That's a month of weekends, and by the third weekend your enthusiasm has cratered because you're debugging OAuth token refreshes at 11 PM instead of doing the thing the tool was supposed to help you do.

I tested this with a simple workflow — a Make.com automation that monitors a Google Sheet for new rows, enriches the data with an API call, and posts a summary to Slack. The happy path took 2 hours to build. Handling the cases where the API returns malformed data, the Sheet has empty rows, the Slack webhook times out, and the Make.com scenario hits its operations limit took another 14 hours. That 2-hour estimate was technically correct and practically useless.

The IKEA effect makes you overvalue things you build. Research on this is well-documented [VERIFY] — people assign higher value to things they've assembled themselves, regardless of objective quality. Your custom-built AI pipeline feels more valuable than the $20/month SaaS tool that does the same thing, even if the SaaS tool is more reliable, better maintained, and handles edge cases you haven't thought of. The labor you invested creates an emotional premium that distorts your evaluation.

The identity-as-builder bias is the deepest one. If you're a technical person, building things is part of how you see yourself. Choosing not to build — choosing to pay for someone else's solution — can feel like a minor identity violation. It feels like admitting you can't, even when the truth is that you shouldn't. The build-versus-buy decision gets tangled up with self-concept in ways that make the analysis unreliable.

The Fix

Replace "I could build that" with a three-question filter. The filter takes 60 seconds and saves you from the 60 hours you'd spend learning that lesson experientially.

Question 1: Does a paid tool already do this? Search for it. Spend 10 minutes. If a tool exists that does 80% of what you want for a reasonable monthly cost, the build calculation changes dramatically. The question becomes: is the missing 20% worth the build time? Usually it isn't. Sometimes — when the missing 20% is core to your use case — it is. But you can't answer this honestly if you skip the search.

The threshold I use: if a paid tool costs less per month than what my time is worth per hour, and the build would take more than a few hours, the paid tool wins. This math is simple and people avoid it because the answer is usually "just pay for the thing," which is unsatisfying.

Question 2: What's the true build time? Take your instinctive estimate and multiply by three. This isn't pessimism — it's the documented planning fallacy correction. If you think "a weekend," budget three weekends. If you think "an evening," budget three evenings. Now compare that corrected time against the cost of the paid alternative over a reasonable period — say, one year. If three weekends of your time costs more than $240/year for the SaaS tool, you have your answer.

Include maintenance in the build time. Every custom-built pipeline requires maintenance. APIs change. Authentication expires. Dependencies update. The n8n workflow you built in March breaks in June because OpenAI deprecated the API endpoint you were using. Per OpenAI's API versioning documentation, deprecated endpoints typically get 6-12 months of support before removal [VERIFY], but that still means you're on the hook for migration. The SaaS tool handles that migration for you. Your custom build doesn't.

Question 3: What won't you do while building this? This is the question people never ask. Building has an opportunity cost. The 30 hours you spend building a custom AI pipeline are 30 hours you're not spending on the thing the pipeline was supposed to help you with. If you're building a content automation system, you're not writing content while you build it. If you're building a research pipeline, you're not doing research. The tool is supposed to serve the work. If building the tool becomes the work, you've inverted the relationship.

Here's when building is the right call. When nothing exists that handles your specific use case — not "nothing exists that handles it perfectly," but "nothing exists that handles it at all." When the existing tool's limitations are in the core functionality, not the edges. When the build process itself teaches you something directly applicable to your work — not "teaches you n8n," but "teaches you how your data pipeline actually needs to function." When the build is genuinely fun and you're honest that fun is the reason, not productivity.

Here's when building is the wrong call. When you're building to avoid paying for a tool, and the avoidance is driven by frugality instinct rather than actual financial constraint. When the build time exceeds a year's cost of the paid alternative. When you're building for the feeling of building — the dopamine of assembling a system, the screenshot for your own Twitter thread, the satisfaction of "I made this." These are real and valid feelings, but they're not the same as making a good allocation-of-time decision, and conflating them is how you end up with 40 hours invested in a system you've used twice.

The honest version of "I could build that" is: "I could build a version of that, it would take longer than I think, it would be less reliable than the demo, and maintaining it is a commitment I'm making to my future self." If you still want to build after that restatement, build. If the restatement made the project less exciting, the excitement was coming from the wrong place.

This article is part of the Demo vs. Delivery series at CustomClanker.