Prototyping and Customer Engineering at Amazon Web Services

Who is PACE @ AWS

Innovation can seem difficult and risky, especially for companies that lack the resources to pursue it. Not every company has the extensive IT resources needed to invest in modernization on its own.

That's where a partner like AWS helps: bringing guidance, thought leadership, and development muscle so customers can stay competitive and profitable.

Sometimes a long-term vision needs a short-term experiment to unblock a tricky problem, evaluate technical direction, or simply build trust and momentum.

AWS's Prototyping and Customer Engineering (PACE) team defines, executes, and delivers fast-paced prototypes that provide business value for customers across industries like Automotive, HCLS, Manufacturing, and Entertainment.

How I Came to Work With PACE

After AWS TechU (Amazon's internal training program for building the next generation of solutions architects), my builder-focused approach was identified as a strong fit for PACE.

Not all solutions architects were developers, but I'd insisted from start on not being behind a PowerPoint all day.

What Problems I Solved for Customers at PACE

From 2022 to 2026, most of the problems I helped solve came down to one question: how should AI systems integrate with existing infrastructure to deliver real value to end users? Some prototypes were for consumer-facing applications, others for internal business tools.

The common thread was taking data from several sources and engineering a system that could dynamically organize it into a format that delivered faster insights at lower cost.

Over that span, I delivered 23 customer and internal engagements across healthcare, automotive, manufacturing, media, gaming, telecom, and enterprise software, building everything from computer vision pipelines to multi-agent orchestration systems, usually on a 4–10 week clock per engagement.

For Example...

Have video archives you want indexed into short clips to sell to editors and documentarians? Sure. One media archive engagement hit ≥90% clip accuracy and a customer satisfaction score high enough that leadership committed to moving it into production.

Need a predictive dashboard for medicinal product launches that forecasts potential regulatory issues? Sure. One healthcare engagement cut data retrieval time from over an hour down to two seconds, with 90% accuracy on root-cause analysis of launch delays.

Want to switch to an interactive voice response system, powered by your internal documents, that can intelligently interact with customers within defined guardrails? Sure. One contact-center engagement in the pharmaceutical space automated 25–60 minute nurse calls into a virtual assistant interaction.

There are a lot of ways to turn data into value: better getting it to the people who need it, optimizing a process to save time, or making a business smart enough to save money somewhere else entirely.

One of the best parts of working in PACE was the variety and agility of the work. Every prototype was a short-term engagement with a different business case, different technology preferences, and different restrictions and considerations.

Engagement Structure

Working with customers to modernize and innovate is the name of the game, but what did that actually look like in practice?

Customers are usually referred to PACE by their account teams, who introduce the people, the problem, and the long-term roadmap the customer hopes to make progress on through the prototype. That usually comes with some formal documents to review before the first customer meeting.

Once that prep is done, the account team hands us the reins for an initial discovery session, led by the solutions developer.

This meeting is about learning directly from the customer: how they got here, and where they want to be by the end of the engagement. For me, that meant asking the questions that would shape the tech stack, budget ownership, and security posture.

It was just as important to learn the domain I'd be working in as it was to understand the customer's appetite for different kinds of solutions.

Next comes the scoping proposal, a formal agreement on the key aspects of the project: what the problem and goals are, how success will be measured, user stories and mockups, the proposed architecture, and the bill of materials required from both sides.

This is the hardest part of the engagement to get right, and also the most important. It takes good judgment, solid technical range, and real people skills. Get it wrong and you either walk into a weak solution or the wrong solution for the customer, and either one costs you their trust.

A few examples of what "success" looked like once a scoping proposal turned into a shipped prototype:

• An automated video localization pipeline cutting cost per video by more than 95% (roughly $5 vs. $130 manually)
• A multi-agent orchestration system hitting 95.91% routing accuracy while scaling to 200+ agents
• An internal FinOps tool cutting manually written SQL by 90%
• A search and discovery feature moving from minutes to sub-second results, later taken into production by the customer
• A media asset pipeline reducing manual tagging effort by more than 99%

Every one of those numbers started as a line item in a scoping proposal, agreed on with the customer before a single sprint began.

Want a concrete play-by-play? Check out a sample engagement here, walking through how a scoping conversation actually shifted the direction of an engagement.

Then comes the bulk of the engagement: the dev sprints, where the plan from the scoping proposal gets executed. Communication with the customer doesn't stop here: engagements go better when the customer stays consistently engaged through development. That meant reporting progress weekly through presentations and emails, adjusting the tone and technical depth depending on who was in the room.

Once the architecture is implemented, the emails are sent, the customer is looped in, and the success criteria are met, it's time for the closeout presentation.

This is where I laid out proof that we'd hit the success criteria, made the case for why this solution fit the customer's context, and shared what we'd learned, along with what they'd need to consider heading into production.

This is also where we confirmed customer buy-in through a survey and made sure they understood how the prototype could grow and evolve inside their organization.

Right around that time, intake for a new engagement usually starts, and the process begins again in a new context. But there's one more step first: handing the prototype off to the team that will build on top of it, through a technical knowledge transfer covering the implementation and recommendations for bringing the solution into production.

What Was the Team Like?

Working on PACE demands a lot of ownership: over code, over architectural decisions, over customer outcomes, over contributions to team goals. But I was never really alone.

The team was incredibly collaborative, which I think reflects Amazonian culture more broadly. No developer or manager was too precious with their time to offer guidance or point me toward a relevant solution.

Prototyping engagements typically used one or two developers at a time, which meant long stretches without much cross-collaboration between any two people on a given project.

To keep knowledge flowing across the team anyway, we were all encouraged to contribute to thought leadership: blog posts, workshops, trainings, and internal tools.

The team was also full of genuinely sharp developers and discerning managers. I was lucky to work alongside people like that.

Some Things I'm Taking With Me

Being a Solutions Developer was one of my first roles as a computer scientist, and I'm grateful to have had such a challenging, demanding, and rewarding experience at an organization with this much reach.

Agility under pressure is probably the skill that grew the most in this role. Big decisions had to be made quickly, and judgment calls requiring both technical depth and business sense were routine.

Collaboration was the backbone of the role. There was no succeeding alone. I learned quickly when and how to pull others in for help, and over time I realized my own experience could be an accelerator for other developers facing problems I'd already worked through. It costs almost nothing to let compounding expertise reduce risk and unblock people faster, and I learned it's always worth working out loud.

Executive exposure came with the territory. I worked with business leaders at every level, some at the C-suite, and got a real look into how enterprise businesses think and prioritize. I became comfortable moving between conversations with senior technical contributors and executives focused on the "why" and "so what" of a project.

Cloud DevOps was the bread and butter of the role. I've deployed to AWS thousands of times, across many environments and many projects.

Working with other developers on a single architecture in a single account can be tricky: reconciling differences both technically, through source control, and architecturally, through design decisions that don't always agree.

Long-term open source contributor to AWS Media Replay Engine, leading the GenAI natural-language video search release (v2.10.0).