The $135 Million Argument for No-Code (and Why I Just Went Full Custom Anyway)

By the end of this newsletter, you'll be able to:

1. Price any build-vs-buy decision with one napkin formula (the $135M rule)
2. Name the two walls that genuinely force a custom build, and the ones that don't
3. Run the security checklist your no-code platform has been silently handling for you
4. Copy the exact stack and playbooks I use to ship custom software with AI agents
5. Steal my learning diet, the newsletters and skill packs I use to get better at this every week

TL;DR: I've been quiet for two months because I've been building. What the build taught me:

• No-code is renting. Custom is owning. Every SaaS subscription is you renting a product team. Airtable's payroll alone is conservatively $135 million a year, and you rent it for anywhere from free to about $75 a seat per month.
• The day you leave a platform, you inherit every safety net it was running. A security disclosure found 170 of 1,645 AI-built production apps with broken database security.
• Agentic AI made full-stack real for citizen developers, because the project's context lives in GitHub now, not in one tool or one AI's memory.
• Bonus: my exact build stack, the security checklist, and the actual reading list behind all of this.

My wife and I rent our home. We always have: houses, apartments, condos, every city we've lived in.

On paper, we're the last people who should. Cassidy is a designer. I'm the guy who genuinely enjoys fixing things. Everyone assumes we should buy a place and renovate it.

