Can't OpenClaw Build That?

February 14th, 2026

A close friend of mine sent me a WhatsApp message the other day. I had just released Kabinette, a SaaS product I've been working on for a few months. His message:

"Can't OpenClaw build that?"

I'm pretty sure there wasn't any intent to patronize me - I do believe it was asked in good faith. But it worked me up, because it's symptomatic of this narrative that's been building up in and around the tech industry.

Tech sector stocks saw sharp declines these past two weeks, supposedly driven by Anthropic's release of Claude Cowork - normies are starting to realize that AI is more than ChatGPT. The influencers on LinkedIn and X are having a field day: "SaaS is dead!", "Why are you paying for Salesforce when you can vibe code a CRM?", "Slack is cooked!" - all these merchants of gloom and doom. And look, Claude Cowork is a fantastic tool. Claude Code is even better, in my opinion, for people who are technical and can work with a command line interface. But everyone is missing the point. Is the cost of writing and shipping code tending towards zero? Yes, I think so. Cheaper code means faster time to market, 100 percent. But building a product and coding a prototype are two very, very different things that live very far from each other on the spectrum of product development. I think many people who are not engineers just don't understand that.

So what is Kabinette?

Before I explain why OpenClaw can't build it, let me tell you what Kabinette is. Kabinette was born out of a simple observation: email is not file storage. It's email storage. The way email is presented to you is as blobs of text. Those blobs of text can have documents attached to them, but the text comes first - that's why they're called "attachments". Your Gmail is organised around that text, and the interfaces are designed with that in mind: you can search for senders, you can search through the body of the email, and all of that works great. But searching for files? That's a different story. The file contents are never indexed. The only information your email client has about an attachment is the file name. That's it. So if someone sent you an invoice and the file was called "XYZ123.PDF", good luck finding it. For those of us who have accumulated years of attachments - invoices, receipts, photos, contracts - and actually need to find and organise them, email gives us very little to work with.

Kabinette solves that. It scans your email, downloads the attachments, and uses a large language model to classify their contents according to categories that you define. It then uploads them to your chosen storage provider - Google Drive, OneDrive, Dropbox - each file going to the folder associated with its category. Each time a new email comes in with an attachment, Kabinette classifies it and uploads it to the correct folder automatically.

I built it because after years of accumulating emails, I had attachments scattered everywhere - tax documents, Amazon purchase receipts, insurance policies, family photos - and no good way to find or organise any of them. We also have an Airbnb, which exacerbated the problem with a constant stream of invoices, receipts, and contractor correspondence. That tipped me into actually acting on it. It's really nice not having to worry about "Did I remember to upload this invoice to my invoices folder?" each time one comes into my inbox.

The prototype was ready in two hours

