Build vs Buy: AI Systems for a Small Business
For a 5–50 person company, build-vs-buy is a false binary. Building from scratch requires a dev team you don't have; buying vertical AI SaaS means renting someone else's idea of your workflow, with your data locked inside their walls. The answer that actually works is the third option: assemble on an open agent framework — the architecture already exists, and your work is capturing your own expertise as skills that run on it.
Why does "build" fail at this company size?
Building custom AI software means hiring or contracting developers, maintaining infrastructure, and owning every breakage at 2am. For a $5–50M business, that's a second company bolted onto the first. The classic estimate-versus-reality gap in custom software doesn't get smaller because the software has AI in it — it gets bigger, because the ground shifts under you with every model release. Unless software is your product, building the platform layer from zero is a distraction dressed up as ambition.
Why does "buy" quietly cost more than the subscription?
Off-the-shelf vertical AI SaaS demos beautifully because it's built for the average company in your category. That's exactly the problem — you're not average, and the parts of your workflow that differ from average are usually the parts that win you business. Buying means:
- The vendor defines the workflow. You adapt your company to the tool, not the tool to your company.
- Your data and process knowledge accumulate inside their product. Switching later means starting over, which is why the price can keep rising.
- Per-seat pricing taxes growth. Every hire raises the bill whether or not they create value with the tool.
- Nothing compounds for you. A year of usage makes the vendor's product smarter. It leaves you exactly where you started.
The full ownership argument — rental versus owning the operating layer — is its own topic, covered in platform rental vs owning your AI operating system.
What's the third option?
Assemble. Use an open framework where the hard architecture — agents, skills, tools, and how they compose — already exists, and your work is configuration and capture, not development:
- Agents (the workers) come from the frontier labs and keep improving without you lifting a finger.
- Skills are plain-language documents that encode how a job is done to your quality bar. You write them once; any agent can load them forever.
- Tools connect agents to your actual systems — email, CRM, files, browser.
This is the FAST framework: Factory of Agents with Skills and Tools, where agents × skills × tools is multiplicative rather than additive. The Optimus system already carries 300+ portable skills built this way, and the architecture is documented openly at fastframe.work. You're not coding a platform and you're not renting a black box — you're accumulating an asset.
Is "assembling without developers" realistic? As one data point: one founder directing agents on this architecture shipped 65+ private repos, 20,000+ commits, 4M+ lines of code, and 38+ live sites in six months of 2026. The leverage is in the direction and the skills, not in headcount.
How do the three options actually compare?
| Build from scratch | Buy vertical SaaS | Assemble on a framework | |
|---|---|---|---|
| Fit to your workflow | Perfect, eventually | Average by design | Exact — you encode it as skills |
| Team required | Developers | None | You + agents |
| Time to first result | Months | Days | Weeks |
| Who owns the accumulated knowledge | You | The vendor | You |
| What compounds | Your codebase (and its maintenance) | The vendor's product | Your skill library |
| Exit cost | Sunk development | High — data and process locked in | Low — skills are portable files |
When should you still just buy?
When the job is commodity and gives you zero edge: transcription, scheduling, invoice OCR, basic support deflection. Buy those without ceremony. The decision rule:
Buy the workflows where being average is fine. Assemble the workflows that make you money. Never buy the ones that differentiate you.
Run your workflow list through that filter and the build-vs-buy debate mostly dissolves — a handful of cheap commodity subscriptions, and a growing skill library for everything that matters. If you're unsure which workflow to run through first, the rollout sequence and the framework definition are the two places to start.
FAQ
Should a small business build its own AI systems or buy off-the-shelf tools?
Neither extreme. Building from scratch needs a dev team most 5–50 person companies don't have; buying vertical SaaS means renting generic workflows with your data locked inside. The practical answer is assembling: use an open agent framework where agents load documented skills and tools, so you own the system without writing it from zero.
What does "assembling on a framework" actually mean?
It means the hard architecture already exists — agents, skills, tools, and how they compose — and your work is capturing YOUR workflows as skills that run on it. You configure and accumulate rather than code from scratch. The FAST framework (Factory of Agents with Skills and Tools) is built exactly for this, with 300+ portable skills already in the system.
When does buying off-the-shelf AI SaaS make sense?
When the job is genuinely commodity — transcription, scheduling, basic support deflection — and the workflow gives you no competitive edge. Buy commodity jobs; assemble the workflows that differentiate you. The mistake is buying the differentiating ones and letting a vendor define how your company works.
Isn't building without developers unrealistic?
Writing an agent platform from scratch, yes. But assembling on a framework is a different activity: the skills are written in plain language, agents execute them, and the community has already built hundreds. One founder directing agents on this architecture shipped 65+ repos, 20,000+ commits, and 38+ live sites in six months of 2026 — the leverage comes from direction, not headcount.