diff --git a/README.md b/README.md
index 1df2db7..c5ffea9 100644
--- a/README.md
+++ b/README.md
@@ -9,6 +9,8 @@
 ![Terraform](https://img.shields.io/badge/Terraform-5C4EE5?style=for-the-badge&logo=terraform&logoColor=white)
 ![GitHub Actions](https://img.shields.io/badge/GitHub%20Actions-2088FF?style=for-the-badge&logo=githubactions&logoColor=white)
 
+![Underflow overview](./apps/web/src/assets/showcase/overview-light.png)
+
 Live app: [underflow.md-dev970.com](https://underflow.md-dev970.com)  
 Technical walkthrough: [Architecture Overview](./docs/architecture.md)
 
@@ -49,24 +51,18 @@ flowchart LR
     User["Browser User"] --> Web["React Web App"]
     Web --> API["Express API"]
     API --> DB["PostgreSQL"]
-    API --> AWS["AWS Services<br/>STS / Cost Explorer / SES"]
+    API --> AWS["AWS Services"]
     Worker["Alert Worker"] --> DB
     Worker --> AWS
     Schedule["EventBridge Schedule"] --> Sync["Scheduled Cost Sync Lambda"]
     Sync --> DB
     Sync --> AWS
-    API --> Customer["Customer AWS Accounts<br/>AssumeRole"]
+    API --> Customer["Customer AWS Accounts"]
     Sync --> Customer
 ```
 
 Underflow separates the customer-facing frontend, the API, the scheduled sync runtime, and the alert worker so cost collection, alert evaluation, and notification delivery can run independently from the UI. The backend assumes customer roles only when needed, while synced reporting data stays in PostgreSQL for fast dashboard queries.
 
-## Why This Project Is Credible
-
-- it spans product UI, backend services, background jobs, cloud integrations, and infrastructure
-- it uses real production concerns such as session invalidation, CSRF protection, ECS deployment, SES email, CI/CD, and Terraform-managed AWS resources
-- it is deployed live, not just developed locally
-
 ## Tech Stack
 
 ### Backend
diff --git a/docs/architecture.md b/docs/architecture.md
index 1b42ab1..7f12fb8 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -109,9 +109,3 @@ Email is treated as a real integration boundary rather than a mocked afterthough
   - shared DB/AWS/logging config is used by API, worker, and Lambda
   - auth/cookie-specific config is validated only in the API runtime
 - Some cloud integrations are fully wired but still benefit from live-account validation before they should be considered fully hardened
-
-## What A Reviewer Should Notice
-
-- The project goes beyond UI work and touches auth, DB migrations, cloud integrations, background jobs, testing, and infrastructure
-- Production concerns are visible in deployment, session handling, logging, and cloud access patterns
-- The implementation is broad enough to demonstrate end-to-end engineering ownership, not just isolated feature work
diff --git a/docs/status-and-limitations.md b/docs/status-and-limitations.md
index ba84963..8bd44c3 100644
--- a/docs/status-and-limitations.md
+++ b/docs/status-and-limitations.md
@@ -57,13 +57,3 @@ The repository keeps billing disabled by default for the current public/open-sou
 - env files are created from the provided examples
 - AWS/Stripe/SES credentials are optional unless you are validating real integrations
 - the repo is being used as an engineering showcase and active build-out, not as a turnkey SaaS product
-
-## Presenting This Repository Honestly
-
-The strongest framing is:
-
-- this is a serious full-stack engineering project
-- it includes real production-style concerns
-- it is still being actively developed and integrated
-
-That framing is more credible than pretending every integration is already production-ready.