The internal tools that replaced our SaaS stack

The standard way to bring more software into a small company is to buy another SaaS subscription. Enough of those accumulate that a five-person company can end up quietly paying for a dozen tools, half of them overlapping, each one run by whoever happened to set it up. The alternative is teaching one of your own people to build and own the tool instead — and it works better than it sounds.

I ran a one-day workshop at Aclymate teaching four non-technical staff the actual mechanics of shipping real software: git, branches, reviewed pull requests, and how to specify what you want built in plain English. What it has produced since is a growing set of internal tools — built and maintained by someone who was never going to be called an engineer — that have replaced tools we used to pay for.

Why this normally fails

Asking a non-technical person to build production software from a blank page does not work. The design space is too large, the failure modes are invisible until they are expensive, and the honest answer to most of their questions is “it depends.” People sensibly give up.

The move that made it work was removing the design space. Every real deliverable follows the same disciplined path: a scoped repo, a branch, a reviewed pull request, checks that block a bad merge, and a deploy that is someone’s deliberate action, not an accident. What varies is the specific problem being solved — and that part is exactly what a domain expert knows better than any engineer does.

Once the pattern is fixed, specifying anything collapses into a few plain-English questions: what is this for, what does it need to read, what should it produce, and who reviews it before it ships. That is a form a salesperson can fill out about their own job in fifteen minutes. It was the closing exercise of the workshop, and everyone finished it.

What the day actually covered

Eight modules over a single day, with exercises in a real codebase rather than a sandbox. The bet was that people learn faster reading code that genuinely runs their company than toy examples, and that held up — the first exercise was reading an actual integration function and working out what information it needed.

Two choices did disproportionate work here. Cloud development environments got the workshop day itself off the ground — no one lost the morning to a failed local install before they had learned anything. That did not last much beyond the workshop: within weeks everyone moved to local environments instead, because a cloud environment ties you to one repository at a time, and real work meant moving between several. The other choice held up better — splitting permissions by repository meant people could ship their own internal tools without review, while changes touching the customer-facing product still came through me. Autonomy where mistakes are cheap, review where they are not.

The ramp every tool goes through

A workshop alone produces enthusiasm and nothing else. What actually converts it is a maturity ramp everything goes through before it is trusted:

1. Read-only first — a tool that surfaces information but changes nothing. This stage catches most misunderstandings while they are free.
2. Reviewed side effects — the tool proposes a change; a person still approves it before anything happens.
3. Trusted to run — once the pattern has been reviewed enough times, it runs unattended.

Nothing skips a stage. By the time something reaches the third, whoever owns it has read enough of its own output to have developed judgement about when it is wrong — which is the actual prerequisite for trusting it.

What actually got built

The practice started the same week as the workshop — the first replacement build, a Jira clone, began April 8th, days after training. Over the four months since, it has produced this:

A seventh replacement — the company website, which used to run on Webflow — is its own story, told in the apprenticeship case study: our Chief Marketing Officer built it and runs it end to end.

Real subscription costs exist for two of these. The Atlassian suite — Jira, Confluence, and its support tooling, bundled with no line-item breakdown available — ran roughly $3,194 a year. AppCues ran $2,356. Both are gone entirely. Datadog was not so much replaced as recognized as redundant: Sentry and Google Cloud Logging, both already in use, covered what it was doing, so paying for a third tool stopped making sense. The SOC2 tracker is a different kind of saving — not eliminating a cost but avoiding one. Building it in-house means never taking on the Vanta- or Drata-class subscription most companies our size assume they need — an internally estimated $8,000 to $15,000 a year that has never actually been spent.

One more data point, more about confidence than dollars: two part-time contractors who handled data entry and cleanup left this summer for full-time jobs elsewhere. Our director of customer success made the call not to backfill them — not a hope, but a decision made with real confidence, because he had already spent months proving that exactly this kind of well-scoped, repeatable work is what internal tooling handles best.

What I would tell a company considering this

The training transfers regardless of which specific artifact comes out the other end. Four people learned git, review discipline, and how to specify something in plain English. What they have built since varies by person and by need — that is the point, not a deviation from it. You are not buying a guarantee about what gets built; you are buying the capability to build whatever actually turns out to be needed.

It does not have to produce an agent, or even software with any AI in it, to be worth doing. A well-scoped internal tool that replaces a SaaS subscription is sometimes the entire right answer, and recognizing that — rather than reaching for an agent because agents are the trend — is part of the same judgement that decides when something needs real guardrails instead.

There is a layer underneath a lot of this that is easy to skip past: being able to point an AI system at your own financial systems, or have it make judgement calls against real customer data, and trust the result, is not something you get by handing a chatbot an API key. Scoping exactly what a model can read, keeping it away from what it should not touch, and doing that without credentials ending up somewhere they should not is its own real engineering — done once, underneath everything else here. It is also precisely the part most companies attempting anything “agentic” skip.

That infrastructure is what the agent-platform case study is really about — worth building when the job needs it, worth skipping when it does not.