The End of the Software Procurement Spreadsheet

Last month, someone on my team came to me with a problem: we needed a way to send large files (4 GB or more) securely to clients. Simple enough request. So I did what any responsible CEO does: I started a spreadsheet.

Two hours later, I had six candidate products listed, a growing list of requirements, and a rising sense of frustration. Excel was not designed for comparing blocks of descriptive text, so I was copy-pasting fragments from marketing sites into cells that weren’t built to hold them. Two of the products had no public pricing (“contact sales”), which in my experience means more than you want to spend. The ones that did show prices were around £10 per user per month, which adds up quickly for a small team. My favourite of the six was missing one feature I genuinely needed.

Then a meeting came up, and the whole thing sat unfinished. We worked around the problem a different way.

The friction economics of small software procurement are completely wrong. The cost of evaluation often exceeds the value of solving the problem.

I suspect this experience is almost universal for anyone running a small business. Small software procurement is, bluntly, broken. Not because good software doesn’t exist, but because the process of finding, evaluating, and committing to it is so costly relative to the value of the problem being solved.

What AI Coding Actually Changes

There has been a lot of noise about AI coding tools. Most of the conversation focuses on developer productivity: how much faster engineers can ship features, how much less boilerplate they have to write. That’s real, but it’s not the most interesting thing happening.

The more interesting thing is what happens to the economics of software when the cost of building and modifying it collapses.

Today, when you buy a SaaS product, you’re paying for a centralised engineering team to build something that works well enough for a large enough slice of the market. Features you need but they haven’t prioritised? On the roadmap. Integrations you require? Maybe, if enough other customers ask. Bugs that affect your specific use case? Ticket submitted. This model exists because custom software was expensive, because writing code was expensive.

When AI can generate, modify, and extend a working application in minutes, that assumption breaks down. Software can be sold as source code, ready to be deployed into your own environment and adapted to your specific needs. You don’t need a SaaS vendor to run a central service; each customer runs their own instance. The customisation that used to require a development contract can happen in an afternoon.

This is a genuine shift. Not evolutionary: revolutionary. The value in software stops being primarily about the code itself, and starts being about sensible application design, the quality of the user experience, and the knowledge embedded in the thing. The code becomes closer to a commodity.

The Problems That Need Solving First

I want to be clear that I’m not describing something that will happen automatically. The AI coding revolution creates a possibility, but translating that possibility into something businesses can actually rely on requires solving some genuinely hard problems.

Security

If you’re deploying software from a marketplace of third-party apps, how do you know it’s safe? The SaaS model, for all its frustrations, does at least mean the vendor has skin in the game. A serious security incident is their problem too. With self-deployed apps, the responsibility shifts. The answer isn’t to abandon the model; it’s to build proper review and verification into the distribution layer. Apps need to be checked before they’re listed. Code review tooling needs to be part of the platform. And for anything customer-facing, there needs to be a path to deeper security testing.

It’s worth noting that many of the most useful tools for small businesses (internal dashboards, workflow automation, team utilities) are never exposed to the public internet at all. That substantially reduces the attack surface. But the security question still needs a real answer, not a hand-wave.

Integration

Standalone apps are limited in value. The tools that actually save time are the ones that connect to your existing systems: your email, your calendar, your file storage, your internal databases. Today, integrating a new tool into your organisation’s infrastructure is a project in itself: OAuth registrations, API keys, permission configurations, IT ticket, two-week wait.

The right approach is to abstract this at the platform level. Let an administrator map out the organisation’s key systems once, and then let individual apps connect to those pre-configured resources during setup. Single sign-on that just works. Connections to shared file storage that don’t require a developer. Permission controls that are consistent across every app. This is the infrastructure work that makes everything else possible.

Discoverability and Trust

A marketplace of AI-built apps is only useful if you can find what you need and have some confidence it will work. That means thinking carefully about how apps are characterised, not just by function, but by the practical dimensions that matter during evaluation: How much effort does setup actually take? How broadly applicable is it across an organisation? What’s the ongoing cost, including any AI processing? A low-friction app that runs with no ongoing costs is a fundamentally different proposition from something requiring significant configuration and expensive models running in the background.

The value shifts from coding as such to sensible application design, and modification, adaptation, and security review, though the latter will also be AI-automated over time.

The Bigger Picture

The impact on large enterprise software will take longer to materialise. Major line-of-business systems (ERP, complex CRM, deeply integrated finance platforms) are genuinely complicated, and the switching costs are enormous. But even there, the long-term direction seems clear: as AI makes it feasible to compose functionality from smaller, well-designed components communicating via APIs, the monolithic vendor lock-in model becomes harder to justify.

For small businesses and teams, the change will come faster. The economics are more favourable, the systems less complex, and the frustration with the current model more acute. The CEO trying to solve a file-sharing problem shouldn’t have to spend two hours on a spreadsheet and still end up with nothing. That’s time that could go into building the actual business.

What We’re Building at Blueberry

I’ve been thinking about these problems for a while. We’ve spent the past year building something to address them directly: a platform called VibeMagic, which combines a curated app store of AI-built software with the infrastructure layer that makes secure, integrated deployment genuinely practical for small and mid-sized organisations.

The idea is exactly what I’ve described above: browse a vetted store of apps, trial one, and have it built and deployed to your own environment automatically within minutes. Then customise it: yourself with AI assistance, with our support team, or by handing it to your own developer. Add your branding, remove a field you don’t need, connect it to your existing systems. The integration layer handles SSO and organisational resource mapping, so each new app you add doesn’t require starting the configuration from scratch.

We’re at an early stage, but the core of the platform is working, and the app store is taking shape. If you’re curious about where it’s headed (or if you’re a developer interested in building apps for it), I’d love to hear from you.

The spreadsheet era of software procurement is nearly over. I can’t wait.