"Everyone gets a Jarvis"

AI agents can now build almost anything. The harder question is figuring out what to actually hand them.

Mar 24, 2026

Last month, an AI agent built me a fully functional auditing tool in an afternoon. Two weeks of developer work. One afternoon. I didn’t know what to do with myself when it was done.

There’s a scene in Iron Man where Tony Stark walks into his garage, says a few words, and Jarvis conjures software and full 3D visuals on demand. No meetings, no tickets, no waiting three weeks for a sprint.

That’s what AI agents are turning into today — Claude Code, Manus, OpenClaw. You describe what you need. It gets built. With Whisprflow, people are making this into a reality FAST.

Iron Man 2 | Welcome home sir (Workshop scene) - YouTube

So the obvious question that comes to me is… why would anyone pay for software again? When should you build or buy software? And, what are actual moats in the software business now?

Stick with me, because the answer is more interesting than you’d think.

Some context… the wall came down

Buying software was, for a long time, just the only practical option. Building your own took months, cost a fortune, and needed specialists most companies didn’t have sitting around. So everyone subscribed. The whole SaaS industry was built on that being true.

It’s getting less true fast. Retool surveyed 817 enterprise builders last year — mixed teams, not just developers, real people across ops, finance, product, IT. 35% had already replaced at least one SaaS tool with something they built themselves. 78% plan to build more in 2026.

One company in that survey had been paying $20,000 a year for a tool. Vendor support was so slow that their ops lead rebuilt the whole thing with an AI agent before a single support ticket got answered. Now their default question for any new software need is: why can’t we just build this?

It’s a fair question to be asking. But it’s not the only one.

Can build is not the same as should build

An AI agent could probably build you a version of Salesforce. Custom, fast, no per-seat licensing, no paying for features you’ve never touched. That’s not hypothetical anymore.

But think about what Salesforce actually is under the hood. Twenty years of security audits. A team of hundreds whose entire job is making sure your customer data stays where it should. SOC 2 certification, GDPR compliance, breach response protocols. The checkbox your enterprise customers look for before they’ll sign a contract with you. And when something does go wrong — a company with real liability on the other end of the phone.

A Jarvis-built CRM has none of that. It has you.

Trust was always the moat. What changed is that it now has to win the argument on its own, because cost no longer makes the decision automatically.

Before, building was expensive enough that buying was the default for almost everything — and trust came bundled in whether you thought about it or not. Now building is cheap, and trust has to be a conscious choice. For some things you make that choice and it’s fine. For others, it’s a liability you haven’t fully accounted for.

The build vs. buy math is changing — fast

Three years ago this whole conversation was mostly theoretical. Building was expensive enough that the economics made the decision for you. You bought things, because building was out of reach.

Retool’s CEO David Hsu said it plainly to Newsweek this February: “The cost of building custom software has collapsed. Two years ago, a custom internal tool might take an engineering team weeks and cost six figures. Today, a business operations lead with the right platform can have a working prototype in a day or two. That’s a structural change, not a cyclical one. When the cost of building drops by an order of magnitude but the cost of buying stays flat, the math changes for every company.”

Here’s what that actually looks like. Same internal reporting tool. 10-person team. Three-year view.

Build it in 2020:

Developer cost to build: $8,000–$12,000 (US contractor rates run $100–150/hr; a two-week build is 80+ hours)
Server hosting on AWS: ~$50/month
Ongoing maintenance: more developer time every time something breaks or changes
Security and compliance: your problem, your cost
Three-year total: $15,000+ before anything goes wrong

Build it in 2026 with your Jarvis:

Agent cost to build: near zero — an afternoon
Server hosting on AWS: still ~$50/month — this doesn’t go away
Ongoing maintenance: still real — someone has to own it when it breaks
Security and compliance: still your problem
Three-year total: ~$1,800 in hosting — if nothing goes wrong

Buy a SaaS tool instead:

10 users at $29/user/month (median entry-level SaaS pricing in 2025): $290/month
Annual price increases averaging 8–12% per year — SaaS inflation is running nearly 5x the general market rate right now
Maintenance, hosting, security, uptime: their problem, included in the price
Three-year total: ~$11,000–$13,000 and climbing

On paper, building with Jarvis wins easily. And for a simple internal tool with no sensitive data, it probably does. But that “if nothing goes wrong” is doing a lot of work. METR ran a proper randomized controlled trial last year — experienced developers, real complex codebases, not toy projects. When they used AI tools, they took 19% longer than without, and thought they were 20% faster. The first 90% of building is genuinely fast now. The last 10% — edge cases, security hardening, keeping it running when something breaks six months from now — still takes what it always took.

