1. ARCHITECTURE RISK: 4/5 (high) The stack is a single Node.js/Express monolith on a single AWS EC2 instance with a Postgres RDS backend — no load balancer or auto-scaling described. This is a classic single point of failure: one instance going down takes the whole product offline. For a Series A company processing payments, this is riskier than typical, since payment reliability directly affects customer trust. No mention of a staging environment or CI/CD pipeline is a tech-debt signal worth probing. 2. SCALABILITY CEILING: Likely strains somewhere between 5,000-20,000 concurrent users on a single EC2 instance, depending on instance size (not specified). The Postgres database will likely become the bottleneck before the app server does, especially without connection pooling or read replicas mentioned. First fix needed: horizontal scaling of the app tier behind a load balancer, and a read replica for the database. 3. SECURITY POSTURE: 2/5 (needs attention) — the description doesn't mention encryption at rest, a WAF, or dependency scanning. Cannot assess actual auth implementation quality from the info given — this needs a direct code-level review, not an assumption either way. 4. KEY-PERSON RISK: High. The description states one founding engineer built the entire payments flow solo. If they left, onboarding a replacement to a payments-critical monolith with no documentation mentioned would be a multi-month risk window. 5. RECOMMENDATION: - Ask for the incident/uptime history over the last 6 months — a single-instance architecture with good uptime suggests operational discipline; frequent incidents confirm the architecture risk. - Ask who else on the team can deploy and debug the payments flow without the founding engineer. - Ask whether PCI compliance requirements have been reviewed given they're processing payments directly. - Ask about their disaster recovery plan for the single database instance.