Highlights
- Took the initiative as a first-year analyst to automate appointment scheduling after the existing UiPath team could not, building a working MVP and earning leadership buy-in that moved me onto automation full-time
- Evolved the product across four architectural generations: coordinate-based Python MVP → headless Selenium → AWS EKS orchestrator with SQS-fed containerized worker fleet → API-based AWS ECS
- Engineered a high-volume scheduling system responsible for scheduling 360,000+ appointments across all 50 states in PY25, automating an estimated ~152 FTEs of manual effort
- Promoted to lead of automation and optimization on the strength of the work; grew the function from a solo effort into a nine-person team
Project Narrative
I joined the Department of Veterans Affairs Medical Disability Examinations (MDE) project as an analyst. The team consisted of roughly 15 at the beginning of the engagement and struggled to stay alive. This number would scale up to 1000+ by the beginning of 2026 and is one of the largest engagements in the firm.
The work was heavily manual, and a separate automation team had adopted UiPath to pick up some of the workload as the platform was basic and the owners of the application were difficult to work with, but they had been unable to create any solutions most notably in scheduling, the highest-volume task on the account.
On my own initiative I approached the senior manager with my proposed solution for a framework for appointment scheduling. What followed was four generations of the same product, each one a step up in engineering sophistication and in what the system was worth to the business.
Phase 1 — Proof of concept (Python, coordinate-based)
My first MVP was a Python script that drove the scheduling platform’s UI through x-y coordinate clicking. It would query the database for cases meeting a basic criterion and would loop through them, scheduling through the web app.
It was crude and tied up a workstation that had to stay powered on all day and struggled with anything beyond the simplest cases, but it scheduled real appointments and proved the concept.
At this stage I was teaching myself automation from a standing start and the early tool facilitated 15,000+ appointments within a year, contributed roughly $1.8M in gross revenue, and did the work of about 5 FTEs.
After the initial success, leadership moved me onto automation/optimization full-time where I was the sole member once the original UiPath team was unable to create a working solution anywhere in the business.
Phase 2 — Productionizing (headless Selenium)
I rebuilt the system on Selenium, which let it run headless and no longer be dependent on a machine staying on. Additionally, I expanded its business-rules coverage so it could handle the complex cases the MVP had choked on. This was the jump from being just a simple script to maintaining a software solution.
By this point the system was autonomously handling roughly 15% of the project’s scheduling workload across a population of 140K+ unique veterans.
Phase 3 — Scaling under load (AWS EKS, queue-based workers)
When the contract expanded and volume spiked by 5x, it quickly overwhelmed my solution. I re-architected the system using Kubernetes and deploying in EKS. An orchestrator pushed scheduling jobs onto an SQS queue and a fleet of containerized Selenium workers pulled and executed them in parallel.
At this point I went from being on my own to working to with 2 managers fulltime assisting with business requirements, a consultant and an analyst to support where I was the lead developer.
Phase 4 — Simplification (AWS ECS, native APIs)
After sustained effort, we eventually got the application owners to deliver proper APIs. With direct integration available, the Selenium worker fleet was no longer necessary, and I moved the system to AWS ECS to remove the complexity I’d previously been forced into.
Furthermore, the query was refactored for speed and increasing the breadth of variety of possible cases to schedule. The code was made more efficient and eventually we worked to achieve a 90x increase in speed with scheduling. What took an hour now finishes in well under a minute.
In addition, to support the new complexity of business rules and volume. We used Google’s OR-Tools to balance business requirements and optimally schedule as many veterans as possible.
Today the system handles roughly 50% of the entire project’s scheduling workload: 360,000+ appointments across all 50 states in PY25, automating an estimated ~152 FTEs of manual effort and anchoring an automation portfolio that drove ~$35M in margin on $170M+ in revenue.
Throughout, the MDE engagement’s transactional pricing model meant each scheduled appointment mapped directly to a billed item so every gain in the system’s throughput was a direct gain in recognized revenue. The work also redefined my role: what began as a solo side project became the basis for my promotion to lead of automation and optimization, and the function grew from just me into a nine-person team.