I had a prototype up during the last hackathon that we organised, the Bay Area Hack Days (we're going to have another one soon, stay tuned). That's when Kabinette was born, almost four months ago. Getting a basic prototype up and running was not hard. I hacked it together in about two hours. But you know what was hard? Making that prototype a real product. And that's where I want to get into the nitty gritty, because the answer to my friend is not just "no" - it's "no, and here's why".

A product needs to work

I don't mean "works on my machine". It needs to work for any unanticipated user input. It can't work for one user but not another. Think about what that actually means for a product like Kabinette:

Emails with no subject, no body, or no sender name. Corrupted files, password-protected PDFs, zero-byte attachments. File names with emojis or non-Latin scripts.
One user has 200 emails, another has 200,000 - both need to work. Provider rate limits kick in mid-sync. Processing times out on large batches.
Different browsers, devices, screen sizes. Different locales, timezones, date formats.
A user changes their categories while a sync is in progress. They disconnect mid-operation. Their cloud storage provider has an outage during upload.
A user revokes permissions mid-sync and wonders why it stopped. They run out of storage on Google Drive. They set up categories that overlap or contradict each other.

None of this is glamorous work. None of it shows up in a demo. But all of it has to be handled, and a prototype handles none of it. And the moment you have paying customers, the stakes go up dramatically. It's no longer a toy. When someone gives you their money, there's an implicit contract - they expect things to work, and when they don't, it's your reputation on the line. Every unhandled edge case is a support ticket, a bad review, or a churned customer. You don't vibe code your way into that kind of reliability. It takes careful, deliberate engineering and real attention to detail.

And the system it runs on needs to be stable. I know some people will bang on about "just buy a five-dollar VPS from Hetzner!" No, folks. That's not how you build a scalable software business. Sure, you can do that for a hobby project, but if you're trying to build a real product with real users and real guarantees, that's not the way.

Infrastructure is not one-dimensional

When I list "infrastructure" as a requirement, it sounds like this simple box to tick. It isn't. Where do you host? Europe? The States? Because depending on where you host, you are governed by different jurisdictions - GDPR is a big thing if you want to open your service to people in Europe. How much storage do you need, and can it grow elastically? Is there a database? Of course there is. Do you host it on the same machine that runs your web server? Not a good idea. And if you're not using a managed platform, you need to manage the database yourself. Database management is a skill. Your app will work fine for one user, but the moment you have concurrent users and every request is hitting the database for reads or writes, you will run into bottlenecks. Knowing how to design around that is not something you pick up from a weekend tutorial. That's just the basics.

Then there is the process of actually updating your software. You're not going to build it once, ship it, and never touch it again. You need to continuously update and test it. There needs to be a pipeline for that - CI/CD is not something that just builds itself. How do you make sure your tests pass before code reaches production? How do you deploy without taking down the service? What happens when a bad update slips through - can you roll back?

And every one of those environments - your laptop, your staging server, production - needs access to your secrets. Secrets are not an easy problem to solve. If my service needs to hit Anthropic's API, I need an API key. How am I planning to store that key and have it available across all those environments? How do I track changes to all those keys? I'm giving you one example, but Kabinette has over 30 different secrets. That's not easy to manage.

Observability

And we're not done yet. I wrote on X the other day that observability is one of the most important aspects of running a software business, and it's something that junior engineers consistently underestimate. Not having any observability in place is like driving with your eyes closed. You need to know if there are exceptions happening in your backend. You need to keep track of all the connections that are open. Is there a bottleneck? Is there pressure on my CPU? Is my disk suffering? Are there any memory leaks? That's just the operational side. Then you have the business side of things:

Did a user churn?
Did a token expire for the user?
Is the user's browser rejecting some of our requests?
Is the user trying to update their billing information and failing?
Did the user request a refund?

You need to know what to log and when to log, because logging itself can be resource intensive. You cannot build a product without this.

And all of this is just one more provider to manage. Kabinette uses many different providers - infrastructure, observability, payments, email delivery - each one another API key, another dashboard, another set of configuration. It adds up fast.

Security is a matter of life and death for your business

This is the one most people don't think about, and it's the one that matters most. Kabinette has access to your emails. That's an enormous responsibility. Programmatic access to Gmail data is classified as the most sensitive scope Google offers - and for a good reason.

To get Google to approve Kabinette, I had to go through a pretty grueling process that took six weeks. I had to record a video of myself showing how every scope we request access for is being used in the application. Right sizing - I had to explain why I need that level of access, and prove it! I had to have a privacy policy and terms and conditions in place. I had to show that there is a parent company above it - registered as a real business entity, not some Mickey Mouse "I'm running this from my bedroom" operation. I had to show ownership of all of that. The parent company had to have its own website. I had to have a logo for the product, separate from the parent company, and it had to be present on both the application and the website. They verify all of this - actual humans, not automated checks.

And we're not done. Once they're happy with all of that, they put you through something called CASA - a security certification conducted by vetted third-party agencies that Google works with. These guys first run automated scanning on your site; that's phase zero. They check for all kinds of vulnerabilities in your infrastructure, both front-end and back-end. They send you a list of findings, classified from severe, high risk, medium, low, and informational. You have to address every category - Google doesn't care, everything needs to be resolved. That's just the automated scan. Then those agencies work back and forth with you to verify how you secure the data, how you encrypt it, that you classify PII and actually segregate how you store it.

As a result, Kabinette is one of the most secure applications I've ever built. Literally everything is encrypted, and if it's not encrypted it's hashed, and if it's not hashed it doesn't exist. Nothing. If someone were to hack into the Kabinette server tomorrow and dump the database, they would get zero information about the customers and zero information about the contents of their emails or their attachments. By design.

UX and everything else

And then there's the user experience on top of all of this. Is there a proper onboarding? Is there support? What happens when there's a feature request? What happens if something doesn't work? Are there flows for all of that? Is there an FAQ? Do you deploy a chatbot to handle this? Maybe direct email support? How do you make sure that when people hit your website, they understand what the product does and can start using it without anything impeding them? Getting all of this right takes many iterations. It requires human input, and I'm talking weeks of tweaking various elements of the UI and the back end. Adding one type of sign-in, removing another. Really iterating until everything clicks.

And we're still not done. How do we make money? You need to integrate payments. Another API key. More security. That's another whole layer of complexity.

SaaS is not dead

So when my friend asked me "can't OpenClaw build that?" - it frustrated me, because it's exactly that narrative. Sure, these tools can help you build a prototype. But don't mistake that for a product.

Now let me take this one level higher. Kabinette is small - it's just me, no team, working evenings and weekends alongside my day job at Netflix. But the same dynamics play out at larger scale.

Let's take a real example. Say your primary business function is digital content publishing - take O'Reilly or one of those guys. Their core business is finding authors, helping them write their books, editing, polishing, publishing, and putting it on their platform. Do you think it makes sense for a company like O'Reilly to then create a small team that will vibe code all their internal tools and maintain them? Of course not. That would be absurd. You don't pay for the code, you pay for the product. O'Reilly has a CRM. That CRM is maintained by a third-party company. When something breaks, they pick up the phone or send an email and they have someone on the other side of the line that will fix the problem for them, follow up and advocate for them. That's the beauty of it. If they need an audit trail, if they want to know who did what, if they need to roll back a version or run into a bug - they don't have to worry about any of that. They have a company that provides a service with a real product and a real engineering team.

Why would O'Reilly hire a team of engineers to develop all these in-house tools? It's a full-time job. The code is the easy part. Iterating, maintaining, securing, improving - that is the hard part. That is the real grind. To say that SaaS is dead is ridiculous. Even if you could build all those tools in-house, it would not be prudent to do so because the versions you build will be subpar, and you will just need to hire more and more people to maintain products that are not core to your business. Unless you're a software company, let the software people deal with the software while you focus on the stuff that you know how to do better.

So to answer my friend:

Can't OpenClaw build that? Nah mate, it can't. And if it could, I don't think it's gonna be a good product.