But we love renting. Specifically, we love the constraints. We can paint the walls, hang wallpaper, swap fixtures. Plenty of room to make it ours. And when the air conditioner dies in a Texas summer? Not our problem. Plumbing, electrical, foundation: one text to the landlord, who gets to deal with the subcontractors. (We admittedly take renting to the maximum. It's a running joke.)

Hold that picture. It's this entire debate in one image: no-code is renting. Full custom is owning.

And this month, I finished helping a client buy the house.

They'd hired me to help with their Airtable. Instead, I walked them off it. The roughly $1,000-a-month bill, scaled-up plans across the whole team, gets canceled in the next few weeks. And I'm the one who originally told them Airtable was the right call.

When I explained why the platform couldn't deliver the experience their customers needed, the founder didn't argue. He exhaled. "Good. Because I've been struggling with that one, too."

That doesn't make the original recommendation a mistake. The opposite: Airtable was the prototype. For months, it let the whole team test the workflows, the architecture, the schemas, the actual usability, in a working tool people could click around in, not a slide deck, knowing the whole time that whatever we learned would be rebuilt better and more custom later. That's renting at its best: full value from day one, nothing you have to own.

To understand why we eventually bought anyway, you need to know which side of this fight I've always been on.

The $135 million argument (I'm still making it)

I'm the no-code guy. I've built businesses, client systems, and most of my own tools on Airtable, Make, and Zapier. And the reason has always come down to napkin math I still stand behind.

Airtable has roughly 930 employees. Assume an average salary of $150K, which is deliberately conservative: levels.fyi puts Airtable's median engineer package at $415K. That's at least $135 million a year in payroll building, securing, and running software that you rent for anywhere from free to about $75 a seat per month, depending on your team size and plan.

And I'm only picking on Airtable because it's the tool in this story. Run the same math anywhere in your stack: HubSpot has roughly 9,000 employees behind your CRM. Zapier runs your automations with about 1,500. Notion, Monday.com, QuickBooks, same story at different scales. Every subscription is another company's entire staff working for you, and not just the engineers. The security team, the infrastructure people, the person answering support tickets at 2 a.m. That's the point: you're renting whole companies, not coders. Stack five tools and thousands of people are on your payroll for a few hundred dollars a month.

I've run multiple businesses arbitraging this simple fact: developers at other companies build features that make my tools better, and I never have to hire a single one. As they roll out features, I roll out features.

Here's the napkin formula, so you can run it on your own stack:

(vendor headcount × average salary) ÷ your annual bill = your rent multiplier.

(Headcount is the only input you might not have; it's on the vendor's LinkedIn page, or a ten-second search for "[vendor] employees." For a rough feel, mid-2026: Airtable ~930, Supabase ~400, Zapier ~1,500, Notion ~7,300, Anthropic ~5,600, OpenAI ~10,500, HubSpot ~8,900, Stripe ~8,500. Notice how fast that adds up across a five-tool stack.)

A solo builder on a single seat is closer to 250,000-to-1. Anytime you're renting engineering at thousands-to-one, keep renting, unless you've hit one of the two walls below.

Who gets to build

And the deeper magic of no-code was never the price. It's that the person closest to the business problem gets to build the tool: the operations manager who lives in the workflow, not a developer three layers of translation away. That's what "citizen developer" has always meant, and it's going mainstream, Gartner expects that by the end of this year, 80% of low-code users in large enterprises will sit outside IT. As one commenter put it in a recent r/nocode thread on making money with these tools: "Clients rarely care what tool you use." They pay for solved problems.

So no, "just build it custom" is not automatically smart. For most internal tools and most teams, the $135M team wins.

The two walls

Then why did we buy the house anyway? Two walls.

1. Record ceilings. Every no-code platform caps how much data you can hold, and the plan jump to raise the ceiling can nearly double your bill. To be fair, this one is more manageable than people admit; routine archiving and pruning is a best practice you should be doing anyway. But a ceiling you're constantly managing around is still a ceiling.

2. The external user experience. This was the real decision. Internal users will tolerate a tool that looks like a database. External users (customers, the people your business serves) deserve an experience you control down to the pixel. Every screen, every interaction, every loading state.

We control the entire experience now. It's a double-edged sword, and a lot of responsibility lands on my shoulders. But that's what I'm here for.

Which brings me to what you inherit the day you leave.

With great power comes great responsibility

The moment you leave the platform, you inherit every invisible thing it was doing for you.

Row-level security (the database rules deciding which records each user can see) is now your job. On modern stacks your users do talk to the database, through an API layer; RLS is what stands between them and everything they shouldn't see. Deciding exactly how that access works is your job now. Authentication, backups, audit trails: yours, yours, yours.

This is not theoretical. A security disclosure (CVE-2025-48757) found 170 of 1,645 production apps built with one popular AI app builder shipped with missing or broken row-level security. Earlier this year a founder proudly launched an app having written zero lines of code himself, researchers found the entire production database exposed within three days. And before anyone assumes this only happens to amateurs: OpenAI disclosed a security incident in its own model-evaluation pipeline in July 2026. Nobody is above this.

You can't just declare "I'm going to start coding with AI now" and skip the fundamentals. I spent four years studying computer science fifteen years ago. The field has changed enormously; the fundamentals haven't. What makes AI genuinely valuable is applying best practices that have been established for decades, and what makes it dangerous is skipping them because the demo worked.

Your no-code platform was handling all of this from day zero. That's a real chunk of what the $135 million buys. Respect it before you walk away from it.

And if you do walk, here's the checklist, the one I promised you at the top. Every box, before real users touch it:

One receipt from the build

The last three months produced real stories: a 105-document parser bake-off, a call three weeks before launch where I had to say "the plan needs to change." I'm telling those one at a time on LinkedIn this week, and collecting them all in Friday's follow-up newsletter.

But one belongs here, because it keeps this piece honest. I recently pitched a client on restructuring their data pipeline for cleaner architecture. The response, "I feel so good about where we have things right now... I just don't know if it's worth the squeeze," was correct. We kept their structure. Custom isn't always the answer, and neither am I.

The payoff (and an honest concession)

So what does carrying all that weight buy you?

Your own APIs. Your own CLIs. Your own MCP servers, so AI agents work with your platform natively. A backend nobody sees and an experience that's 100% yours. (Acronyms new to you? I keep a plain-English Operator's Glossary for exactly this.)

And a concession to the engineers reading: yes, "custom" here means custom on managed rails. Supabase and Vercel have nine-figure payrolls I'm renting too, the same $135M argument, one layer down. That's the point. You never choose between renting and owning. You choose which layer you rent.

The double-edged sword cuts exactly where the house analogy says it will. The quiet gift of building in a no-code tool is the constraints: the fonts, the colors, the text sizes, where a button can go and what it's allowed to do, all decided for you. Rented walls. You decorate, and it looks clean because it can't not. Go custom and anything is possible, which means every one of those decisions is now yours to make and yours to maintain. A more powerful tool is also a more complicated one. Owning the house means you can move a wall. It also means you're the one drawing the floor plan.

One warning before the tools section: with today's models, a working prototype takes an afternoon. A production system (especially one you're delivering to a client) is a different animal. The distance between the two is exactly the stuff that never makes the demo video.

