Your Automation Project Is Built. So Why Can't It Go Live?
Most automation projects don't fail at the bot. They stall at go-live, when nobody can answer what production will actually cost. Here's how to avoid that trap.
Automation projects do not usually fail because the bot cannot click the button.
They fail much later, in a much less exciting way.
The workflow is built. The vendor says the implementation is basically done. The team is ready to move into production. Then someone asks a simple question:
“What will this actually cost to run?”
That is where things get messy fast.
A Common Pattern
We recently dealt with a situation like this. I will keep it anonymous, but the pattern is worth talking about because it is far more common than it should be.
A company had an automation project that was reportedly built and close to ready. The implementation partner was still involved. Support was expected to stay with that partner. But when it came time to discuss production licensing, platform access, and usage costs, the picture fell apart.
Nobody had one clean answer to basic questions:
- Who owns the production environment?
- Is the customer buying its own platform, or running on partner-managed infrastructure?
- What licenses are actually required for go-live?
- How many users, robots, or usage-based units are needed?
- What part of the cost is implementation, and what part is ongoing platform overhead?
At that point, an outside expert gets pulled in and asked to “just give a number.” But there is no responsible way to do that without understanding the architecture, ownership model, usage assumptions, and deployment approach. That is not a pricing request. That is a commercial and technical assessment.
The “Managed Service” Trap
There is a variation of this problem that is even more confusing.
Sometimes the automation is not built as a standalone project. Instead, a vendor sells it as a managed service: they build it, host it, run it, and support it. The client pays a service fee and never has to think about the underlying platform.
That sounds great until the client gets the bill and starts asking questions. Why is the service fee so high? What is the licensing cost underneath? Can we buy the licenses ourselves and save money?
At that point, the client discovers that the platform licensing was bundled into the service all along, and unbundling it is not straightforward. The environment may be owned by the vendor. The licenses may be tied to the vendor’s tenant. The infrastructure may be shared. The client thought they were buying a service, but now they need to understand the licensing model underneath it just to evaluate whether they are getting a fair deal.
If you are buying automation as a managed service, make sure you understand upfront who owns the environment, who holds the licenses, what happens if you want to change vendors, and what the licensing cost would be if you had to carry it yourself.
How This Happens
Most of the time, nobody is being malicious. It happens because the project is driven from the implementation side first.
The team proves the process can work. The workflow gets built. A development environment exists somewhere. Everyone assumes the commercial side will be straightforward later.
Then later shows up. And later turns out to include platform fees, user licensing, robot licensing, usage-based costs, hosting questions, support boundaries, tenant ownership, renewal terms, and procurement review.
Suddenly the project is technically ready but commercially incomplete.
This is frustrating for everyone involved. The customer feels like the vendor built something without clearly showing the end-state cost. The implementation partner feels like they did the technical work and are now stuck explaining a pricing model the customer does not like. And any third party asked to help late in the process gets pulled into a trap: asked for a precise answer without being given the inputs needed to produce one. That is where a lot of unpaid “helpful expert in the middle” work starts.
The reality is that both sides usually share some responsibility. Clients can push harder early on for clear answers about production costs and ownership. Partners can do a better job of explaining the full commercial model in plain language before the build gets too far. When neither side forces clarity early enough, the result is a project that is technically finished but commercially unresolved.
The Real Mistake
The mistake is not underestimating software cost. The real mistake is failing to define the production model early enough.
Before a serious automation project gets too far, someone should be able to clearly answer six questions about total cost of ownership:
1. What does it cost to build? This is the part most implementation partners get right. It is also the part most buyers focus on. But it is only one piece.
2. What does it cost to run? What platform, user, and robot licenses are required for production? What do they cost annually? Are they billed directly to you, or bundled into a managed service fee?
3. Who owns the infrastructure? Where does the solution run? Who owns the servers or cloud environment? What are the ongoing hosting costs?
4. Who supports it when something breaks? Is support included in the build cost, or is it a separate contract? What does it cost? What does it cover?
5. What happens when you scale? If you want to add more automations later, how does the cost change? Does the platform fee stay flat, or does it increase with every new process?
6. What changes at go-live? What moves from development assumptions into production obligations? Are there new licensing requirements, infrastructure changes, or support contracts that only kick in at launch?
If those questions are still fuzzy after the build is complete, the project is not really ready for go-live. You do not just have a pricing question. You have a project planning problem.
This Is Not Just a Planning Lesson
It changes how automation projects should be scoped from the start.
This is exactly why we built DigitalStaff around total cost of ownership from day one. Our discovery process is designed to surface these questions early, before you commit to a build. We do not start building until you know what production will cost, who owns what, and whether the business case still works under real operating conditions.
We also take a different approach to the technology itself. Enterprise platforms can absolutely make sense when governance, scale, auditability, and a large automation program justify the overhead. But for many small and mid-size businesses running a handful of automations, defaulting into a heavyweight platform with significant annual overhead is not the best path. We build automations using modern, lightweight tools with transparent and predictable hosting costs. In many cases, a simpler stack with clearer ownership produces a much better ROI.
That is not ideology. It is just good business.
Our model reflects this:
Discovery. Define the production architecture, ownership model, and total cost of ownership before building anything.
Build. Implement with the lightest stack that can reliably solve the problem.
Managed Services. Keep it running with clear monthly ownership, support, and no surprise fees.
Final Thought
If nobody can clearly tell you what it will cost to run, who owns the environment, and what go-live requires, the project is not actually finished.
Oscar ONeill is the founder of DigitalStaff, an AI and automation consultancy that helps small and mid-size businesses automate their operations without enterprise-level complexity or cost. If you are evaluating an automation project and want to stress-test the architecture, ownership model, and total cost of ownership before you commit, book a discovery call.
