Daniel sent us this one. He's asking about infrastructure and tooling for a small business, specifically a two-person interior design practice. They have these typical but niche needs — they need to share renders with clients, manage projects, collaborate — and nothing off-the shelf fits their size or their exact workflow. He's seeing a trend where companies are increasingly rolling their own internal tools, and he's curious about options like Airtable or Firebase. He even advocates for what he calls an AI agent development-led approach to avoid vendor lock-in, though he admits it's more work. The core question is, what would we recommend?
Right, and this isn't just an interior design problem. I was just reading a piece from the Small Business Tech Survey last year — it found sixty percent of small businesses reported dissatisfaction with off-the-shelf SaaS tools for their niche needs. That's a huge number.
So most small business owners are staring at some generic project management dashboard thinking, "This is not how my brain works.
They're either paying for bloatware with features they'll never use, or they're duct-taping three different apps together and hoping nothing breaks. The frustration is real and it's widespread.
By the way, today's episode is being powered by deepseek-v3.
A solid choice for a technical deep-dive. So, where do we even start with this? Because the instinct to just build your own thing is getting more and more tempting.
Let's start with the pain point itself. Imagine you and I are running Corn and Herman Interiors. We've got a client for a kitchen remodel. We create these beautiful 3D renders. Now, we need to get them to the client, get feedback, track revisions, maybe even take approvals. What do we use? Email chains that get lost? A shared Google Drive folder that becomes a mess? Some enterprise-grade architecture software that costs a thousand dollars a seat?
That's just one workflow. Then there's sourcing materials, tracking budgets, communicating with contractors, managing the project timeline. Every single one of those steps has a dozen SaaS solutions yelling at you to sign up.
None of them talk to each other. None of them respect the unique way you, as a specialist, actually move through a project. So the question becomes: do you keep patching the holes, or do you just build a better boat?
I think that's the tension Daniel is pointing at. And the 'why now' is because the tools to build your own boat have gotten dramatically better and more accessible in the last few years. It's not about writing a million lines of code from scratch anymore.
What makes the existing boats, the off-the-shelf options, so inadequate for a small, niche operation like this? Because if I had to guess, it’s a mismatch of scale and specificity—but I’d love to hear your take.
The inadequacy usually comes from that mismatch. Large, generic tools are built for the broadest possible user base. They have to accommodate a marketing agency, a software team, a construction crew. So their data models are flexible, but in a generic way. They'll have a 'file upload' field, but not a 'client render version three with approval status' field.
So you're constantly translating your business logic into their generic containers. You're calling a render a 'file', a client approval is a 'checkbox', the entire context of your workflow gets flattened. It creates cognitive overhead.
The tools built specifically for interior design? They're often massive, expensive suites designed for large firms. You're talking about full-blown CAD integration, complex billing modules, vendor databases with thousands of entries. For a two-person shop, that's overwhelming overkill. You're paying for a battleship when you need a nimble sailboat.
You get the worst of both worlds. The generic tools don't understand your domain, and the domain-specific tools assume you have an entire department to manage them. The niche in the middle is completely hollow.
Which leads us directly to the pain points Daniel mentioned. Client render sharing is a perfect example. A generic file-sharing tool doesn't track which client saw which version, or capture feedback in a structured way tied to that specific image. A design-specific tool might have that, but it's buried inside a twenty-thousand-dollar-a-year platform.
Project management is the same story. You don't need the complexity of Jira for software sprints. You need to track a kitchen remodel from concept to installation, with dependencies like 'backsplash tile arrives' before 'countertop template can be made'.
That's a workflow you could probably map on a napkin. But try to force that into Asana or Monday.com, and you're spending more time configuring columns and automations than actually designing. The collaboration breaks down because the tool isn't speaking your language.
The 'roll your own' trend is essentially a reaction to this. When the gap between what you need and what's available gets too wide, and the cost of bridging it with manual work gets too high, building starts to look attractive.
It's gaining traction because the barriers to building have plummeted. We're not talking about hiring a dev team. We're talking about using platforms that give you a flexible data backbone and a way to slap a simple interface on top. The value proposition shifts from 'buy a solution' to 'assemble your own from higher-level components.
Which brings us back to Daniel's prompt. He's already name-checked the usual suspects for this approach: Airtable, Firebase. So the question isn't really 'should they build?' It's 'how should they build, and where do those tools fit in?
And when we look at those tools, Airtable and Firebase are practically the poster children for this 'assemble your own' movement. Airtable pitches itself as a spreadsheet that can do anything, while Firebase is Google's backend-as-a-service — bundling database, authentication, and hosting into one package.
They do address the custom need in a big way. You're not starting from zero. You get a flexible data structure immediately. For our interior design duo, they could spin up an Airtable base with tables for Clients, Projects, Renders, and Material Samples in an afternoon.
The power is in that flexibility. You can define a 'Render' record to have fields for the image file, the version number, a link to the client proofing page, a status dropdown for 'Pending Review', 'Approved', 'Needs Revision'. That's your workflow, codified.
Here's where they fall short for the niche scenario, and it's a subtle but critical distinction. Airtable gives you a database and a grid interface. It does not give you a tailored client portal. So when you need to share that render with the client, you're back to square one. You can generate a shareable grid view, but it's ugly and confusing for a non-technical client. Or you can build an interface on top of it with something like Softr or Glide…
…which is another layer of complexity, another subscription, and another point where the seams show. I saw a case study last week about a two-person design firm in Portland. They used Airtable brilliantly for internal project tracking. But for client sharing, they were still exporting renders, uploading them to a separate gallery tool called Pic-Time, and then manually updating the status back in Airtable.
That's the classic patchwork. You've solved the data problem internally, but the client-facing experience is a separate, disjointed system. The moment you need an interaction that doesn't fit neatly into a table row — like a beautiful, branded gallery where a client can click directly on an image to leave feedback — the generic platform starts to buckle.
Firebase has a similar profile. It's an incredibly powerful engine. You can build a real-time database where a designer updates a render and the client sees it instantly. You can build user logins for clients. But Firebase doesn't give you a frontend. You're committing to writing actual code, or using a framework, to create the user interface. That's a much steeper cliff for a non-developer.
The limitation of these traditional low-code or backend platforms is that they solve half the problem perfectly. They give you the Lego bricks, but they assume you're either okay building with just the bricks, or you're willing to combine them with other, more specialized Lego sets from other companies. The integration is always the weakest link.
That's the tradeoff in a nutshell. Off-the-shelf tools offer a complete, polished experience for a common use case. Airtable and Firebase offer incredible flexibility for the data part of your use case. But the complete, polished experience for your specific use case? That gap remains, and bridging it requires moving beyond configuration into actual construction.
That construction has its own cost. It's not just the time to build. It's the maintenance, the updates, the worry that your custom glue between Airtable and your image server will break. You've traded vendor lock-in for a different kind of lock-in: you are now your own IT department.
Which is why Daniel's point about an AI agent-led approach is so interesting. It's a way to think about that construction phase not as manual coding, but as directing a more capable assistant to assemble the pieces for you. But before we get to that, we should talk about the technical mechanism at the heart of this. The real magic isn't the tool, it's the data model.
The tailored workflow you mentioned.
The breakthrough for a small business isn't finding a tool that does everything. It's designing a data structure that mirrors how they work. Once you have that — a clear schema for Projects, Clients, Renders, Tasks, Materials — the choice of tool becomes secondary. You can implement that schema in Airtable, in a Firebase Firestore database, in a simple SQLite file even. The tool just becomes the access point.
The first step for any firm feeling this pain isn't "should we buy Airtable?" It's "can we map our actual process on paper?" If you can't define what a 'Render' is and what happens to it from creation to client approval, no tool in the world will save you.
And once you have that map, you can see exactly where the off-the-shelf tools leak—the points where you're copying data from one app to another, sending email reminders manually, or letting client feedback languish in text messages instead of with the project. Those pain points are begging for a custom solution, even a small one. Which is why...
...Daniel's AI agent angle becomes so compelling. If the real work is defining your process, not writing code, then an agent that can translate that map into a working tool changes the equation entirely.
An AI agent development-led approach means you're not manually connecting Airtable to a frontend builder. You're describing the outcome to an AI: "I need a client portal where they can view project renders, leave timestamped comments on specific images, and approve versions." The agent then figures out the technical assembly.
It avoids vendor lock-in because you're not buying a monolithic platform. You're using the agent to stitch together best-of-breed, often open-source, components. The logic and the workflow you defined are the valuable part, not the specific SaaS subscription.
And it provides flexibility because when your needs change — say you start offering virtual reality walkthroughs — you don't have to beg a vendor for a new feature. You update your process map and have the agent integrate a new component. A recent case study I saw involved a three-person firm in Austin. They used an AI agent framework, basically a tool for building tools, to create a custom client portal with Firebase for data and a simple React frontend.
Let me guess, they saved the twenty-thousand-dollar-a-year suite fee.
More than that. They reported saving about fifteen hours a week on administrative coordination and client follow-ups. Client satisfaction scores jumped because the portal was branded, intuitive, and kept everything in one place. The agent handled the initial scaffolding; they just had to provide their branding assets and approve the design.
What does this approach entail for a small business that isn't tech-savvy? I can hear listeners thinking, "I'm a designer, not a prompt engineer.
That's the critical shift. You're not writing code; you're being a very clear project manager. The practical steps start with what we already said: map your core workflows. Then, you identify the one or two most painful gaps. For our design firm, that's absolutely client render sharing and feedback. Don't try to rebuild your entire operation at once.
Start with the thorn in your side.
Then, you select tools based on what the AI agents can work with effectively. Firebase is a fantastic choice because it's a well-documented, standardized backend. An agent can easily generate the code to read and write data to it. For the frontend, you pick a simple, popular framework like React or Vue. The agent has seen millions of examples of how to build interfaces with those.
You're giving the agent common building blocks, not obscure, proprietary APIs.
The knock-on effect here is profound. A custom tool built this way scales with you. It's not a static product. When you hire your first employee, you can have the agent add user role permissions. When you add a new service, like sourcing antiques, you can add a new module. The tool evolves as a natural extension of your business logic, not as a foreign platform you have to contort yourself to fit.
Compared to patching together multiple off-the-shelf tools, this is a cleaner, more unified system. The patchwork approach always has data silos and manual sync steps. The custom approach, even if assembled by an agent, has one source of truth.
That justification for the additional effort comes down to time and sovereignty. The initial time investment in mapping your workflow and directing an agent might be forty hours. But if it saves you ten hours a week of friction, you're in the black in a month. And sovereignty means you own the system. You're not at the mercy of a startup pivoting or a giant corporation deprecating a feature you rely on.
It turns a cost center into a strategic asset. Your unique way of working becomes your operational software, which can be a real competitive edge against firms using the same generic tools as everyone else.
That's the ultimate point. For a small, niche business, your process is your intellectual property. Baking it into a tailored tool protects and leverages that IP in a way no off-the-shelf box ever could.
And that's why the first step for anyone feeling this pain should be mapping, not shopping. Don't even look at software websites until you've defined what makes your process unique.
Grab a whiteboard, or a notebook, and literally draw the lifecycle of your core service. For a designer, that's: client inquiry, initial consultation, concept development, render creation, client review, revision cycles, final approval, procurement. At each step, note what information is created, who needs to see it, and what decision is made.
Be brutally honest about where the friction is. Is it chasing clients for feedback over email? Is it losing track of which render version the client actually approved? That’s your target. A generic project management tool might track a task called "Client Feedback," but it won't solve the specific problem of managing visual feedback on image files.
The second step is to leverage platforms that are designed for customization, but choose based on where you need that flexibility. If your pain point is mainly data and workflow logic — like tracking project statuses, budgets, and client details — a tool like Airtable is a phenomenal starting point. You can build your entire operational backbone there.
If your pain point is a client-facing interaction, like the render sharing portal, that's where you graduate to something like Firebase. It’s a more serious commitment, but it gives you the raw materials to build a truly custom experience. And crucially, these platforms are well-documented and widely used, which means AI agents can work with them effectively.
The recommendation isn't to become a Firebase expert. It's to understand that Firebase is a suitable "construction site" for the AI agent to build on. Your job is to define the blueprint — the data schema and the user stories. The agent's job is to write the code that makes Firebase and a frontend framework do what you described.
What can a listener do this week? First, schedule ninety minutes to map one core workflow. Second, audit your current toolset. For every app you use, ask: does this bend to my workflow, or do I bend to it? Where am I doing manual work to bridge gaps between apps?
Third, take that identified pain point and research one potential building block. Don't look at full solutions. Look at components. If client portals are the issue, spend twenty minutes reading about Firebase Firestore databases or about simple React gallery components. You don't need to understand how to code them; you need to understand what they are, so you can better direct an agent.
That last point is key. The goal isn't to learn to code. It's to learn to specify. The more precisely you can describe the problem and the desired outcome, the better any tool — human developer or AI agent — can build the solution for you.
The justification for the effort comes back to those numbers we cited earlier. With sixty percent of small businesses dissatisfied with off-the-shelf tools, the competitive advantage is shifting to those who can craft their own. The initial investment of time pays off not just in hours saved, but in client satisfaction and in owning an asset that makes your business uniquely efficient — which raises an obvious question.
If this becomes the new normal for small, niche businesses — using AI agents to build custom tools — how does it change the playing field?
It democratizes capability in a way we haven't seen before. Think about it. For decades, the operational software advantage went to large corporations with big IT budgets. They could afford to build or heavily customize systems. Small firms made do with generic tools. But if a two-person design firm can have a tool that fits them perfectly, built for the cost of a few weeks of focused effort, that flips the script.
The potential is for small businesses to compete not just on personality or hustle, but on operational polish and client experience. A boutique firm could offer a client portal that feels more tailored and responsive than what a giant corporate design house provides, because theirs is built for their specific workflow from the ground up.
The future implication is that the 'tailored tool' becomes a core competitive asset, especially in service-based niches. It’s not just about efficiency; it’s about embedding your unique value proposition into the very software your clients interact with. That’s a moat that’s very hard for a competitor using the same off-the-shelf kit to replicate.
It makes me wonder if, in a few years, we'll see a market for pre-built, open-source 'business logic schemas' — like a starter pack of data models and agent instructions specifically for an interior design practice. You'd still customize it, but the heavy lifting of defining the core entities would be done.
I could absolutely see that. A community-driven library of blueprints. But the core principle remains: ownership and flexibility beat out-of-the-box convenience when your needs are specific. The rise of AI agents is just removing the final technical barrier.
That's a fascinating place to leave it. As always, a huge thanks to our producer, Hilbert Flumingtop, for keeping the microphones working and the sloth supplied with leaves. And thanks to Modal for providing the serverless GPUs that power our production pipeline — reliable compute without the infrastructure headache, which feels rather on-topic.
This has been My Weird Prompts. If you found this useful, the single biggest help you can give us is to leave a rating or review wherever you listen. It makes a real difference.
Until next time.
