TL;DR
Replace a SaaS tool when you use a narrow slice of it, the workflow is specific to your team, and the data it needs is already yours. An agent can build that slice, and the business owns it and changes it by asking. Keep buying the systems where the vendor carries regulatory, deliverability, or support work.
- The economics changed. A Lego business replaced legacy inventory and selling software that cost about $10k a year with an app its agent built.
- Fit beats features. We built our own CRM because it needed to read our product data, which a generic CRM cannot.
- Not everything should be rebuilt. Payroll, ledgers, payments, and email delivery stay bought.
- An owned app needs the boring parts: sign-in, a database, backups, scheduled jobs, logs, and rollback.
The old build-versus-buy math assumed building was expensive and changing was more expensive. With an agent writing the code, both got cheap for a certain kind of tool. What did not get cheaper is running it reliably for other people. That is the part to plan for.
Which tools are good candidates?
Tools with three traits:
- You use a small part of the product. If your team uses three screens of a forty-screen product, the other thirty-seven are cost and clutter.
- The workflow is yours. If you keep exporting to a spreadsheet to do the real work, the tool does not fit the workflow.
- The data is already yours. A tool that needs to read your product database, your orders, or your own API is easier to build next to that data than to integrate from outside.
What did that look like in practice?
Inventory for a Lego business. The business ran inventory and selling on legacy software at about $10k a year. It now runs its own system on floo, built by its agent. It owns the software, changes it by prompting, and stopped paying for the legacy tool. The use case is here.
Our own CRM. We wanted to see which orgs were deploying more, which were going quiet, and how many users their apps had. A generic CRM stores contacts and notes; it cannot see product reality. Our CRM reads product data, runs an hourly job, and sends the next actions to Slack. It sits behind floo sign-in, so we wrote no auth code. How we built it.
In both cases the win was fit as much as price. The app does the specific job, and it changes the day the job changes.
What should you keep buying?
Some vendors sell work, not software. Keep buying when the vendor carries:
- Regulatory work, such as payroll, tax, and accounting ledgers.
- Deliverability and reputation, such as sending email at volume.
- Money movement, such as payments and payouts.
- A large integration surface you would otherwise maintain, such as a full helpdesk with every channel.
Your own app can sit on top of these, calling their APIs, without replacing them.
What does an owned app need to be trusted?
Replacing a vendor means taking on the things the vendor did quietly. For an internal app, that is a short list:
- Sign-in limited to the team, with a way to remove someone at once.
- A real database with backups, not a JSON file or a spreadsheet.
- Scheduled jobs for the work that happens without anyone opening the app.
- Logs and rollback, so a bad change is visible and reversible.
- A safe place to try changes before the team sees them.
On floo, those are part of the app. access_mode = "accounts" adds invite-only sign-in, [managed.default] adds Postgres, [cron.<name>] adds scheduled jobs, every push deploys to a dev URL, and a GitHub release sends a checked build to production. The agent that built the app can deploy, read logs, and roll back from the same CLI.
How should you start?
Pick the tool your team complains about most that does one narrow job. Write down what the team actually does in it, not what the product can do. Have your agent build that, put it behind sign-in, and run both side by side for a couple of weeks. If nobody opens the old tool, cancel it.
Sources
- floo use cases: Lego inventory, floo-crm
- floo docs: app sign-in, Postgres, backups, cron jobs, environments, releases and rollbacks
Frequently asked questions
Is it worth building internal software instead of buying SaaS now?
For narrow tools that fit one team's workflow, often yes. An agent can build and change the app quickly, and the running cost is usage rather than seats. For broad systems of record with compliance, integrations, and support needs, buying is usually still right.
What kinds of SaaS tools are good candidates to replace?
Tools where you use a small part of the product, pay per seat, and work around the rest: inventory for one business, a dashboard of the numbers a team argues about, a CRM that needs to read your own product data.
What should I keep buying?
Payroll, accounting ledgers, email delivery, payments, and anything where the vendor carries regulatory or deliverability work you do not want to own.
Who maintains the app after the agent builds it?
The same agent, with a person deciding what changes. That only works if the app's configuration lives in git and the agent can deploy, read logs, and roll back without a person clicking through dashboards.