The internal tools that replaced our SaaS stack

I taught four people at Aclymate, none of them engineers, how to build real software in a single day. One of them has since replaced four paid tools with things he built and now runs himself.

The usual way a small company adds more software is buying another subscription. Those add up fast. A five-person company can end up quietly paying for a dozen overlapping tools, each one run by whoever happened to set it up first. Teaching someone on the team to build and own the tool instead works better than it sounds.

Why most people never finish

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

The fix was removing the design space. I taught everyone the same disciplined path for any deliverable, the same five steps every time no matter what’s being built. What varies is the specific problem being solved, and that part is exactly what a domain expert already knows better than any engineer.

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

What the workshop actually taught

Eight modules in one day, with exercises in the company’s real codebase instead of a sandbox. The bet was that people learn faster reading code that actually runs their company than toy examples, and that held up. The first exercise was reading a real piece of code from Aclymate’s own product and figuring out what information it needed.

Two choices did disproportionate work here. Cloud development environments got the workshop day itself off the ground. Nobody lost the morning to a failed local install before they’d learned anything. That didn’t 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 aren’t.

How a new tool earns trust

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

1. Read-only first. A tool that surfaces information but changes nothing. This stage catches most misunderstandings while they’re 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 judgment about when it’s wrong. That’s 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’s produced this:

A seventh replacement, the company website (it 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 wasn’t 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, avoiding a cost rather than eliminating 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’s 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’d already spent months proving that exactly this kind of well-scoped, repeatable work is what internal tooling handles best.

Pulse wasn’t his last tool, either. Since then he’s independently shipped a customer quarterly-business-review generator, and Cleanup Crew, an OpenAI-backed tool that re-categorizes vendor records. That one’s the only AI-specific example among his work, and proof the training extends past plain internal tooling when the job actually calls for it. Someone else on the team, in sales rather than customer success, has independently written real, substantial code of his own in the same environment. Whether it becomes part of his daily work remains to be seen, but the training clearly reached more than one person.

If you’re considering this for your company

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’ve built since varies by person and by need. That’s the point, not a deviation from it. You aren’t buying a guarantee about what gets built. You’re buying the capability to build whatever actually turns out to be needed.

It doesn’t 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. Recognizing that, instead of reaching for an agent because agents are the trend, is part of the same judgment that decides when something needs real guardrails instead.

There’s a layer underneath a lot of this that’s easy to skip past: being able to point an AI system at your own financial systems, or have it make judgment calls against real customer data, and trust the result, isn’t something you get by handing a chatbot an API key. Scoping exactly what a model can read, keeping it away from what it shouldn’t touch, and doing that without credentials ending up somewhere they shouldn’t is its own real engineering, done once, underneath everything else here. It’s 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 doesn’t.