# Architecture Scalability Assessment: Questions Every Investor Should Ask > The key architecture scalability assessment questions investors and technical reviewers should ask during due diligence. Covers load, data, cost, and failure handling. - **Published:** 2025-03-17 - **Author:** Clixo - **Reading time:** 6 min read - **Tags:** scalability-assessment, technical-due-diligence, architecture-review, investors - **Canonical URL:** https://clixo.sh/blog/architecture-scalability-assessment-investor-questions A product that works at current scale and a product that can scale to the size your investment thesis requires are meaningfully different things. Architecture scalability assessment is the part of technical due diligence that determines which one you are looking at. It is also the area where confident-sounding answers from founders most frequently diverge from what the architecture can actually support. Asking the right questions — and knowing what the answers actually tell you — is a skill that separates investors who get ahead of technical risk from those who discover it post-close. ## Why Scalability Assessment Is Not Just About Traffic The word "scalability" gets narrowed to load handling in most conversations, but in an architecture review it covers at least four dimensions: - **Load scalability**: Can the system handle more requests, more users, more data processing volume? - **Data scalability**: Can the data model and storage layer support the volume and query patterns the business will require at 10x or 100x current scale? - **Operational scalability**: Can the team operate the system effectively as complexity and user count grow? - **Cost scalability**: Does the unit economics of infrastructure hold at scale, or does the cost per user or per transaction increase as the system grows? A system can pass on load scalability and fail badly on cost scalability — particularly common in products with a per-request AI inference cost that has not been modeled at scale. ```mermaid flowchart LR A[Scalability Assessment] --> B["Load Scalability"] A --> C["Data Scalability"] A --> D["Operational Scalability"] A --> E["Cost Scalability"] B --> B1["Traffic and throughput"] C --> C1["Query patterns and volume"] D --> D1["Team and complexity"] E --> E1["Unit economics at scale"] ``` ## Architecture Scalability Assessment Questions for Investors ### Load and Throughput **"What is the current peak load, and how does the system behave at twice or five times that load?"** This should be answerable with data — load test results, staging environment benchmarks, or observed production behavior during traffic spikes. Founders who answer this question with "the architecture should be able to handle it" without data are describing aspiration, not capability. **"Where are the bottlenecks under load, and what is the plan to address them?"** Every system has a bottleneck — the limiting resource that reaches saturation first under increasing load. Founders who can identify it specifically (database connection pool, synchronous API call to a third-party service, single-threaded job processor) demonstrate that they understand their system. Founders who cannot identify it have not tested it under realistic conditions. **"Is there horizontal scaling in place, and if so, at which layers?"** Stateless application servers can generally scale horizontally by adding instances. Stateful components — databases, session stores, file systems — cannot scale the same way without architectural changes. Ask which components can scale horizontally today and which would require redesign. ### Data Architecture **"What happens to query performance as the data volume grows by an order of magnitude?"** A query that runs in 50ms against a table with one million rows may run in several seconds against a table with one hundred million rows if there are no appropriate indexes or if the query pattern is not compatible with the index design. This is a common and expensive surprise in products that are growing data volume faster than user count. **"Is there a data archiving or partitioning strategy for high-volume tables?"** Products with event logs, audit trails, or time-series data accumulate large tables quickly. Ask whether there is a strategy for managing table size — partitioning by time, archiving cold data, or moving to a purpose-built time-series store. **"What is the strategy for read-heavy versus write-heavy workloads?"** A product that is primarily read-heavy (a content platform, a dashboard) has different scaling requirements than one that is write-heavy (a transactional system, a data ingestion pipeline). Ask whether read replicas exist and whether the write path has any obvious serialization bottlenecks. ### Infrastructure and Cost **"What does the infrastructure cost at current scale, and how does that change at 10x scale?"** Unit economics of infrastructure are material. Some architectures have good unit economics — cost grows sub-linearly with scale because fixed costs amortize. Others have poor unit economics — cost grows linearly or worse because every user requires proportional compute. If the team has not modeled this, that itself is a finding. **"Is the infrastructure defined as code? Can the entire environment be reproduced from the repository?"** Infrastructure-as-code (Terraform, Pulumi, CloudFormation) is the baseline expectation for any system that will need to scale or be maintained by a team larger than one or two people. Manual infrastructure is a scalability blocker because it cannot be reliably replicated or modified under pressure. **"What is the vendor lock-in profile? Are there any components that would be difficult or costly to migrate away from?"** Significant use of proprietary managed services can be entirely reasonable, but it should be a known and deliberate choice. Deep lock-in to a specific vendor's proprietary features — particularly at the data layer — constrains future options and should be understood and priced. ### Failure Handling and Resilience **"What happens when the primary database is unavailable for five minutes?"** This question separates systems designed for resilience from systems designed to function normally. The expected answer includes specifics: read traffic fails over to a replica, writes queue and retry, users see a degraded mode, or some defined subset of functionality fails gracefully. "It has not happened yet" is not an architecture assessment. **"Are there single points of failure in the current architecture?"** Ask for the architecture diagram and walk through it looking for components with no redundancy: a single cache instance, a single queue worker process, a third-party integration with no fallback. Any component whose failure would take down the entire product is a risk that should be explicitly acknowledged. **"What is the recovery time objective for a complete infrastructure failure?"** How long would it take to restore service from a complete failure of the primary environment? This requires tested backup and restore procedures, not theoretical estimates. If it has never been tested, treat the answer as unknown. ## Synthesizing the Answers Architecture scalability assessment is not about expecting perfection. It is about determining whether the current architecture can support the business thesis without requiring a fundamental rebuild in the near term, and if a rebuild is required, understanding the scope and cost. A system with well-understood scalability constraints and a clear remediation roadmap is a manageable risk. A system whose team has never pressure-tested the architecture and cannot describe its failure modes is a significantly different risk profile — even if the product currently works well in production. Clixo conducts architecture scalability assessments as part of technical due diligence engagements for investors and acquirers. [Reach out](https://clixo.sh/#contact) to discuss what a focused scalability review looks like for a specific deal. --- Clixo · 1141 W Bryn Mawr Ave, Itasca, IL 60143, US · [hello@clixo.sh](mailto:hello@clixo.sh) [Start a build](https://clixo.sh/#contact) · [All services](https://clixo.sh/services) · [Agent guide (llms.txt)](https://clixo.sh/llms.txt)