The short version
Buy the narrow tool when it solves one common, low-risk problem cheaply. Build custom when the workflow is a constraint, a major cost or a genuine advantage. For most established agencies and info businesses, use a specialist external team to build it instead of turning the founder into a developer or building a full software department in-house.
Founders tend to compare the price on the proposal and ignore the price of getting the decision wrong.
A £97-a-month SaaS subscription looks cheaper than custom software. For a simple cold email workflow, it probably is. But if that tool sits at the centre of client delivery, cannot support the way your team works and forces you to employ people around its limitations, the subscription price tells you very little about its real cost.
Building it yourself can look even cheaper. You open a vibe coding tool, explain the idea and have a good-looking dashboard by the end of the day. Then you find the bugs, permissions, deployment, security, integrations, data migrations and edge cases that separate a demo from production software.
Hiring an AI engineer sounds like the sensible middle ground, but a single hire is not a product team. It is also difficult to judge an engineer when you are not an engineer yourself.
The decision should come back to one question: which route has the highest probability of removing the business constraint without creating a more dangerous one?
If the constraint itself is not yet clear, start with the constraint-first framework for choosing an AI system before comparing delivery routes.
01 · Compare the actual options
The four routes to getting an AI system built
There is no universal winner. The right option depends on how specific the problem is, how much control you need, how much failure would cost and whether software is your core business.
| Route | Best fit | What you gain | What you carry |
|---|---|---|---|
| Buy SaaS | One common, narrow problem | Speed and a low starting cost | Dependency and limited control |
| Build it yourself | A prototype or low-risk internal experiment | Fast learning and direct ownership | Engineering, security, QA and maintenance |
| Hire internally | A software company building a permanent product function | Dedicated internal knowledge | Recruitment risk and the need for a complete team |
| Use a specialist team | A high-value custom system for an established business | Developers, QA and delivery experience from day one | A larger initial investment and partner selection |
The mistake is choosing the route before deciding whether the system is strategically worth building at all. If it does not remove a constraint or reduce a major cost, do not turn it into a custom software project simply because custom sounds more impressive.
02 · Buy the solved problem
When buying SaaS is the right call
Existing SaaS is brilliant when you need one small thing and the market already has a good answer. If you want to automate cold email outreach and a reliable product does it for £97 a month, buy it.
Rebuilding that product would be over-engineering. It is unlikely to be the constraint in your business, the subscription is not a meaningful expense and you gain nothing by owning a weaker version of a solved tool.
Buy SaaS when
- The job is narrow and common across many businesses.
- A proven product already handles it well.
- The monthly fee is small relative to the value.
- The workflow is not a core differentiator.
- Switching to another product would be manageable.
A custom system should earn its build. If a cheap tool solves the problem properly and does not trap the operation, there is no medal for recreating it yourself.
03 · Convenience can become dependency
When SaaS starts controlling the business
SaaS is designed for the average customer. That is what makes it commercially viable, but it also creates the ceiling. Your team cannot add the exact feature it needs. You can submit a request, but the vendor has hundreds or thousands of other customers asking for different things.
As the business scales, the workarounds multiply. People copy data between products, build spreadsheets around missing features and change the operation to suit the tool.
You also carry platform risk. The provider can change its pricing, interface, limits or product direction. It can remove a feature you rely on. It can be acquired or close. If that product runs a critical part of fulfilment, somebody else has more control over your operation than they should.
That does not mean every dependency is bad. It means a dependency becomes worth replacing when it is expensive, central to delivery or actively constraining how the business scales.
The right replacement may combine several approaches. Our guide to AI agents, automation and custom software explains where each fits.
“Buy the narrow tool. Build the operation you cannot afford to lose control of.”Harry Meighan
04 · A demo is not a production system
The hidden cost of building it yourself
AI coding tools have made software more accessible. That is a good thing. A founder can validate an idea, prototype an interface and learn what the workflow should do without waiting weeks for a development cycle.
The danger is confusing accessibility with engineering. Software can look finished while still having weak authentication, exposed secrets, incorrect database rules, broken permissions, fragile integrations and unhandled edge cases.
Public-facing environment variables and API keys can be found and abused. A poorly configured database can expose client data or generate unexpected usage charges. An agent without sensible limits can burn through model and compute costs. These are not theoretical risks, and a polished dashboard does not tell you whether they have been handled.
Then there is the founder’s time. You become the product manager, developer, infrastructure engineer, tester and support desk. You started the business for freedom, not to inherit four new jobs.
The booking platform that cost a founder two months
A founder I knew ran a marketing agency for beauty salons. He decided to build a custom booking platform that he could upsell to clients as an alternative to established products such as Fresha or Booksy.
He spent roughly two months building it himself. The result was visibly less capable than the products clients already used. They did not want it, and presenting the weaker product alongside the agency’s service made the overall offer look less valuable rather than more valuable.
The largest cost was not hosting or software. It was two months of the CEO’s time spent fixing product issues instead of running the company, with no meaningful demand at the end.
Experience note: this example comes from a founder known to Harry. It is included to show the opportunity cost and market risk of an unsupported DIY build, not as a Build, Ship & Scale client case study.
The greatest risk is a system that performs worse
Security and surprise bills matter, but the largest business risk is normally underperformance. Imagine replacing a fulfilment team with software that produces worse client results. You save payroll on paper, then lose the saving through complaints, rework and churn.
A system should not go live because it exists. It should go live because it has been tested against the real workflows and performs well enough to take responsibility for them.
05 · One engineer is not a product team
Why the internal hire is harder than it sounds
Hiring an AI engineer is a step up from doing everything yourself. You may find somebody excellent who can own the platform and build it properly. The problem is identifying that person when you do not know what good engineering looks like.
A strong interview performance does not prove that somebody can design secure architecture, handle production data, manage model costs and ship a dependable product. A wrong hire can lose months before the business even understands that the foundations are weak.
The access also matters. This person may handle API keys, infrastructure, client data and billing credentials. Hiring quality and access controls are not small details.
The strongest engineers also have options. Many choose teams with ambitious technical missions, mature engineering cultures and resources that a non-software business cannot easily reproduce. A bigger salary alone does not guarantee the right hire.
Developing and testing are different jobs
Builders naturally focus on making the product work. Thorough testing asks a different question: how can this product break? Expecting one engineer to design, build, review and independently challenge all of their own work leaves gaps.
On our projects, developers and QA testers operate as separate functions. Developers build during the day. Our QA team can test the work in the next handover, log defects and return clear findings for the following development cycle. That creates a continuous loop of building, testing and fixing.
Testing includes unit, integration, end-to-end and regression coverage alongside the real user journeys the platform must support. The exact balance depends on the product, but independent QA is not optional for a system affecting client delivery.
06 · Rent the product function, own the build
When a specialist external team makes more sense
Most agencies and info businesses are not software companies. Building a full internal software department can mean recruiting developers, QA, product leadership and infrastructure experience for a function the business may only need around specific systems.
A specialist external team gives you those disciplines without asking the business to become an engineering employer. You avoid months of interviewing, the risk of one critical hire and the need to train a generalist from zero on how an agency or info business actually delivers.
That context matters. A team that has already built systems for businesses like yours understands the patterns, the integrations, the operational edge cases and the pressure that client-facing software carries.
Use a specialist team when
- The system removes a real constraint or major cost.
- The workflow is specific to your operation.
- Failure would affect clients, revenue or sensitive data.
- You need development, QA and delivery leadership together.
- You want to own the custom system without building a software company.
This is the route I favour for established agencies and info businesses because it matches the capability to the problem. The business gets a serious product team for the build and ongoing support, without carrying a full permanent department that sits outside its core model.
07 · Do not buy a development lottery ticket
How to tell whether a software partner can actually deliver
A confident proposal and a good-looking portfolio are not enough. You need evidence that the team understands the kind of system you are asking it to build.
Ask for comparable work and a tangible outcome
Ask: “What have you built that is like this, and what happened after it went live?”
The example does not need to be identical. It should prove that the team has handled comparable complexity, risk or operating scale. Look for measurable outcomes where the client allows them to be shared, and clear experience disclosures where the work came from a founder’s previous role.
Ask exactly how testing works
Testing is as important as building. Ask who owns QA, whether it is independent from the developer, which environments are used and how unit, integration, end-to-end and regression testing fit the release process.
If the answer is vague, or if the same developer simply clicks around their own work before launch, treat that as a serious warning sign.
Ask about ownership, maintenance and change
Find out what you own, who controls the accounts and infrastructure, how bugs are handled after launch and how future features are requested. Also ask what happens when the team discovers that your original requirement is not the best solution.
A good product partner will not blindly build a weaker idea to keep the conversation easy. It should bring the issue to you, explain the tradeoff and recommend the stronger route.
08 · High input at the start, low drag after
How a Build, Ship & Scale engagement works
We start with a working call to understand the vision, the constraint, the users and the result the system must create. That becomes the brief and initial requirements our developers work from. There should be no guesswork hidden inside the build.
From there, we manage the process end to end. The client gets regular progress updates and can give feedback on what they see, but there is no expectation that the founder becomes a part-time product manager.
Our developers build the system, our QA team tests it and the client validates it in a UAT environment before production. We deliver the first production-ready version within 45 days of coming on board, with the exact scope set around the system.
If we discover a better route than the original request, we raise it. We are there to build the strongest product, not to agree with an idea that evidence says will underperform.
09 · Price the full decision
Ownership, ongoing costs and the true price of the build
With Build, Ship & Scale, the client owns the specific custom build. We reserve the right to feature the platform in case studies and to reuse non-client-specific patterns or code as templates for future work. The exact ownership, confidentiality and usage terms are set out in the engagement agreement before work starts.
After the initial build, the system still has operating costs. Depending on the architecture, those can include hosting through a platform such as Vercel or Render, a database such as Supabase, model and API usage, monitoring tools and occasional specialist subscriptions.
Some agent setups also need dedicated compute, which might be a Mac mini or another suitable device. These costs are normally modest beside the initial build, but they depend on volume and should be modelled before production.
We also offer maintenance packages so clients can raise bugs, request changes and add features without hiring an internal development team. Pricing stays custom because the scope, integrations, risk and complexity of each build are different.
Compare total cost, not the opening quote
| Option | Visible cost | Often missed |
|---|---|---|
| SaaS | Monthly subscription | Workarounds, dependency, per-seat growth and limited control |
| DIY | Tools, APIs and hosting | Founder time, security, QA, deployment and support |
| Internal hire | Salary and recruitment | Wrong-hire risk, management and missing product disciplines |
| Specialist team | Custom project fee | Ongoing hosting, usage and optional maintenance |
Do not automatically choose the cheapest quote. Choose the team and route most likely to solve the constraint and make the business more profitable. If a system could genuinely remove the thing holding the company back, what would that be worth?
That is the number the build should be compared with. Not the price of a random subscription, and not the fantasy that the founder’s time is free.
Use the AI system ROI calculation framework to turn that value into a defensible investment case.