How I actually ship now

The real 2026 unlock is where the context lives, not which model you use.

This build sits on six months of stakeholder conversations. None of it lives in my head, or in any one AI's memory. It lives in the repo, in a shape any model or teammate can pick up cold:

In practice: conversations become specs (plans), specs become tasks (GitHub issues), tasks become pull requests, and everything lands in the repository, the source of truth. The visual version of this flow is on the web post.

Models work like a team, not a subscription. I mostly run Anthropic and OpenAI models, but which one changes with the task. A frontier model does the planning and architecture. Smaller, cheaper models do the hands-on work as sub-agents. Then the frontier model reviews the result and either approves it or sends it back with comments for the smaller models to fix. It's the classic architect-and-builders setup, running at machine speed. (Not ready to marry one lab? Cursor, Notion, and Hyperagent all bundle multiple models under one subscription with subsidized credits, and OpenRouter puts every model behind a single API key, experiment first, commit later.)

Skills are the other half. Matt Pocock's AI coding workflow is the best on-ramp I know, and the deeper methods are all linked in Bonus 2. But my most-used skills are humbler: an end-of-day wrap-up and an end-of-week wrap-up. AI work is an infinite dopamine drip, there is always one more thing it can do, and something has to tell you "this is a stopping point." Pair that with a task system (GitHub issues, Basecamp, Asana, Jira, Notion, pick one) and every model, agent, and platform you work with, local or cloud, gets the same answer to the only question that matters: what exactly are we working on right now?

And if the word "repository" just made your shoulders tense: Claude Code now lives inside the regular Claude app, ChatGPT has Codex built in, and working with a repo is closer to briefing a capable teammate than to programming.

I say that as someone who went the other way and came back. I did all of this in terminals for a long time, and I've since moved most of my work into the native desktop apps. They've gotten good, good enough that people who were curious but intimidated can finally get involved, and good enough that the people who assumed the apps were a watered-down terminal have quietly stopped saying so.

Your first step, if you're no-code curious: ask Claude to help you create your first GitHub repository, then have it rebuild one Airtable automation you already understand as a tiny app. One weekend, zero stakes. That's the whole on-ramp.

So which one should you pick?

This exact question, should citizen developers vibe code, or vibe no-code?, is the live argument in operator circles right now. Here's my answer:

Choose no-code when the users are internal, the data fits the limits, and the person who understands the problem can build it themselves.

Choose custom when external users are the point, or the experience is the product, when your customers live in the house too.

And in between: no-code plus custom extensions is still the right balance for most businesses I advise. This isn't a religion. It's a sizing exercise.

The part where I tell you what I'm doing next

I'm fully open for consulting and advising engagements. I've done this work with Fortune 100 companies and with startups that were two people and a deck. If you're staring at build-vs-buy, wondering whether your no-code stack is about to hit a wall, or figuring out what agentic development means for your team, get in touch, or forward this to the person you know who's wrestling with it.

More on this theme all week, across the newsletter and socials.

Know someone stuck between no-code and custom? Forward this to them. I write these so people can skip the tribal arguments and get the honest take from someone who's built real systems both ways.

Share on LinkedIn · Share on X

This is Automate With Rob, a newsletter about building with AI tools without losing your mind. If someone forwarded this to you, subscribe here.