A Boardroom Simulator You Can Lose
I built an app over a weekend for the AWS Weekend Creative Challenge.
You type a paragraph describing an AI initiative. Four executives read it and object, out loud, in character.
- The Chair wants to know who the customer is.
- The CFO wants the number.
- The Chief Risk Officer wants a name against the failure.
- The CEO thinks it is too small.
Then you get a score out of 100 and the three questions you are least ready for.
The part I care about
Before you pitch, you pick a market and an industry. Or you paste a document and let the app work them out.
The same pitch then faces a different room in each.
| Market | What the room asks first |
|---|---|
| Singapore | Who else in the region already runs this? |
| Japan | Which departments have agreed to it? |
| Jakarta | Who operates it once the launch team goes home? |
Run the built-in example against Singapore and it scores 100. Run the same text against Japan and it scores 80.
The twenty points it drops are a reference to MAS FEAT. That means nothing to a board in Tokyo.
There is no single APJC playbook. Carrying one argument into six markets loses five of them.
The board speaks
Each member has an Amazon Polly voice. The Chair takes the accent of the market you selected.
Jasmine for Singapore. Olivia for Australia. Kajal for India.
The other three keep fixed voices so you can tell who is talking.
Reading four objections on a page is homework. I wanted it closer to sitting in the room.
Where I chose not to use a model
Most of the design went into deciding where a model should not go.
The model does not score the pitch. It extracts nine signals from your text. Ordinary code then decides what those signals are worth.
Putting the rubric in the prompt would have broken three things:
- The same pitch would score differently across runs.
- A confident pitch with no customer would talk its way to a high score.
- Nobody could audit why a verdict came out the way it did.
Customer obsession is a gate, not only a weight. It carries 40 of the 100 points.
A pitch that names no customer cannot be approved, whatever else it scores. The Chair’s opening question is hardcoded and identical in every run.
A board member you can charm into skipping that question is not a useful simulator.
Architecture
Two independent paths on the same account.
The request path serves the app. Amazon S3 hosts the frontend. Amazon API Gateway fronts a Lambda handler. Amazon Bedrock writes the objections and Amazon Polly narrates them.
The weekly path maintains reference data. Amazon EventBridge triggers a second Lambda that proposes new case studies, then verifies each one against its cited source before opening a pull request.
That agent never merges. Code checks every claim the model makes.
What went wrong
A new AWS account can have zero Bedrock quota. My account was hours old. Service Quotas showed every on-demand value for Nova Lite reading 0.0, marked not adjustable.
So the app serves a template board, badged as such in the interface. I wrote that fallback on day one for a failure I had only imagined.
Amazon Polly is why this is still a creative app. With Bedrock at zero I tested the other AI services. Comprehend and Translate both refused. Polly answered on the first call.
The constraint produced a better app than my plan did.
The bug I am most glad I found had nothing to do with AWS. My frontend defined a local escape() helper. It silently shadowed the browser built-in my permalink encoder was calling.
Every shareable link produced garbage, failed to parse, and did nothing. A catch block swallowed the error.
It surfaced only when I bundled the app differently. Silent catch blocks hide the failures you most want to see.
The wider library
The case studies behind this app grew into something separate.
The APJC AI Playbook covers 50 cited cases across AWS, Azure and Google Cloud. Filter by country, industry, vendor and year.
Every card states only what its source states. Where there is no published number, the card says so.