You may have heard the news: Bending Spoons acquired Airtable for $1.28 billion. Rome didn’t fall in a day, but this is as good a point as any to mark the moment No Code platforms jumped the shark. Full disclosure, I worked at Airtable for many years, love the product, and love the people I worked with there even more. It’s the technology, namely the unreasonable effectiveness of LLM loops with tool use, that’s changed.

Software at work is not valuable in and of itself. It’s built to serve some purpose. Mostly it’s used to keep track of something (schedules, parts, orders, people, you name it). Spreadsheets are the universal software here–and I love me a spreadsheet. But spreadsheets have a ceiling when it comes to sharing, programming, permissions, automations, and so on. Once you leave a spreadsheet, you upgrade to a database and some software on top of it: that’s what low or no code platforms like Airtable are. At their best, the person who brings Airtable to their team isn’t bringing Airtable: they’re bringing much-needed organization and process, and Airtable is merely the means.

One of the things that Airtable got right was their experience of creating the tables themselves. You just added a column (like in Excel), and chose a data type (string, number, date, and so on), and, voila, you’ve created a table. I used to joke that Airtable should show up to SIGMOD (the big database conference) and present a paper on the efficacy of not having ALTER TABLE widgets ADD COLUMN (color string) as the way people use your database. Fred Brooks wrote: “Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.” Airtable understood this at its core: if the user can specify the business model, building the automations and features on top of it becomes possible. (This is nothing new! FileMaker launched in 1985; it was my introduction to databases when I helped run a conference for ~1,600 high school students. It turns out that a little bit of extra credit, some freshmen, and 3 AppleTalk-connected computers could handle the mailed-in registration forms!) 

Once upon a time (the 90s!), IT teams at companies existed to build software for said companies. Much software was bespoke. We can use Salesforce’s 2000 “Software is Dead” campaign as the mile marker for when SaaS started taking over. IT departments became all about procurement. And procurement means saying NO. Low code and No Code platforms (and Microsoft SharePoint and Excel and Google Sheets) picked up the slack. When you can’t buy the software, you make do with what you can get access to, and you smuggle in some Airtable, increase revenues/efficiency/trust/whatever, and nobody can get rid of it for bureaucratic reasons because it’s now load-bearing.

AWS launched EC2 in 2006. You could rent a VM. Getting it on the internet (so that you could share a thing with your co-workers) required learning about EC2 VPCs, IAM permissions, EBS, RDS, static IPs, DNS, and a handful of other Three Letter Acronyms (TLAs). Even within software companies, IT gatekept EC2. When I was at Google in 2007, the tool to search the company’s code base ran on a spare desktop under Jeff Dean’s desk. Getting a machine in Google’s datacenter to serve this (to me, critical) piece of infrastructure was too much of a hassle. (There were, at the time, funny “Is it web scale?” videos; e.g., https://www.youtube.com/watch?v=b2F-DItXtZs, amongst others.)

Fast forward to 2026. LLMs are king. The SaaSpocalypse is under way, and happening like bankruptcy–gradually first, then all at once. What is the right way to build and deploy business tools? What is the right platform? Can non-software-engineers be trusted to do it?

The right answer (it’s my turn to be wrong on the internet today, baby) is Linux. Yes, choose boring technology, and just use Linux. You can choose one of many stacks on top of Linux. Honestly, if you chose LAMP (Linux, Apache HTTPd, MySQL, PHP) you would be fine. My current preference is (sqlite, Go, Typescript, maybe Vue). If memory weren’t getting expensive, there’d be nothing wrong with (PostgreSQL, Node, TypeScript) but the memory crunch is real, and the advantages of using a single language for frontend and backend have disappeared since you’re not writing the code anyway.

Yes, that entire stack is Open Source. Yes, if you build on that stack, and you need to migrate to AWS or GCP or Render or Azure or Oracle Cloud Infrastructure or Railway or Hetzner or a miniPC, you will be able to rsync the data and code over, and you’ll be all set. The platform-level lock-in is weak compared to low code platforms. (That said, an agent will port your low code setup to Linux with a few prompts.)

Exe.dev sells this very stack. Your subscription lets you create Linux VMs. They’re on the internet in the way that matters: you can send links to your friends, and the links will work. They are secure by default, and you can make sites public using our auth system or your very own. They’re fast. They’re great for coding agents. The way to build your custom software is to build it right there in prod with the coding agent. Iterate until you get something usable. Iterate some more with feedback from your co-workers. Let your co-workers iterate on it too; let them sand down the edges. If you give the coding agent the data model for your business and the workflows, and a hint about the stack maybe, it will do ok. If your project is in the 1 percent of projects that need to graduate to “Business Critical Very Important Stuff,” sure, start a second VM and a dev environment, or maybe even graduate to the confusing trappings of modern software development (git). An LLM running on a Linux machine is the ultimate in “low floor, high ceiling”: just get started, and you’ll perhaps be able to leave your spreadsheet in the dust.

Moving on to some relevant FAQs.

Is my data secure?

Yes. Our defaults are secure. The mechanics are very similar to a Google Sheet: you can share a VM’s web port with just your team or individual people or the world.

I have a spreadsheet or a low code solution already; how do I port it?

If you’re comfortable doing so, start the VM, visit the agent (ours is called Shelley and it’s pre-installed by default), and give it an API key to your existing solution or upload your spreadsheet. Tell it to port it over into a web application on this machine. It will. Today, use Sol or Opus as the model. Tomorrow, ask us on Discord; the answer changes kinda frequently.

How do I do schedules? Automations?

Linux is a rich platform. You can ask the agent to run something on a timer, and it will. (It will usually choose systemd, but if you have a preference for cron, nudge it in that direction, and if you don’t know what either of those are, that’s ok!)

How do I build agents or bots?

The same way: ask the agent to write an “agentic loop using the exe.dev LLM integration” with tools to do this and that. So, perhaps it reads Slack threads in a certain channel and comments on that. The agent will one-shot it.

One of the best things about the exe.dev platform is our “Integrations” system. Hooking up your bot to Slack has never been easier.

Is Vibe Coding good enough?

In my experience, yes. The usual thing is to measure Risk and Reward. Every spreadsheet formula is fragile and untested and so on; and yet, spreadsheets work! Same applies here.

Shouldn’t I use the Flue agent framework? Or maybe some framework from Langchain? Can I really just yolo it?

Use whatever frameworks you like, but, ultimately, the agents are fine at choosing their own, or just doing it the boring way. There are millions of conflicting best practices the world over, “P & L FINAL FY2025 FINAL VERSION 3” is still the median solution, and you should figure out your workflow needs first. Have the agent set up a cron job to back up the database somewhere, too.

How does your pricing work?

The basic plan for $20/month gives you up to 50 VMs, but they are limited to 2 CPUs and 8GB of RAM. This is enough for quite a few small apps targeted toward your team. If you need more resources, you can upgrade or ask us; we are happy to get you machines as big as you need. Building your app may take more LLM tokens than we provide as part of your subscription. You can hook up a ChatGPT subscription, use other coding agents, or other model providers, or we’re happy to give you the LLM at API token costs through us.

What if the app is slow? How do I test it?

I’ve found that the agents are surprisingly good at both testing their end result and fixing performance issues. They use the same tools I use: profilers and so on. Shelley’s secret weapon is a good browser tool that it’s capable of using, profilers, screenshots, screencasts, and all.