Daniel sent us this one — and it's actually two threads that connect in a really interesting way. First, he's been burned by Airtable. He built a significant internal tool for a nonprofit event in New York, and it became a case study in what Airtable can't do, especially when non-technical users need to interact with it. His takeaway: Airtable's front-end bolt-ons are second-best, and you're better off using it as a backend with your own front-end. That leads into the real question — for a two-person interior design business, if you're unfamiliar with frameworks like Vue, React, or Ruby on Rails, how do you actually choose? He wants us to solidify the major front-end families before we talk frameworks.
By the way, today's script is coming to us from DeepSeek V four Pro.
Alright, let's start with the Airtable war story because it's the perfect entry point. Daniel's experience isn't unusual — I've watched multiple small businesses walk straight into what I'd call the Airtable trap. It's not that Airtable is bad. It's that it's deceptively easy to start with, and the pain doesn't show up until you're already deeply committed.
The inflection point is the thing nobody talks about in the marketing materials. Airtable bases max out at a hundred thousand records on the free plan, and performance starts degrading well before that. But the real killer for a multi-user scenario — exactly what Daniel was dealing with at that nonprofit event — is the seating cost model. Paid plans bill per editor or creator seat, so if you need fifty volunteers to interact with the system, you're either paying for fifty seats or creating an elaborate maze of read-only views that still doesn't let people do their jobs.
That's where Daniel's point about the front-end bolt-ons being second-best really lands. Airtable Interfaces — their attempt at letting you build dashboards for non-technical users — work for basic internal views. But the customization is shallow, mobile support is weak, there's no custom login system or real user roles, and conditional logic is extremely limited. For a customer-facing portal or anything requiring granular control, it falls apart.
The permission model is the hidden landmine. Native roles are Owner, Creator, Editor, and Read-only. That's it. No row-level security, no field-level permissions. If you're building a client portal where different clients should only see their own projects, you can't do that natively. The workaround is what's called view sprawl — you create hundreds of filtered views, each locked to a specific client, and it becomes unmanageable fast. And even then, a technically curious user can sometimes poke around in browser dev tools and see data they shouldn't.
The pattern that's emerged — and this is what Daniel landed on — is use Airtable as the backend database and build your own front-end. That decouples the data layer from the presentation layer. You get Airtable's excellent spreadsheet-database hybrid for data management, but you control exactly how users interact with it.
This is where the framework question becomes real. Because once you decide to build your own front-end, you're staring at a landscape of options. But before we get to frameworks, I want to talk about something that's changed dramatically in the last year — the rise of AI-driven development tools specifically designed for people who don't know frameworks at all.
This is where the conversation gets genuinely interesting for that two-person interior design business. The traditional advice would be: learn a framework or hire a developer. But there's now a third path that didn't really exist in a usable form until recently.
Lovable is the one I've been watching most closely. It's an AI-powered builder that generates full-stack React and Tailwind applications from natural language prompts. You describe what you want in plain English, and it builds a working web app — with a database, authentication, the whole thing. People who've never written a line of code are building complete client portals and booking systems in hours, not weeks. And critically, it syncs with GitHub, so you actually own your code. You're not locked into a proprietary platform the way you are with Airtable Interfaces.
There's also Bolt, from StackBlitz, which is more developer-oriented. It gives you a full in-browser IDE with live previews, Node.js support, and direct deployment to Vercel or Netlify. But it requires more technical input than Lovable, and it has token limits that can halt generation mid-build. For someone non-technical, Lovable is the more accessible entry point.
What's fascinating is how these tools are collapsing the traditional framework decision. For a two-person interior design firm, the question isn't really React versus Vue versus Angular. The question is: do you use an AI builder like Lovable, or do you hire a freelancer? And if you hire a freelancer, you still need to know enough to specify what you want and evaluate what you get.
Let's do the thing Daniel actually asked for. Let's solidify the major front-end families, because even if you're using an AI builder or hiring a developer, you need to understand the landscape well enough to make an informed decision. I want to frame this around the actual needs of a small interior design business — they probably need a portfolio showcase, a booking or consultation scheduler, maybe a client portal where clients can see project progress and share feedback, and some kind of admin dashboard for managing projects internally.
Let's start with React, because it's the elephant in the room. React has about seventy-eight percent adoption among front-end developers. It has the largest ecosystem, the most jobs, the most tutorials, the most third-party libraries. If you're hiring a freelancer, saying React is the safest bet for finding someone qualified. It pairs with Next.js as the default meta-framework — and we should talk about -frameworks in a minute — for server-side rendering and search engine optimization.
React isn't lightweight. The bundles are larger than alternatives, there's overhead in re-renders, and there are notorious stale closure issues that can trip up even experienced developers. For a small interior design site that's mostly static pages with a booking form and a client login, React might actually be overkill.
That's the tension. Industry consensus in twenty twenty-six is that you should never use vanilla React alone — you always pair it with Next.js, which handles routing, rendering optimization, and a bunch of production concerns out of the box. But that means you're not just learning React, you're learning the React ecosystem. js adds its own concepts and conventions. For a two-person team with no technical background, that's a steep climb.
Vue is the counterpoint. Vue adoption is around seventeen or eighteen percent, so it's smaller, but it's extremely lightweight — the core is about eighteen kilobytes, and apps tend to be ten to thirty percent smaller than equivalent React apps. The syntax is more intuitive for beginners, and it has a gentler learning curve. Vue pairs with Nuxt for full-stack features, similar to how React pairs with Next.
There was a really interesting piece on the DEV community comparing Vue and React specifically for small teams and Rails backends. The conclusion was that Vue's lighter weight and simpler learning curve translate directly to faster development speed and lower costs for small projects. If you're a two-person interior design business and you do end up hiring a developer, a Vue project will probably cost less and ship faster than an equivalent React project, simply because there's less complexity to manage.
That connects to something Daniel mentioned — Ruby on Rails. Rails has been around forever, and it still has a strong niche, especially for small teams that value convention over configuration. If you're building on Rails, Vue is actually the more natural front-end pairing. Rails and Vue share a similar philosophy of developer happiness and sensible defaults. React can work with Rails too, but it's more of a square peg in a round hole situation.
Let me round out the landscape. Angular is the enterprise option — built with TypeScript, two-way data binding, server-side rendering via web workers, and a very opinionated structure. It's powerful for large-scale single-page applications, but the learning curve is steep and the runtime is heavy. For a two-person interior design firm, Angular is almost certainly overkill. You'd be paying for complexity you'll never need.
Then there's Svelte, which takes a fundamentally different approach. Instead of shipping a framework runtime to the browser, Svelte compiles your code at build time into vanilla JavaScript with minimal overhead. The bundles are tiny, and it's consistently fast in benchmarks. SvelteKit provides the -framework features. The trade-off is a smaller ecosystem — fewer libraries, fewer tutorials, a smaller hiring pool. But for performance-sensitive projects, it's a strong contender.
This brings us to -frameworks, which is where the industry has landed in a way that's surprisingly recent. As of twenty twenty-six, the consensus is that you don't use a front-end framework alone anymore. You always pair it with a -framework — Next.js for React, Nuxt for Vue, SvelteKit for Svelte. These handle routing, server-side rendering, static site generation, image optimization, and a whole host of production concerns that you used to have to configure manually.
I want to pause on that because there's an interesting question about whether this consensus is better for small businesses or whether it's industry groupthink. -frameworks add their own layer of complexity and their own opinions about how things should work. For a simple interior design portfolio with a booking form, do you really need server-side rendering and incremental static regeneration? Or is the industry optimizing for the needs of large-scale applications and dragging everyone else along?
The counterargument is that -frameworks have matured to the point where the defaults are good enough that you get the benefits without having to think about them. js, for example, will automatically optimize your images, split your code, and pre-render static pages where possible — all without configuration. For a non-technical business owner, having those optimizations handled automatically is arguably better than having to learn about them and configure them manually.
That assumes the -framework's defaults match your use case, and that when something breaks — which it will — you or your developer can debug it. The debugging surface area is larger with a -framework because there's more magic happening under the hood.
That's a real trade-off. And it's one of the reasons I think the Lovable and Bolt approach is so compelling for the specific scenario Daniel is describing. These AI builders generate production-ready React and Next.js code with Tailwind for styling. You get the benefit of the industry-standard stack without having to understand the internals. And because the code syncs to GitHub, if you eventually outgrow the AI builder and need to bring in a professional developer, they're working with a standard codebase, not some proprietary black box.
Let's make this concrete for the interior design scenario. Say you're running a two-person firm. You need a website that showcases your portfolio with high-quality images, lets potential clients book consultations, gives existing clients a login where they can see project timelines and share feedback, and gives you an internal dashboard for tracking projects and invoices. What does the actual decision tree look like?
Path one: you use Lovable. You describe what you want in natural language. It generates a React plus Next.js plus Tailwind application with Supabase handling the backend database and authentication. You iterate by chatting with the AI — change the booking flow, add a new field to the client portal, adjust the portfolio layout. You deploy to Vercel with one click. Total cost: Lovable's subscription fee, maybe twenty to fifty dollars a month, plus Supabase's free tier which is generous enough for a small business. Time to working prototype: potentially a weekend.
The catch with path one is that you're still operating a piece of software. When something goes wrong — a booking disappears, a client can't log in, the portfolio images aren't loading — you need to troubleshoot. Lovable gives you error messages and can often fix issues when you describe them, but you're still the person in the middle. For some business owners, that's fine. For others, it's a non-starter.
Path two: you hire a freelancer. You specify React plus Next.js plus TypeScript plus Tailwind in the job post — that's the standard twenty twenty-six production stack. You test candidates with a small prototype, maybe a single page from the portfolio with the booking form, and you emphasize accessibility and mobile-first design. Budget for a developer who's familiar with AI tools like GitHub Copilot or Lovable itself to accelerate the build. A competent freelancer working with these tools can build a full client portal and booking system in a few weeks.
The advantage of path two is you get a human who understands the system end to end and can handle edge cases. The disadvantage is cost — you're paying freelance rates, and you'll need ongoing maintenance. Dependencies update, APIs change, browsers evolve. If you build a custom application, you're committing to maintaining a custom application.
Path three is a hybrid: you use Lovable to generate the initial version, get it working, and then hire a freelancer to review the code, fix any issues, and handle ongoing maintenance. This gives you the speed and low cost of AI generation with the safety net of professional oversight. And because the code is standard React and Next.js, any React developer can pick it up.
I think there's a path four that's worth mentioning, which is the no-code platform route. Noloco, for example, integrates natively with Airtable and Google Sheets, provides row-level security and workflow automation, and doesn't require you to manage your own database. For someone already comfortable with Airtable as a backend, Noloco or Softr can give you a much better front-end experience than Airtable Interfaces without requiring you to learn a framework or hire a developer.
Noloco specifically solves the permission problem that burned Daniel. It has proper row-level security, so you can build a client portal where each client only sees their own projects, without the view sprawl nightmare. And it syncs in real time with Airtable, so your data stays where it is. The trade-off is you're adding another subscription and another platform dependency.
That dependency is arguably less risky than a custom codebase that only one freelancer understands. If Noloco disappears, you still have your data in Airtable and you can migrate to another front-end. If your custom React app breaks and your freelancer is unavailable, you're stuck.
Let's circle back to the framework families and solidify what Daniel asked for. I'd group them into three tiers for a small business scenario. Tier one, the safe bets: React with Next.js, and Vue with Nuxt. React has the ecosystem and hiring advantage. Vue has the simplicity and lower overhead. Both are production-proven and well-supported.
Tier two, the specialists: Svelte with SvelteKit for when performance is critical, and Ruby on Rails with Hotwire or Vue for teams that prefer convention over configuration and want a monolithic full-stack framework. These are excellent tools but have smaller communities.
Tier three, the overkill: Angular for enterprise-scale applications, and vanilla everything — no framework at all — which made sense in twenty fifteen but is hard to justify today given how much -frameworks handle automatically.
Then there's the tier zero, which didn't exist in a meaningful way two years ago: AI-generated applications where you don't choose a framework at all, you choose a prompt interface. Lovable and Bolt abstract away the framework decision entirely. You're building in React whether you know it or not, but you don't need to care.
I want to dig into that point because it's the most consequential shift for non-technical founders. The traditional advice was: learn enough HTML, CSS, and JavaScript to be dangerous, then pick a framework and learn that too. That's hundreds of hours before you've built anything useful. The new advice might be: learn to prompt an AI builder effectively, learn to read the code it generates well enough to spot obvious problems, and learn enough about deployment and hosting to get your app live. That's a different skill set, and it might have a higher return on investment for a busy business owner.
The counterpoint — and I'm going to push on this because it needs to be said — is that prompting an AI builder effectively is its own skill, and it's not trivial. You need to be precise about what you want, you need to understand enough about how web applications work to describe the right things, and you need patience for the iterative back-and-forth when the AI misunderstands you or generates something that's almost right but not quite. It's faster than learning to code from scratch, but it's not magic.
No, it's definitely not magic. But compare it to the alternative for Daniel's interior design firm. Option A: spend six months learning React and Next.js and Tailwind and Supabase and deployment, then spend another two months building the app, all while running a business. Option B: spend a weekend with Lovable, get something working, iterate over a few weeks, and have a functional client portal by the end of the month. Even with the friction of learning to prompt effectively, option B is orders of magnitude faster.
That speed matters for a small business in a way that's different from a startup or an enterprise. A two-person interior design firm isn't trying to scale to millions of users. They're trying to solve an immediate operational problem — clients need to see their project status, the current system of email and text messages is chaotic, and they need something better before they lose a client or drop a ball on a project.
Which brings us back to Daniel's Airtable experience. The reason that nonprofit event tool became a case study in limitations is that Airtable made it easy to start and hard to finish. The initial build was fast, but the moment real users with different permission levels needed to interact with the system, the limitations became structural. You can't fix a missing permission model with more filtered views. You can't fix seating costs by optimizing your base design. At some point, you have to migrate to a real front-end.
The question Daniel is implicitly asking is: at what point does the cost of migrating out of Airtable exceed the cost of building right the first time? For a two-person interior design firm, I'd argue the inflection point comes earlier than you think. If you know from day one that you'll need a client portal with per-client access control, don't build it in Airtable Interfaces. Either use Airtable as a backend with Noloco or Softr on top, or go straight to a custom front-end with Lovable or a freelancer.
The flip side is that Airtable is excellent as a collaborative database for internal use. If your users are just you and your business partner, and you're tracking projects and inventory and client communications, Airtable's core product is fantastic. The problems only emerge when you need to expose that data to external users with different permission levels. That's the line.
There's one more angle I want to explore before we move to practical takeaways. Daniel mentioned Ruby on Rails in his prompt, and I think there's a specific use case where Rails still shines for small teams. Rails has this philosophy of convention over configuration — it makes decisions for you about project structure, database access, routing, and a dozen other things. For a solo developer or a tiny team, those conventions are a force multiplier. You spend less time on configuration decisions and more time on the actual business logic.
Rails has evolved significantly. Hotwire, which is Rails' modern approach to front-end interactivity, lets you build responsive interfaces without writing much JavaScript. You send HTML over the wire instead of JSON, and the front-end updates automatically. For an interior design portfolio and booking system, Hotwire might be all you need — you get the interactivity without the complexity of a separate front-end framework.
The trade-off with Rails is the hiring pool. There are fewer Rails developers than React developers, and they tend to be more expensive because they're more experienced on average. But for a project that a single developer can build and maintain, Rails plus Hotwire or Rails plus Vue is a combination that can be extremely productive.
Let me pull together what I think the actual decision framework looks like for Daniel's two-person interior design scenario. Question one: do you want to write code or not? If not, your options are Lovable, Bolt, or a no-code platform like Noloco. Lovable gives you the most flexibility and code ownership. Noloco gives you the tightest Airtable integration and the simplest setup.
Question two: if you're hiring a developer, what's your priority? If it's finding someone quickly and having the largest possible hiring pool, specify React plus Next.js plus TypeScript plus Tailwind. If it's minimizing complexity and long-term maintenance burden, consider Vue plus Nuxt or Rails plus Hotwire.
Question three: what's your growth trajectory? If you're going to stay a two-person firm forever and just need a functional client portal, optimize for simplicity. If you might grow to ten or twenty employees and need more sophisticated internal tools down the line, invest in a stack that scales — React and Next.js are the safest bet for future extensibility.
Question four, which I think is the one most people skip: what's your tolerance for platform risk? Every choice is a bet on a technology staying relevant and supported. React and Next.js are backed by and Vercel respectively — they're not going anywhere. Vue is driven by its community and Evan You's team — smaller but sustainable. Rails has been around for two decades and will probably be around for two more. Lovable and Bolt are startups — they could be acquired, pivot, or shut down. The code they generate is standard and portable, but the tool itself is a dependency during development.
Now: Hilbert's daily fun fact.
The average cumulus cloud weighs about one point one million pounds — roughly the same as a hundred elephants floating above your head.
Alright, let's get practical. For the listener who's in a similar situation to Daniel — running a small business, needs internal tools, trying to navigate this landscape — here's what I'd actually do. Step one: if you're already in Airtable and it's working for your internal use, keep it. But the moment you need to give external users access — clients, contractors, event volunteers — stop building in Airtable Interfaces. Move to a proper front-end layer.
Step two: before you commit to learning a framework or hiring a developer, spend a weekend with Lovable. Describe your client portal or booking system in plain language. See what it generates. You might discover that an AI builder can handle eighty percent of what you need, and the remaining twenty percent is either not critical or can be handled manually for now.
Step three: if you do hire a developer, be specific in your job post. Don't just say "web developer needed." Say "React, Next.js, TypeScript, and Tailwind developer needed for a small business client portal and booking system." Test candidates with a small paid prototype. Look for someone who uses AI tools in their workflow — it's a signal that they're efficient and current.
Step four: budget for maintenance. A custom application isn't a one-time cost. Dependencies need updating, security patches need applying, browsers evolve. If you can't afford ongoing maintenance, lean toward no-code platforms where the platform handles updates for you. Noloco, Softr, or even sticking with Airtable and accepting its limitations might be the pragmatic choice.
Step five: own your data. Whatever front-end you choose, make sure your data lives somewhere you control and can export. Airtable lets you export to CSV. Supabase is open-source Postgres — you can migrate anytime. Lovable syncs to your GitHub. Avoid platforms where your data is locked into a proprietary format with no export path.
I think the deeper shift here is that the framework question is becoming less important for small businesses at the same time that it's becoming more standardized for professional developers. The industry has converged on React and Next.js as the default. But for a non-technical founder, the real question is whether you need to care about frameworks at all, or whether you can use AI tools and no-code platforms to solve your problems without ever touching a line of code.
That's where Daniel's Airtable experience is instructive in a broader sense. The lesson isn't "Airtable is bad." The lesson is that tools optimized for ease of starting are not always optimized for ease of finishing. The same could be true of AI builders — we don't have a decade of experience with them yet. They might be the Airtable of twenty twenty-six: incredibly easy to start with, but with unknown long-term limitations that only become visible when you push against them.
The counterpoint is that AI builders generate standard, portable code. If you hit a limitation with Lovable, you take your React and Next.js codebase to a human developer and they continue where the AI left off. That's fundamentally different from hitting a limitation in Airtable Interfaces, where your only option is to rebuild from scratch on a different platform.
That portability is the safety valve. It's what makes the AI builder path lower-risk than it looks. You're not betting on Lovable the company. You're betting on React and Next.js, which are about as safe a bet as exists in front-end development right now.
To answer Daniel's question directly: the major front-end families are React with Next.js, Vue with Nuxt, Svelte with SvelteKit, and Angular. For a two-person interior design business, React with Next.js is the safe default if you're hiring a developer. Vue with Nuxt is the lighter-weight alternative that might save you time and money. And if you're not hiring a developer at all, Lovable or a similar AI builder is the fastest path to a working application without needing to understand the frameworks underneath.
One final thought. The reason Daniel's prompt resonated with me is that it captures a moment of genuine change in how software gets built. For decades, the answer to "how do I build a custom tool for my business" started with "learn to code or hire someone who can." That answer is still valid, but it's no longer the only answer. The barrier between having an idea and having working software is lower than it's ever been. The challenge now is navigating the abundance of options without getting paralyzed or making a choice you'll regret.
Thanks to our producer Hilbert Flumingtop for keeping this show running. This has been My Weird Prompts. Find us at myweirdprompts dot com or wherever you get your podcasts.
Until next time.
