Why I Turned Down an Enterprise Software License and Built My Own Stack

I was paying enterprise-level fees for a software license. Then I asked myself what I was actually getting for it. Here's what happened next.

I was paying enterprise-level fees for a software license. Then I asked myself: what am I actually getting for this?

The Starting Point

When I started DigitalStaff, I relied on traditional enterprise RPA platforms for robotic process automation. They’re powerful. They work. They have huge ecosystems, enterprise support, and proven track records.

They also come with significant per-seat licensing costs. For a lean consultancy serving mid-market Canadian companies, that cost either gets passed to the client (making our services less competitive) or eaten by the margin (making the business less sustainable). Either way, it’s a problem worth solving.

The Question

What if I could get the same core capabilities without the enterprise price tag? Workflow orchestration, scheduled automations, API integrations, error handling, monitoring, all the things that make automation reliable in production. What if I could own the infrastructure instead of renting it?

I’m not talking about building everything from scratch. That would be foolish. I’m talking about assembling the right tools into a stack that does what I need, at a fraction of the cost, with full control over the infrastructure.

What I Built

I assembled a self-hosted automation platform that covers everything we need: workflow automation, data storage, and custom client-facing dashboards. All hosted on our own infrastructure in Canada, fully under our control.

The total infrastructure cost is a fraction of what enterprise licensing would run. Not close. Not comparable. A fraction.

The Trade-Offs

I’m being honest here because this matters.

More operational responsibility. I maintain the servers, the updates, the backups, the security patches. There’s no enterprise support line to call at 2 AM.

More technical depth required. You need to understand Linux system administration, networking, database management, and the internals of each tool you’re running. This is not a click-to-deploy situation.

More initial setup time. Getting the stack configured, secured, and production-ready took weeks of work. An enterprise platform gives you a working environment on day one.

This approach works for me because I have the technical skills and I genuinely enjoy the infrastructure side. It would not work for someone who just wants to click buttons in a SaaS dashboard. That person should absolutely use an enterprise RPA platform and pay the license fee. The right tool depends on your situation.

The Benefit for Clients

Lower costs passed through. No vendor lock-in. Everything runs on open standards and can be migrated if needed.

Canadian-hosted infrastructure with full control over data residency. For clients in healthcare or government, this isn’t optional. It’s a compliance requirement that’s much easier to meet when you control the servers. Read more: Why Healthcare Clinics Are Automating Their Billing (And How It Works)

Custom apps that can do anything, not limited by what a platform supports. If a client needs a specific integration, a specific workflow, or a specific UI, I build it. No “sorry, the platform doesn’t support that.”

And the tooling gets better over time. The stack I’m running today is significantly more capable than what I started with, and the upgrade cost was zero.

The Lesson

The best tool is the one that fits your situation, your skills, and your economics.

For an enterprise with 500 developers and a procurement department that needs vendor support contracts, traditional RPA platforms make perfect sense. The license fee is a rounding error in their budget, and the support infrastructure is worth paying for. We still implement those platforms for clients where it’s the right fit.

For a lean automation consultancy serving mid-market Canadian companies, where every dollar of overhead affects either the client’s price or the company’s margin, owning part of the stack makes more sense. It means we can do more for clients, at a lower cost, without sacrificing capability. The investment is in time and skill, not in license fees.

I’m not saying everyone should do what I did. I’m saying everyone should ask the question: what am I actually getting for this cost, and is there a better way to get it?

If you’re curious about how we’ve structured our automation infrastructure, or if you’re evaluating build-versus-buy decisions for your own automation needs, let’s have that conversation. It’s one of my favourite topics.

Related Posts