Should We Build It?

This one follows on from [*Problem First. Tools Second.*](/insights/problem-first-tools-second). Say you've done that properly — you've named the real problem, found the bottleneck, and decided a piece of software is genuinely the right answer. A new question turns up almost immediately, and AI has quietly changed what it means. The old version was, "Can we build this?" For a long time that was a real constraint. Building software was slow, expensive, and needed people you probably didn't have. So "can we" did a lot of the deciding for you. That barrier has mostly fallen over. With AI builders and a weekend, a non-developer can stand up a working app. Hosting a simple one costs next to nothing. So "can we build it?" is now nearly always yes — which is exactly why it's stopped being a useful question. When the answer is always yes, the question isn't doing any work. The one worth asking is the harder one: *should* we? ## The dependency worry is fair There's a genuine argument on the build-it-yourself side, and it's worth taking seriously. Lean on someone else's AI platform and you've taken on their pricing, their roadmap, and their survival. The price goes up. A feature you depend on quietly disappears. The company gets acquired, or simply switches off. Your business now has a load-bearing wall it doesn't own. Owning the thing instead has real value, and not only operationally. Proprietary software — code, data, IP you actually control — can lift the valuation of a business and make it more defensible. Anyone who's been near a company sale knows buyers prefer assets the business owns over heavy reliance on third parties they can't see the contracts for. None of that is wrong. But it's only one side of the ledger, and it's the side that's easy to talk yourself into. ## "Can we" was never the expensive part Here's the thing the cheap-to-build argument tends to skip. The cost of software was never mostly the building, and it certainly isn't the hosting. Building is now the cheap bit. The expensive bits all come after launch, and they don't stop: maintenance, security patches, updates when something upstream changes, support when it breaks, documentation so it isn't trapped in one person's head, training so people actually use it, and the quiet ongoing work of keeping it reliable and compliant. A £50-a-month tool that saves ten hours a month is often a far better decision than a custom app you now have to nurse for the rest of its life. The SaaS fee looks like the cost. It isn't. The real comparison is that fee against the full, honest cost of owning the alternative — and that second number is almost always bigger than the spreadsheet says, because the spreadsheet only ever has hosting in it. So the question isn't "Can we build it ourselves?" It's "Should we?" And that turns on what the thing is actually worth to you, and what it'll cost you to keep alive — not on whether it's technically possible. ## When everyone can build it, building it wins you nothing There's a second reason to be careful, and it's about where advantage now lives. If AI makes a particular tool trivial to create, then everyone can create it. The software itself stops being a differentiator — it becomes a commodity, the same capability sold a dozen ways. Build your own version of something that's already a commodity and you've spent real effort to land exactly where you started, except now you own the maintenance too. Advantage moves to the things that can't be copied in a weekend: distribution, brand, expertise, the relationships you have with customers, the data only you hold. That's the test for whether building is worth it. Building a commodity gains you nothing. Building where you have a genuine, hard-to-copy edge — your own data, a process that's actually unusual, something off-the-shelf can't reach — is a different decision entirely, and sometimes very much worth it. ## Don't build your own landfill The likely near future is a flood of cheap, AI-generated software. Lots of it. Much of it duplicate, much of it low quality, most of it short-lived — software as fast fashion, easy to produce and quick to throw away. It's easy to read that as a warning about other people's software. It's also a warning about your own. Every tool you build is a thing you now own and have to look after. Build five of them in a burst of enthusiasm and within a year you've got a graveyard of half-maintained internal apps that each made sense on the day and now collectively eat time, carry risk, and confuse new starters. That's not an asset. It's a liability you generated yourself, one cheerful "we could just build that" at a time. ## A way to decide The choice isn't ideological. It's case by case, and these are the questions that usually settle it. - **Is it core or commodity?** If the capability is something anyone could buy off the shelf, buy it. If it carries a genuine, hard-to-copy advantage of yours, building is on the table. - **Who maintains it best?** A SaaS vendor patching, securing and improving a product full-time will almost always do it better than you can in the gaps between real work. If that's the realistic comparison, rent it. - **What's the true cost to own?** Not hosting. The whole lifetime — maintenance, support, security, documentation, training, the people-time. Compare *that* against the subscription, honestly. - **Can you fund the life, not just the launch?** Building is a sprint; owning is a standing commitment. If you can't resource the years, don't start the weekend. - **Does owning it change your value?** Sometimes the IP itself is the point — it raises the valuation or the defensibility of the business. If so, that goes in the build column, with eyes open about the upkeep. ## Three routes, none of them wrong It's worth being plain about this, because the article so far might read as a quiet argument for buying. It isn't. There are really three routes, and any of them can be the right one. You can build it yourself, which keeps the cost low and the control entirely in your hands — but the maintenance, security and support land on you, and stay with you. You can commission a specialist builder to make exactly what you need, which gets you something fit for purpose and properly engineered, at a higher upfront price and with a new dependency on whoever built it being around to support it. Or you can buy an off-the-shelf tool, which hands the upkeep to someone who does it full-time, at the cost of the lock-in and the loss of control we've already talked about. None of those is the wrong answer. The wrong move is choosing one without seeing the trade-off you're signing up for — picking "build" for the control and being surprised by the upkeep, or picking "buy" for the convenience and being surprised by the dependency. Go in with the pros and cons of each in full view, and any of the three can be a good decision. ## The thread that runs through both The first question is still the one from the companion piece: what problem are we actually trying to solve? Once that's clear and a tool is the answer, the second question now has a build-or-buy decision folded inside it — and the honest version of that decision isn't "can we?" It's "should we, and can we afford to keep it alive?" The technology stopped being the bottleneck a while ago. Ownership, maintenance, and business value are where the real decision now sits. Get that the wrong way round — building because you can, rather than because you should — and you don't end up with an asset. You end up with something to maintain. ## Frequently asked questions **Should I build or buy software now that AI makes building easy?** Ask "should we?" rather than "can we?". Building is now nearly always possible, so it's no longer the deciding question. The cost of software was never the building or the hosting — it's the maintenance, security, support and training that follow, which a subscription often covers more cheaply than owning a custom tool. **What are the real costs of owning software?** The expensive parts come after launch and don't stop: maintenance, security patches, updates, support, documentation, staff training, reliability and compliance. Hosting is the small line in the budget; the lifetime cost of ownership is almost always larger than the spreadsheet suggests. **When is it worth building your own tool?** Build when the capability carries a genuine, hard-to-copy advantage — your own data or an unusual process — when nothing off the shelf fits, and when you can fund its whole life rather than just the launch. Building a commodity everyone else can also build wins you nothing but the maintenance. **What are the options for getting a software tool?** There are three: build it yourself (low cost, full control, but the upkeep is yours), commission a specialist builder (fit for purpose and well engineered, at a higher price and a dependency on the builder), or buy off the shelf (maintenance handled for you, at the cost of lock-in). None is wrong — the mistake is choosing without seeing the trade-off. --- *At Smart AI Studio we spend as much time talking clients out of building things as into it. If you're weighing whether to own a tool or rent one — and want an honest read on the full cost of each, not just the launch — Peter Lowe runs discovery calls built around exactly that decision. It's a working session, not a sales pitch.*