Building an Automation Function from Nothing
How I took a mobile application security company from no automation function to a multi-layer team, a shared engineering foundation, and a customer-facing product.
The problem
When I joined a mobile application security company, there was no automation function. There was no team, no framework, and no shared way of building. Every automation was written from scratch, which meant every new project repeated work that had already been done, and quality depended on whoever happened to build it.
I saw the problem before anyone asked me to solve it, and I started building.
What I built
A shared framework. I designed a cross-platform automation framework in Python and Swift that worked across iOS and Android, with a shared, versioned telemetry schema so results meant the same thing on every platform. It became the foundation everything else ran on.
A generator instead of a starting line. I built a command line tool that created every new project from versioned templates. Engineers no longer started from a blank page, and every project began consistent, current, and aligned with our standards, without anyone distributing files by hand.
Data reporting that people actually used. I built our data reporting systems from scratch, including a pipeline that turned raw API output into structured reports used every day to monitor quality. Those systems reached a 98% adoption rate across custom automations.
A product customers relied on. The framework grew beyond an internal tool. It became a customer-facing, self-service product feature and the foundation of a revenue-generating managed testing service. I worked directly with demanding customers to design solutions for their automation needs, negotiating strict SLAs, identifying attack surfaces, and advising on application design and usability.
How I built the team
Good systems need people who can carry them. I scaled the team from two engineers to nine and built everything a team needs to grow: a hiring framework, career paths, performance standards, a compensation structure, and an internship pipeline. As we grew, I organized the team under leads who managed their own reports, across four states and the Philippines, supported by governance, workflows, and documentation that made our work repeatable.
The result I am proudest of: every engineer on my team was promoted at least once. One moved into an SDET role on the engineering team. Another, whom HR had passed over because he was not an exact match on paper, earned two promotions to Lead Automation Engineer and later went on to law school.
The results
- From nothing to an automation function, team, and leadership structure
- One shared framework that replaced from-scratch work across the team
- 98% adoption of data reporting across custom automations
- A product and a service: a customer-facing feature and a revenue-generating service line built on that foundation
- Every engineer on my team promoted at least once
What I learned
Build it once, then build on it.
The biggest gains came from refusing to solve the same problem twice. A framework, a template, or a standard pays for itself every time someone does not have to start over.
Build it, then hand it off.
The best systems do not depend on the person who created them. I measure my work by how well it runs without me.
Recognition matters too.
I tend to choose education over accolades, giving people room to learn even when the outcome is uncertain. I still believe in that, but I have learned to fight just as hard to make sure the people on my team are recognized for their work.