Single Use Software
A tool just for you, just for this time
I recently wrote about vibe coding and how the paradigm around investment in software engineering has changed, as have others. I’ve been thinking that software products today are so big and bloated because they have to appeal to so many different customers and meet so many different sets of needs, using only one product.
Until now, creating software products has been difficult and expensive. The idea of a company choosing to build its own BI tool, ELT tool, or Data Warehouse has seemed outlandish and is often considered foolish unless the company is large enough that this doesn’t apply, or is in the business of building such tools.
This is now beginning to sound like an era of the past. What if, at some point soon, you could write a PRD to define just the features of a BI tool that your company needs? It doesn’t need to support LDAP, SSO and Okta; it only needs to support Okta, because that’s what your company has. It doesn’t need row-level security because your company isn’t a large listed company with strict access to data; everyone has access to all your company data as long as they work there.
What if your company doesn’t use horizontal bar charts and your CEO has outright banned them? Well, then your BI tool doesn’t need to support them. In fact, it only needs to support the chart types that your company wants. Don’t like log scales? Don’t need’em then. Your BI tool only needs to connect to your data warehouse, instead of the 100 possible databases and data warehouses that could be used by any company anywhere. Your BI tool doesn’t need to support iframing or embedding, because your company doesn’t do that. Your BI tool doesn’t need to support integrations with data catalogs, because your company thinks they’re a waste of money and your CFO would never let you buy one….
You get the picture - you come down to the exact specifications of a tool that just your company needs and work with AI to build that exact tool, and within hours or worst, days, you have the tool you need. No vendor selection process, no tender, no RFPs, no infosec review, no big meeting with senior people to decide to go or no go. Just build what you want to meet your needs. The build vs buy scales are tipped towards build.
Many of you think this is still outlandish, and it probably is today, but I actually think with the lower complexity tools we use today…. it’s not. Using the dlt framework and AI, I think most companies could build their own ELT tool that just connects to the APIs they care about already.
Query engines are more complicated in the stack, which is why we pay the most for them; they will be the last to go. But imagine if we created a new query engine for every query. Some data scientists used to do this before Pandas. They would take a dataframe and perform different operations on it without pre-defined functions to achieve a goal; this is a bespoke query. It was expensive and has fallen out of favour because of how time and labour-intensive it was, and how the software often wasn’t that efficient. But now it’s cheap and fast to do. Imagine a data agent which writes a set of Polars transforms on the fly, to answer any given query of a dataset. What if it didn’t even need to use Polars or Pandas and just operated on a data array?
BI tools aren’t that complicated; they are complicated because they have had to cope with so many different organisations’ needs. But it could be incredibly simple if your BI tool only had to deal with your company’s needs. The same is true for orchestrators; the perfect orchestrator for your company would be incredibly simple.
If you take this idea of simplicity even further - each time you want to do something, you probably have a relatively simple goal, but you end up using a massively complicated piece of software that can help you achieve your goal, again for the reasons above. However, if we stop thinking this way and ask the LLM to do something, let it write the simplest viable software to do that, and then run it… Nothing more than this. Think about how simple that software could be.
Imagine wanting to do an email campaign. You ask the LLM to execute an email campaign where you want to use templated content for a given list of emails, with call to actions with specific URLS to click through for each. There are things you have to provide, like the list of emails, the content template (although you could also get the LLM to generate this) and the CTA URLS. These things are all data. With the minimum required data to perform a single action, it is perfectly possible to vibe code a piece of software to execute just that one task, at this one moment in time, and then never touch it again. Don’t commit it to GitHub, don’t save it as a text file on your Google Drive, click the cross on your IDE tab or window, click don’t save on the pop-up… move on.1
Do we even need to vibe code at this point? What if we ask an AI agent to generate some content to the effect we want, and send it to everyone on a list of emails in a personalised way?2 Maybe instead of providing a list of emails, we could describe the segment we want? All of the contacts we met at our booth at Gartner Orlando 2025, who worked for an enterprise with over 2500 employees, where the enterprise is based in the US and the contacts are also based in the US or Canada. However, AI can’t generate a list of emails to contact out of thin air. AI can’t know how to segment without the data you have collected about your opportunities. Once we strip everything back to what can’t be done by AI, data is the last moat.
Even if you did need to do something similar again, if it was in a few months time the AI will have improved and you may be able to do it more easily, simply and quickly than before.
Lots of companies end up buying CRMs because they want to do something this simple.