AWS Sales Planning Tool: Adoption & Impact Case Study

Problem

A sales-account-planning tool had been built in an AWS hackathon and then drifted into the hands of real account teams who loved it. The business problem: the teams relied on it daily to plan customer accounts, but it was fragile enough that a bad deploy could take away the tool they ran their week on. It had one environment, auth held together with tape, deploys pushed from a laptop, and a core workflow so click-heavy that people avoided it.

The goal was to keep the teams that already depended on it, get more of them using it, and add the features they actually asked for, without ever breaking their day.

Process

I started by watching three power users work, not by reading the code. The revealing finding: the biggest drag wasn't a missing feature, it was a modal-on-modal-on-modal pattern inherited from an early UI experiment. Updating an account's status and adding a note, the single most common thing anyone did, took 9 clicks across 3 dialogs. That decision, to fix the hot path before adding anything new, shaped the whole engagement. We deferred a requested reporting module until the daily workflow felt fast.

From there:

Killed the click tax. Replaced the nested dialogs with inline edit-in-place, taking the most common workflow from 9 clicks to 3.
Made it safe to grow. Split deployment into dev, staging and prod with a CDK stack per environment and per-stage approval, ending all laptop deploys so the tool stopped going down mid-week.
Auth done once, properly. Replaced the patched sign-in with Cognito federation against the corporate identity provider, with roles modelled in the app.
History teams could trust. Every plan edit emitted a structured event, surfaced in a "who changed what" panel so account managers stopped losing track of edits across a team.

I shipped every change behind feature flags and kept existing users informed, so the tool they relied on never stopped working.

Outcome

The most common workflow dropped from 9 clicks to 3, and weekly active account teams rose roughly 40% over the following quarter as word spread that it was faster and no longer flaky. Deploys moved off laptops into a staged pipeline, so the tool stopped disappearing mid-week. What had been "the prototype that became real" turned into a maintained internal product people chose to open every morning.

"It went from the thing we tolerated to the thing we plan the week in. The speed difference is night and day."

Account team lead

Architecture

For engineersTechnical Deep Dive

Expand

Stack

React + TypeScript (Vite) → S3 + CloudFront
   │
   ▼
API Gateway (HTTP API) + Lambda
   │
   ├─ DynamoDB (single table: PLANS, ACCOUNTS, USERS, HISTORY)
   ├─ DynamoDB Streams → Lambda → S3 archive
   └─ Cognito (federated IdP) for auth

Single-table DynamoDB

Five entity types lived in one table:

Entity	PK	SK	GSI1PK
Plan	`PLAN#<id>`	`PLAN#<id>`	`ACCOUNT#<accountId>`
Account	`ACCOUNT#<id>`	`ACCOUNT#<id>`	n/a
User	`USER#<id>`	`USER#<id>`	`EMAIL#<email>`
HistoryEntry	`PLAN#<id>`	`HIST#<timestamp>#<id>`	`USER#<userId>`
Comment	`PLAN#<id>`	`COMMENT#<timestamp>#<id>`	n/a

Single-table design isn't dogma. It was the right call here because every read pattern was already keyed by either the plan or the account, and we didn't need ad-hoc analytics queries (those went to the S3 export).

CDK structure

One stack per environment, instantiated by a cdk.context.json per stage. Constructs were composed:

new SalesPlanningStack(app, `sales-planning-${stage}`, {
  stage,
  env: ENV_CONFIG[stage],
  ssoConfig: SSO_CONFIG[stage],
  retention: stage === 'prod' ? RetentionDays.ONE_YEAR : RetentionDays.ONE_MONTH,
});

CDK over Terraform here because the rest of the AWS internal tooling ecosystem was on CDK and the team's JavaScript skills made stack-level edits trivial.

History pipeline

DynamoDB Streams captured every write. A small Lambda transformed the stream record into a structured history event (who, what changed, before/after) and pushed it to a separate table partitioned by plan, plus an S3 archive. The history-panel UI queried that table directly, scoped to the plan being viewed.

UX work

The biggest single win was killing the modal-on-modal-on-modal pattern. Users were drowning in nested dialogs to edit a plan. Replacing it with inline edit-in-place reduced the most common workflow (update an account's status and add a note) from 9 clicks across 3 modals to 3 clicks inline, the change that drove the jump in daily use.

Trade-offs

No major rewrite. Tempting to start fresh with the design we wanted. Wrong call here: the existing users would have lost their tool while we rebuilt. Refactor in place, ship behind flags.
Federated sign-in over per-app users. More effort up front, but a separate identity store would have been a maintenance and security headache we'd never escape.