Look up any customer's account and billing without AWS access

Build an internal support desk console that our customer support reps open every time a customer writes in, so they never have to ask an engineer to look someone up in the AWS console. The app is read only by default: it shows everything about a customer account, but only a small, explicitly whitelisted set of fields can ever be changed.

At the very top of the code, define a single configuration block that lists the editable fields, and let nothing else in the app grant write access. Start it with plan tier, seat count, and feature flags, each with a label, a type (string, number, or boolean), and for plan tier the allowed values. Every field that is not in that list still displays on screen so reps can read it, but it renders as static text with no edit control. Adding or removing an editable field should be a one line change in that block.

The main screen is a single search box where a rep types an email address, an account ID, or a customer ID. Look the record up in our DynamoDB accounts table: if the input looks like an email address, use Query against the table's email index; otherwise, and as a fallback when that Query returns nothing, use Get Item by primary key. Show a clear not found state when neither returns a record, and let the rep search again without reloading the page.

Render the matched record as a clean profile card, never as raw DynamoDB JSON. Unwrap the attribute value format so the rep sees real values, and lay out plan, seat count, entitlement flags, signup date, and account status as labelled fields with human formatting: dates as readable dates, booleans as clear on or off pills, and status as a badge. Group the entitlement flags together so it is obvious at a glance what the account has turned on.

Alongside the profile, show a billing panel with the customer's live payment picture from Stripe. Find the Stripe customer with Search Customers using the account's email address, then load their subscriptions with List Subscriptions and their recent invoices with List Invoices. Surface the current plan and price, the renewal or next billing date, and call out any unpaid, past due, or failed invoices at the top of the panel where the rep will see them first. If no Stripe customer matches, keep the profile card working and show a plain no billing record found message in the panel rather than an error.

For each whitelisted field, put an inline edit control next to the value. When a rep changes one, open a confirm dialog showing the field, the current value, the new value, and a required short reason box. The rep cannot confirm without typing a reason. On confirm, write the change back with Update Item using an update expression scoped to that single attribute, so nothing else on the item can be touched. Show the updated value in place and keep the rep on the same customer.

Every confirmed change also writes an audit item to a separate DynamoDB audit table with Put Item. Stamp it with the logged in rep's identity, the account ID, the field name, the before value, the after value, the reason the rep typed, and a timestamp. Write the audit item as part of the same action as the update, and if the audit write fails, tell the rep clearly rather than failing silently.

After the audit item is written, post a one line summary to a Slack channel with Slack Bot Send a Message, in the shape of: rep name changed field on account from old value to new value, reason. Set the target channel in the same configuration block at the top of the code, so the team has a visible trail without needing to open the app.

This is an interactive surface a person opens and works in, not an automation: nothing runs on a schedule or in the background. Keep it usable by someone who has never seen a database, make the guardrails visible by showing which fields are editable and which are locked, and never expose AWS or Stripe credentials to the rep.