Ask a roomful of founders what they plan to automate first, and most will point at the work they understand least. Deployment pipelines, reporting, customer onboarding, anything that feels tedious from the corner office tends to land at the top of the list. Entrepreneurs who have actually built automation into the core of their companies argue the opposite: the work you understand least is the last thing you should hand to a machine.
The Rush to Automate the Wrong Layer
Automation has become a reflex in early-stage companies. Tooling is cheap, integrations are everywhere, and every SaaS vendor promises to eliminate a category of manual work. The result is that many founders automate before they diagnose. They wire together scripts and platforms around processes that were never clearly defined, and the automation quietly encodes every ambiguity that already existed.
Pablo Gerboles Parrilla, a Spanish entrepreneur who runs a portfolio of bootstrapped companies, founded Alive Devops around exactly this problem. The company has spent years applying automation-first thinking to software infrastructure. His position is that automation amplifies whatever it touches. A well-understood process becomes faster and more reliable. A confused one becomes confused at scale, and now nobody remembers how it worked by hand.
Understand the Work Before You Delete It
The founders who get automation right tend to share a habit: they do the manual version first, long enough to know exactly where the friction lives. That runs against the standard advice to delegate early and ruthlessly, but it produces sharper decisions about what deserves engineering time. Gerboles Parrilla holds that a founder who has personally run a process can specify its automation in an afternoon, while a founder who has only observed it will spend months iterating on the wrong requirements.
This ordering also protects companies from a less obvious failure. When a process is automated by someone who never understood it, the organization loses the ability to question it. The workflow hardens into infrastructure, and infrastructure rarely gets interrogated. Teams inherit steps nobody can explain and constraints nobody can trace to a decision.
Thirty Minutes a Night, for Years
One of the clearest examples in Gerboles Parrilla's own portfolio is also the smallest. His mother runs a bakery, and every night, someone on her team spends roughly thirty minutes translating the day's incoming orders into a production sheet for the factory the next morning. It was unglamorous work, perfectly understood, and endlessly repeated. He built custom software that reads the incoming orders and generates the morning production sheet in a single click.
The project would never make a pitch deck. Still, it illustrates the pattern he looks for everywhere: high frequency, low ambiguity, and a human who can describe every step without hesitation. Those are the processes that pay back automation almost immediately. The exotic, ill-defined workflows that founders find most annoying are usually the worst candidates, because the annoyance is a symptom of a process problem no script can fix.
The Dashboard Trap
The same overreach shows up in how companies instrument what they have automated. Monitoring platforms make it trivial to track hundreds of metrics, so teams do, and the signal gets drowned out. Gerboles Parrilla, whose infrastructure work centers on observability, is blunt about the failure mode.
“The goal isn't to track everything; it's to know what matters and why it's happening,” he says. A dashboard with 40 panels is a confession that nobody decided which three numbers actually describe the system's health. Automation without that editorial judgment produces the strange modern condition of teams that measure everything and understand very little.
The Automation You Skip Sends an Invoice Later
Founders also misjudge automation in the other direction, treating resilience work as optional because it produces no visible feature. Gerboles Parrilla's team once recommended multi-region redundancy to a client whose budget did not yet stretch that far. When a regional cloud failure later brought the client's application down for roughly 8 hours, the gap became very apparent. The relationship survived because his team had documented the recommendation and handled the incident with full transparency, but the lesson was expensive.
The point applies well beyond infrastructure. Every automation decision is a risk decision. Choosing not to automate a failover path, a backup, or a verification step means accepting a specific failure at an unspecified time. Founders who frame these choices as cost line outages.
Systems Are What Make Ideas Durable
There is a cultural objection that surfaces in creative businesses: the worry that automation flattens the work. Gerboles Parrilla, whose ventures span software, live entertainment, and marketing operations, rejects the premise. “Creativity brings ideas to life, but systems make them sustainable,” he says. In his companies, automation handles the repeatable substrate, reporting, scheduling, and data movement, so the people involved can focus on judgment and craft.
Framed that way, the founder's job changes. The question stops being which tasks to eliminate and becomes which decisions deserve a human every single time. Everything beneath that line is a candidate for a system. Everything above it should stay stubbornly manual, no matter how capable the tooling gets.
AI Raises the Stakes on Judgment
Generative AI compresses the cost of building automation to nearly zero, which sounds like an unqualified win until you notice what it does to bad automation. Poorly conceived workflows can now be produced in minutes and multiplied across a company before anyone has examined the underlying process. Gerboles Parrilla views AI as leverage for founders who already have clarity, and as an accelerant for those who do not. The technology changes the execution speed, but it leaves the quality of the founder's understanding exactly where it was.
Gerboles Parrilla learned this discipline long before he wrote a line of business software, and the entrepreneur's approach still traces back to his years in competitive golf. The sport taught him that repetition reveals which details matter, and that no shortcut substitutes for doing the work yourself. Founders reaching for automation would do well to borrow the sequence: understand the swing completely, then, and only then, build the machine that repeats it.
