Daniel's been thinking about something that came up in our episode on Twilio and WhatsApp Business — the whole category of Business Solution Providers. He said it struck him because it's a kind of software company he'd never really thought about before. Not exactly SaaS, not quite systems integrators, not just consultants — this interesting middle layer building products and services on top of larger platforms. And that got him asking about another overlooked category: internal tools. Here's what he wrote.
I'm a big fan of internal software. At a technical level, most internal applications are variations on a surprisingly simple theme — a user interface sitting on top of a database with business logic in the middle. Whether it's inventory management, a CRM, a ticketing system, an approval workflow, or a donor database, so many of these boil down to CRUD operations with domain-specific workflows layered on top. Historically, companies have had the option of buying large enterprise platforms like SAP, Oracle, Microsoft Dynamics, or Salesforce. More recently, low-code and no-code platforms like Airtable, Retool, Appsmith, Budibase, and others made it much easier to build bespoke internal applications without starting from scratch. Now, with AI-assisted development and agentic coding tools, it feels like we're entering yet another phase where custom software has become dramatically more accessible.
Then he gives a concrete example. He worked on a project for a nonprofit organizing events during UN Climate Week in New York, and ended up building what was effectively a completely bespoke internal platform. Part event management system, part CRM, part donor relationship manager, part email campaign platform, part internal support desk. There wasn't an off-the-shelf product that matched what they needed, so it evolved into a unique system assembled around Airtable with custom workflows and integrations. He says it was exhausting to build — but it demonstrated how many organizations have requirements that don't fit neatly into a single commercial product.
So his questions — and there are several. How common is it for medium-sized and large organizations to commission or build their own internal software rather than forcing workflows into commercial ERP or CRM platforms? Do large enterprises quietly have hundreds or even thousands of bespoke applications running behind the scenes? Where is the line between buying, customizing, and building? At what point does it make economic sense to develop something in-house? How do organizations think about maintenance, technical debt, security, and long-term ownership? And finally, how is generative AI changing this landscape — are we moving toward a world where internal software becomes increasingly disposable, and could AI fundamentally shift the balance away from buying generic enterprise software toward organizations owning much more of their own operational tooling?
So today we're going to pull back the curtain on the software that runs organizations from the inside, and ask whether AI is about to make building it the default.
Let's start by defining what we're actually talking about when we say internal tools — because they're everywhere, but we rarely name them. An internal tool is software built for an organization's own operations rather than for external customers. Inventory systems, CRMs, ticketing, approval workflows, donor databases, employee onboarding portals, expense tracking, scheduling — the stuff employees use to get work done. What makes them invisible is that they're never marketed, never sold, never demoed at conferences. Nobody puts "internal reimbursement approval system" on their resume as a product launch.
The shadow fleet.
And every organization sits somewhere on a spectrum. On one end, you buy a giant enterprise platform — SAP, Oracle, Salesforce — and you force your workflows into its shape. On the other end, you build everything from scratch. Almost nobody lives at either extreme. Most organizations are in the messy middle, customizing, extending, assembling. Daniel's UN Climate Week project is a perfect example of that middle ground — a purpose-built system assembled around Airtable that no single off-the-shelf product could match, because no product was designed to be an event manager and a CRM and a donor tracker and an email platform and a support desk all at once.
The core technical pattern really is what Daniel described. A user interface on top of a database with business logic in the middle. CRUD operations — create, read, update, delete — with domain-specific workflows layered on. That simplicity is what makes internal tools tractable for platforms like Airtable and Retool, and it's also what makes them tractable for AI-assisted development. But we'll get to that.
Before we get to AI, I want to understand the scale of what's already out there. Daniel asked whether large enterprises quietly have hundreds or thousands of bespoke applications running. What's the actual number?
The Retool State of Internal Tools report — which is kind of the canonical industry survey on this — found that enterprises typically run dozens to hundreds of internal applications. Not tens. Dozens to hundreds. And that's just what IT knows about. The real number, when you include shadow IT — departmental tools built outside official channels — is almost certainly higher.
Shadow IT being the stuff someone's department built in a spreadsheet that gradually mutated into a full application.
Right, the classic story. Someone in finance builds an Excel workbook with a few macros. Five years later it's a mission-critical forecasting system with three thousand lines of VBA and exactly one person who understands how it works. That person leaves. Panic ensues. I've seen this in hospitals — entire clinical scheduling systems running on Access databases that predate the electronic health record migration.
And nobody thinks about these as "software." They're just... the thing Janet built.
The thing Janet built. And Janet's thing is running a forty-million-dollar department. The scale of this is genuinely underappreciated. A Fortune 500 company might have a time-tracking tool built in 2005 that's still running because migrating to a commercial system would cost more than maintaining it. Not because the commercial system is bad — because the migration touches payroll, compliance, project accounting, and about fifteen other systems that all expect the data in exactly the format the 2005 tool produces.
So the build-versus-buy decision isn't really about upfront cost.
It almost never is. The real economic calculus has several layers. First, license costs per seat — that's the easy number. But then you have customization costs to force your workflows into the generic platform. You have integration costs to connect the new system to everything else you run. And the hidden one — the one that almost never shows up on the spreadsheet — is the cost of workflow mismatch. Employees fighting the tool instead of doing the work.
Give me a concrete number on that. What does fighting the tool actually cost?
Hard to isolate precisely, but think about it this way. If a sales team of twenty people each spends thirty minutes a day working around a CRM that doesn't match how they actually sell — exporting to spreadsheets, copying data between systems, manually reconciling — that's ten hours of lost productivity per day. At fully loaded compensation, that's hundreds of thousands of dollars a year. The license cost for the CRM might be eighty thousand. The hidden cost of mismatch is two or three times that, and it never appears in the procurement analysis.
So the spreadsheet lies.
The spreadsheet compares license costs. It doesn't compare how much of your organization's cognitive capacity is being burned on data entry that shouldn't exist.
But here's what I don't get. If building bespoke tools is so obviously better in many cases, why does the default tilt so hard toward buying? Daniel's asking where the line is — at what point does it make economic sense to build?
The answer has historically been: almost never, once you account for maintenance. That's the real reason organizations default to buying. Not upfront cost — long-term ownership. Who maintains it? Who understands it when the original builder leaves? Who patches security vulnerabilities? Who onboards new employees onto a system that has no documentation because it was built by one person over three weekends in 2019?
The bus factor.
The bus factor. If your internal tool depends on one developer and that developer gets hit by a bus — or, more likely, takes a job at a startup — the tool becomes a liability. And in a large organization, you might have dozens or hundreds of these liabilities. The CIO's nightmare isn't the SAP implementation that went over budget. It's the forty-seven shadow IT applications that nobody has inventoried, each one quietly running some critical process and each one one retirement away from catastrophic failure.
So the build-versus-buy decision has always been: buy is more expensive upfront and a worse fit for your workflow, but someone else carries the maintenance burden. Build is cheaper upfront and a perfect fit, but you own the maintenance forever.
That's the traditional calculus. And it's why most organizations bought. The maintenance tail was just too long and too unpredictable. You could budget for Salesforce licenses. You couldn't budget for the unknown cost of keeping a custom tool alive for fifteen years.
But then something changed.
Two things changed. First, the low-code and no-code platforms — Airtable, Retool, Appsmith, Budibase — they made the CRUD layer nearly free. You're not building a database from scratch. You're not writing authentication. You're not handling deployment and hosting. The platform does all of that. What's left is the domain-specific workflow logic — the actual business rules that make your organization different from every other organization. That's where the value is, and that's what you build.
And second?
Second is generative AI. But let's sit with the low-code inflection for a minute, because it's important. Daniel's UN Climate Week project was built on Airtable. That's not an accident. Five years earlier, building that same system would have meant standing up a database, writing an API layer, building a front end, handling authentication, deploying somewhere, monitoring it. Months of work. With Airtable, the database, the API, the auth, the hosting — all handled. He could focus on the workflows, the integrations, the business logic. Still exhausting, as he said, but possible for one person in a reasonable timeframe.
And that's the pattern. The low-code platforms didn't eliminate the build-versus-buy tradeoff — they shifted where the line is drawn. More things became worth building because the platform ate the maintenance burden for the commodity layers.
The commodity layers being... database, auth, hosting, UI framework.
The stuff every application needs and nobody wants to build again. The platform handles that. You handle the part that's specific to your organization. And the part that's specific to your organization is mostly business logic and data modeling.
Which brings us to the thing that actually makes or breaks these projects. Data modeling.
This is where most internal tool projects fail. Not the code — the schema. If you get the data model wrong at the start, you spend the rest of the project fighting it. Every new feature is harder than it should be. Every report requires contortions. And the thing about data modeling is that it's not a technical skill — not primarily. It's a domain understanding skill. You have to know what the organization actually does, what information flows where, what relationships matter. If you model donors as contacts with a donation history attached, but the organization actually thinks of donors as relationships that span multiple campaigns with different engagement patterns... you've built the wrong thing, and you won't know it until month three.
So the hard part of internal tools was never the CRUD.
Never. CRUD is trivial. The hard part is figuring out what the workflow actually is. And that's a human problem. You have to sit with stakeholders, watch how they work, ask questions they've never thought to ask because the workflow is just "how we do things." Then you have to translate that into a data model that captures the real structure of the work, not just what people say they do.
Which is why off-the-shelf software fails so many organizations. It encodes someone else's data model.
Someone else's assumptions about how work works. Salesforce assumes a particular sales process. SAP assumes a particular way of thinking about supply chains. If your organization matches those assumptions, great — the platform fits. If it doesn't, you're in the customization trap, bending your workflows to match the software instead of the other way around.
And the customization trap is expensive in ways that don't show up on the invoice.
It's the most expensive kind of technical debt, because it's not even your debt. You're paying to work around someone else's design decisions.
Okay, so that's the current state of the world. The low-code platforms shifted the line — more things became worth building because the commodity layers were handled. But Daniel's real question is about what happens next. Generative AI. Agentic coding tools. Are we about to see another shift, and how big?
Here's where it gets interesting. The cost of building a bespoke internal tool has collapsed. AI-assisted coding tools can generate the CRUD scaffolding, the UI, and much of the business logic in hours instead of weeks. What used to take a developer a month — standing up a basic internal application with forms, tables, some workflow logic — can now be done in an afternoon. Not perfectly, not production-ready necessarily, but directionally correct and fast enough to iterate on.
So the economic threshold shifts again. More things cross the line into "worth building."
Dramatically more. Take Daniel's grant-tracking example. A mid-sized nonprofit needs a system to track grant applications, deadlines, reporting requirements, funder relationships. Previously, the choice was a ten-thousand-dollar-a-year SaaS subscription for something generic, or a three-month custom build. With AI-assisted development, the custom build might take a week. At that point, the SaaS subscription doesn't just look expensive — it looks like the wrong answer entirely, because you're paying indefinitely for something that doesn't quite fit, when you could have a perfect fit for a one-time build cost measured in days.
But the maintenance problem doesn't go away. If anything, it gets worse.
That's the tension. If building becomes nearly free, you get proliferation. Every department builds its own tools. Every team has a collection of AI-generated applications. And suddenly the CIO isn't worried about forty-seven shadow IT apps — she's worried about four hundred.
Which is where the disposable software idea comes in. Daniel asked whether we're moving toward a world where internal software is built quickly for a specific process, evolved as requirements change, and replaced when no longer needed — rather than maintained for a decade.
I think that's exactly where we're heading, but it requires a mindset shift that most organizations haven't made yet. The traditional model treats software as an asset — you build it, you maintain it, you depreciate it over time. The disposable model treats software as... almost like a document. You create it for a purpose, you use it, you update it when needed, and when the purpose changes you replace it. You don't maintain a memo for ten years. You write a new one.
The memo analogy is interesting. But a memo doesn't have a database full of customer data.
Right, and that's the catch. The data outlives the application. The application might be disposable, but the data model needs to persist. Which brings us back to data modeling being the skill that matters. If you've designed the schema well, you can replace the application layer without losing or corrupting the data. If you haven't... you're stuck with the application forever because it's the only thing that understands the data.
So the new bottleneck isn't writing code. It's requirements gathering, data modeling, understanding the domain.
And that's still deeply human. AI can generate a CRUD app from a prompt. It cannot sit in a room with your operations team and figure out that when they say "donor" they actually mean three different things depending on context, and that the reporting requirements are driven by grant compliance cycles that nobody thought to mention because they're just part of the annual rhythm.
The AI doesn't know what questions to ask.
The AI doesn't know what it doesn't know. And domain experts often can't articulate their own workflows because the workflows are tacit knowledge. They're "how we do things." Extracting that, formalizing it, translating it into a data model — that's the new superpower. Eliciting.
So the skill that matters most shifts from technical implementation to something closer to anthropology.
Organizational anthropology with a database design bent. I'd hire that person.
Let me push on something. If anyone can spin up an internal tool with AI assistance, what stops organizations from drowning in unmaintained, unpatched shadow IT? The governance problem seems enormous.
It is enormous, and it's the thing that keeps CIOs up at night. The answer isn't going to be technical controls — you can't block people from using AI tools any more than you could block them from using spreadsheets. The answer has to be governance models. Organizations need to establish, before the proliferation happens, who owns maintenance, how security is reviewed, when a tool gets retired, where the data lives, what happens to the data when the tool is decommissioned.
The disposable software future only works if disposal is actually planned.
Planned and practiced. You need a lifecycle for internal tools that includes a retirement phase. Most organizations don't have that. They have procurement processes for buying software and development processes for building software, but they don't have retirement processes for the tools that have outlived their purpose. Those tools just... persist. Forever. Running on some server nobody remembers, consuming resources, accumulating vulnerabilities.
The zombie application problem.
And AI makes it worse because it lowers the barrier to creating new zombies. The governance has to catch up.
Let's zoom out. Daniel's last question was whether AI could fundamentally shift the balance away from buying generic enterprise software and toward organizations owning much more of their own operational tooling. What's the end state?
I don't think we're heading for a world where organizations build everything themselves. The core systems — the ERP, the financial ledger, the payroll — those will still be bought. The compliance requirements alone make building your own payroll system a terrible idea for almost everyone. But the long tail of niche workflows? The event management system that's also a CRM that's also a donor tracker? That's where building becomes the default.
So a hybrid. Core systems bought, long tail built.
And the long tail is longer than most people think. If you map out all the workflows in a mid-sized organization, the core platforms cover maybe thirty percent of them. The other seventy percent are handled by spreadsheets, email, shared drives, and the informal systems that people invent to get work done. That seventy percent is the opportunity. That's where AI-assisted internal tools live.
And this connects back to the BSP pattern Daniel noticed. Business Solution Providers occupy a middle layer building on top of platforms like Twilio. AI-assisted internal tooling creates a similar pattern — organizations building on top of low-code platforms and AI code generators. Platform plus bespoke layer.
The same architecture at a different scale. The platform handles the commodity — messaging infrastructure, database, auth. The bespoke layer handles the domain-specific value. And the bespoke layer gets thinner and faster to build as the tools improve.
What does this mean for the enterprise software industry? If building becomes the default for the long tail, does the industry shrink, or does it just move up the stack?
It moves up the stack. The platforms that survive won't be selling finished applications — they'll be selling platforms that organizations build on top of. Salesforce already understands this; that's why they've invested so heavily in their platform capabilities. The value isn't in the CRM anymore — it's in the ecosystem of custom applications built on the CRM data model.
The enterprise software company of the future looks more like AWS than like SAP.
It looks like a platform with a marketplace. Provide the infrastructure, the data layer, the security model, the compliance certifications — and let your customers build whatever they need on top. Charge for the platform, not the application.
Which is already happening with the low-code platforms. Airtable's marketplace, Retool's component library.
AI accelerates it. Because now the platform doesn't just provide building blocks — it can help you assemble them. "I need a grant-tracking workflow that integrates with our existing donor database and sends reminder emails thirty days before reporting deadlines." The platform generates the application. You tweak it. Done.
Okay, so if this is where things are heading, what should people actually do about it? Let's get practical.
Three things. First, when you're evaluating build versus buy, stop comparing just license costs. Calculate the cost of workflow mismatch — employees fighting the tool. Calculate the total cost of ownership including maintenance. And now factor in the dramatically reduced build cost with AI assistance. The spreadsheet looks different when you do all three.
Second?
Start with the data model, not the UI. The reason most internal tool projects fail is poor data modeling. Get the schema right and the CRUD layer almost builds itself, especially with AI help. Spend the time upfront understanding the domain, the entities, the relationships. That investment pays off for the life of the system.
And third?
Establish governance before you need it. Decide who owns maintenance for AI-built tools, how security is reviewed, when a tool gets retired. If you wait until you have fifty of these things running, it's too late. The governance has to be in place before the proliferation starts.
For individual practitioners — the person who's going to be building these things — what's the skill to develop?
Requirements gathering and domain modeling. The ability to sit with stakeholders, extract the actual workflow, and translate it into a data model. Coding is becoming the easy part. Understanding what to build is the hard part, and it's not going to be automated anytime soon.
Before we wrap up, there's one bigger question hanging over this whole conversation. If building internal tools becomes nearly free, does the enterprise software industry itself become obsolete — or does it just move up the stack to more complex problems?
It moves up the stack. The industry doesn't disappear — it transforms. The value shifts from providing finished applications to providing platforms, data infrastructure, compliance, security, and the governance layer that makes AI-built tools safe to deploy. Someone has to certify that the grant-tracking tool your AI generated isn't leaking donor data. Someone has to ensure the payroll integration is actually calculating withholdings correctly. Those problems don't go away — they become more important.
I'd add one thing to watch. Internal tool marketplaces. If organizations are building bespoke tools for their own workflows, some of those tools will be useful to other organizations with similar needs. We're going to see platforms where organizations share or sell the tools they've built. Not SaaS — more like templates with data models and workflow logic that can be adapted.
AI agents that can build and maintain their own operational tooling. That's the next horizon. An agent that notices your team is spending too much time on manual data entry, proposes a tool to automate it, builds it, deploys it, and monitors it. That sounds like science fiction, but we're not that far away.
The misconception I want to nail down before we close: internal tools are rare or unusual. They're not. Large enterprises quietly run hundreds or thousands of bespoke applications that employees never think twice about. They're the invisible plumbing of most organizations, and the build-versus-buy calculus that's governed them for decades is being rewritten in real time.
The rewrite isn't just about cost. It's about fit. Organizations have always known that custom tools fit better. What's changing is that the cost of that fit has dropped from prohibitive to trivial. That's the real story.
If you've built an internal tool that no one outside your company will ever see, we want to hear about it. Send us your weird prompts — the address is show at my weird prompts dot com.
Thanks to our producer Hilbert Flumingtop. This has been My Weird Prompts.
We'll be back soon.