One team built an AI-assisted internal dashboard in two weeks. Six months later nobody could safely touch it. The developer who built it had moved on. They scrapped it and bought a SaaS tool, which is probably what they should have done from day one.

Who we buy software from is about to change

A friend of mine was telling me recently he wants to build a social media scheduling app. I asked him the obvious question: if anyone with a Jarvis can build a scheduling app in a weekend, what’s your advantage?

He didn’t hesitate. His advantage is the people he already knows. The marketers, the agency owners, the founders in his network who trust him personally. Who’ve seen him show up, fix problems, respond at midnight when something breaks. Who’d pay for his tool over a stranger’s identical tool on Product Hunt — not because his is better, but because he built it and they know him.

That’s not a new idea. People have always bought from people they trust. What’s new is that it’s becoming one of the only defensible advantages left in software. When the product itself can be replicated in an afternoon, the relationship is what remains.

Info-Tech Research Group found in their 2025 buyer research that satisfaction is now rooted in the vendor relationship, not the feature set. People leave when the relationship breaks down. Rocket Software found that 84% of consumers say knowing a company uses secure, up-to-date technology makes them more confident doing business with that brand.

The product got you in the door. The relationship keeps you there. And for a lot of buyers, the relationship is the reason they knocked in the first place.

The moats that still hold

So what actually defends a software business in a world where anyone can build? The feature list is gone. The UI is gone. “We built it first” is gone. Here’s what remains.

Network effects. The product gets more valuable as more people use it. WhatsApp isn’t better than its competitors because of the code — it’s better because everyone you know is already on it. Slack, LinkedIn, Uber. Your Jarvis can build a ride-sharing app. It cannot build the driver network. The product and the network are inseparable, and the network took years.

The content and library effect. Spotify has 100 million tracks. Netflix spent billions on licensed content. A medical records platform has fifteen years of patient data structured exactly the way clinicians need it. These libraries cost more to build than any subscription price — often by orders of magnitude. Nobody is going to have their Jarvis recreate that. The cost in time, money, and licensing negotiation makes it untouchable. The content is the moat, not the player.

Switching cost moats. When your entire team is trained on a tool, your three years of data lives inside it, your workflows and integrations are built around it — leaving costs more than staying, even if a cheaper or better alternative exists. This is why enterprise software companies sleep well at night. Getting out is a project. Most companies never start it.

Compliance and regulatory moats. SOC 2, HIPAA, FedRAMP, PCI-DSS. These certifications take years to earn and require ongoing investment to maintain. An enterprise customer’s procurement team isn’t going to approve your Jarvis-built alternative because it doesn’t have the paperwork. The certification isn’t the product — it’s the permission slip to sell the product to anyone serious.

Trust and reputation moats. The oldest one. Eight years of uptime. A support team that picks up the phone. A track record that your customers’ customers can point to when someone asks why they use you. My friend’s scheduling app wins not because of features but because his buyers would rather give money to someone they know than take a chance on someone they don’t. At scale, this is what brand actually means.

Notice what’s not on this list… the code itself. The features. The UI. The clever onboarding flow.

Those were always easier to copy than people admitted. Now they’re trivial. What’s left is everything that takes years to build and can’t be prompted into existence.

Taste and judgement is something I still think is important and hear people talking about alot, but I am not sure that a successful judgement/taste couldn’t just eventually be copied.

So, when do you build, and when do you buy?

My auditing tool was easy. Internal only, no customer data, unique to my workflow, and I can maintain it myself. Two weeks of developer time versus one afternoon — that math does itself.

But I’d never have an AI agent build something that touches customer payment data, or that an enterprise client’s security team is going to review. Not because I couldn’t. Because the question stopped being about capability a while ago.

Build with your Jarvis when the tool is internal, the data isn’t sensitive, the workflow is specific to you, and you can own what happens to it when the person who built it moves on. Build when no vendor does what you actually need.

Buy from a vendor when you’re handling customer data at scale, when you’re in a regulated industry, when your customers or partners will audit your stack, or when getting it wrong is a company-ending problem. Buy when what you actually need is the decade of trust sitting underneath the product, not just the product.

The gray zone — and this is where most companies actually live — is building the custom layer on top of a trusted foundation.

Your Jarvis writes the workflow, the interface, and the internal tooling. But it sits on Stripe, on AWS, on whatever infrastructure took ten years to make trustworthy. You get the customization without taking on the liability of replacing the thing underneath.

Trust was always worth paying for. Now you just have to decide when.

Discussion about this post

Ready for more?