Rova is a composite company. Its founders, engineers, and investors are fictional. Its problems are not.
The damage does not announce itself. That is the thing about AI-generated architectural debt — it accumulates quietly, in decisions that each look reasonable at the time, until the month when it suddenly is not quiet anymore.
For the founders of Rova, that month was month fourteen. The conversation happened on a Tuesday afternoon. Their lead engineer, Marcus, sat down with Priya and Daniel and said the words that cost more than any architecture decision they had made: we need to talk about the codebase.
This post traces the six decisions that led to that conversation — each one made with Claude's guidance, each one individually defensible, together forming a system that moved at half the speed it should and cost twice what it needed to. The goal is not to assign blame. Claude is a genuinely useful tool. The goal is to make the pattern visible before you are inside it.
At Digital Scientists, the approach we call Build to Horizon exists specifically because of patterns like this one. You design for what you can see and measure clearly — your actual team size, your real customer count, your honest runway — and no further. When Rova pivoted eight months later, the tragic irony was that the complex architecture they had built was suited to neither their original direction nor their new one. They had overbuilt for a future that did not arrive, in a direction they had already left.
Month 1: The Setup — Two Founders and One Engineer
Priya ran operations at a regional SNF group for eight years. Daniel is a former healthcare consultant. Neither writes code. They hired Marcus — a capable full-stack developer, referred through their network — as their first engineer. Marcus is good. He has not built a multi-tenant SaaS platform before.
What Priya and Daniel do have is Claude. They use it well in those first months — pitch deck, market analysis, outreach emails, SOW templates. This is Claude at its best: orientation and acceleration in domains where they can evaluate the output. The trouble starts when they point it at technical decisions they cannot evaluate.
Month 2: When AI Over-Engineered the Database
Priya asked Claude how to structure the database for a multi-tenant healthcare SaaS. She described their stack — PostgreSQL on RDS — and mentioned they were in pilot with two customer groups.
Claude recommended schema-per-tenant with PgBouncer for connection pooling and cross-tenant materialized views for analytics. The recommendation was thorough, mentioned HIPAA, and came with 80 lines of SQL. Priya sent it to Marcus: "Claude says schema-per-tenant makes sense for HIPAA compliance. Can you implement this?"
Marcus had reservations — this felt more complex than two pilot customers warranted — but the recommendation came with a rationale, cited a regulatory framework, and he did not feel confident enough to push back against what looked like considered technical guidance.
Month 3: API Versioning Nobody Needed
Daniel asked Claude about REST API best practices. Claude gave a comprehensive guide to versioning strategies and recommended building the versioning structure from day one. "Claude says this is how you do it properly. We want to do it right from the start."
/v1/ directory. Every engineer who joined afterward asked why. The first external integrator did not arrive until month nineteen.Month 5: A Real-Time System for 40 Users
Marcus asked Claude how to build a real-time notification system. Care coordinators needed to see alerts when patient conditions changed. Claude recommended WebSockets with Socket.io, a Redis pub/sub layer for horizontal scaling, per-tenant notification channels, and a Bull queue for async delivery with retry logic.
The architecture was designed for thousands of concurrent users requiring sub-second updates. Rova had 40 users. The relevant events happened on a human timescale.
Rova didn't have a technical advisor. You can.
Senior engineering guidance without the full-time hire — architecture review, risk identification, and honest recommendations before you commit.
Learn About Technical Advisory →Month 7: A Full RAG Pipeline Before Product-Market Fit
Priya asked Claude how to productize her vision feature: care coordinators querying patient documentation using natural language. The prototype already worked — paste documents into Claude and ask questions. Claude recommended a full RAG pipeline: OpenAI embeddings, Pinecone with per-tenant namespaces, Cohere reranking, eleven architectural components, four external vendor contracts.
AI Architecture Decisions: Impact Across Eight Dimensions
None of these decisions was catastrophic in isolation. The compounding is the problem. Below, each decision is scored across eight dimensions — bars measure operational burden, not capability. The Claude default always has a higher ceiling. The question is what you are agreeing to carry before you reach it.
How AI Architecture Debt Compounds Over 18 Months
By month 14, the gap between the two paths represents roughly one full engineer's worth of capacity — lost to coordination overhead, slower onboarding, and incidents that would not have happened on the simpler architecture.
Month 12: Engineers Rejected the AI-Built Codebase
Rova raised a seed round and began hiring. Both engineering candidates asked to review the code before accepting. Both passed. The feedback, delivered politely:
"The codebase has more infrastructure than I'd expect for this stage. Schema-per-tenant with PgBouncer, Redis-backed WebSockets, a full RAG pipeline with Pinecone and Cohere. None of it is bad engineering, but I'd want to understand who owns the operational complexity. It feels like the system was designed for a company further along than where you are."
Month 14: The Rewrite Conversation
Marcus sat down with Priya and Daniel. The next three roadmap features each required foundational changes before they could be shipped. Schema migrations across eleven customer schemas. Idiosyncratic WebSocket reconnection behavior. RAG pipeline iteration needed every time a customer uploaded a new document type.
Estimated recovery: a two-to-three month partial rewrite.
"Can we fix it?" Priya asked.
"Yes," Marcus said. "But some of it we have to rewrite."
What Non-Technical Founders Miss About AI Architecture
They did not do anything wrong by consulting Claude. They did what thoughtful non-technical founders do: used the best tool available to make decisions quickly and confidently.
What they did not know was that each Claude session was answering a slightly different question than the one they were actually in. They asked about multi-tenant databases and got an answer optimized for enterprise scale. They asked about real-time notifications and got an answer for thousands of concurrent users. They asked about document AI and got an answer for millions of documents.
Build to Horizon is the discipline that closes that gap. It shares a core principle with the monolith-first approach: start simple, prove the product, and add complexity only when you can measure the need. It starts with a stage assessment — actual team size, actual customer count, actual runway — before any architecture conversation begins. It treats Claude's output as a first draft, not a specification. And it defines the upgrade path at the time of the decision, so the simple choice today is never a trap.
We review your architecture decisions, find where the Build to Horizon gap is largest, and tell you what to build now versus later.
30 minutes · A real architect, not a salesperson
