A founder asked me to do a technical assessment before her Series A pitch. She had two weeks until the first investor meeting. Her lead engineer had been with the company for 14 months and was, in the founder's words, "pretty confident the system is solid."
I spent 48 hours on it. Here is what I found: the system was functionally solid. The main application worked. But there were three things I knew an investor's technical advisor would flag: no disaster recovery plan, database queries that were going to cause performance problems at 5x current load, and a deployment process that required manual intervention and had no rollback capability.
None of these were catastrophic. All three were meaningful. All three had specific remediation paths. The investor meeting was two weeks away, and we fixed two of the three before it happened.
This is the structure I use for every startup architecture review and technical architecture audit. Same framework, adapted to the context. It takes 48 hours for a reasonably scoped codebase and team. Larger companies take longer, but the questions do not change.
Hour 0-4: Context Before Code
I do not start with the code. I start with conversations.
The first conversation is with the technical leader - CTO, lead engineer, whoever owns the technical decisions. I ask them to walk me through the system as if I have never seen it. The goal is not to learn the architecture - I will look at that separately. The goal is to understand how they think about it. Where do they have confidence? Where do they hesitate? What keeps them up at night technically?
The things they do not mention are often as informative as what they do. An engineer who is confident in the application logic but never mentions infrastructure is telling me something. An engineer who mentions every system without pausing on any of them is also telling me something.
The second conversation is with the founder. What are the business pressures on the technical decisions? Is there a major customer onboarding coming up that depends on the system handling a specific load? Is there a compliance requirement that needs to be met by a specific date? Is there a feature that has been promised in the next release that the engineer has not mentioned?
The third conversation, when possible, is with a non-technical person on the team - a customer success person, a salesperson, a product manager. What do they hear from customers about the product? What problems do they work around? What do they promise that makes the engineering team wince?
By hour four, I have the business context. Now I look at the system.
Hour 4-16: The Technical Inventory
The technical assessment has four components that I review in parallel, not sequentially.
The codebase. I want to see the repository structure, the test coverage, and the code in the highest-risk areas. I am not doing a full code review - I am looking for patterns. Tests: are there any, and do they cover the important things? Complexity: is there code that is clearly unmaintainable, or that only one person can touch? Security: are there obvious issues like secrets in version control, SQL injection vulnerabilities in user input handling, or missing authentication checks on sensitive endpoints?
The infrastructure. How is the application deployed? Where does it run? What happens if the primary database fails? What does a deployment look like - is it automated or manual, does it have rollback capability, does it require downtime? Who can perform a deployment, and what do they need to know to do it? I look at the cloud console, the deployment scripts, and the monitoring setup.
The data. What does the data model look like? What is the size of the primary tables? Are there indexes on the columns used in frequent queries? Is there a backup process, and has it ever been tested by actually restoring from backup? How long would a full restore take?
The team and process. How does work flow from idea to production? Is there code review? Is there a testing process? How long does a deployment typically take? What happens when something breaks at 2 AM? These questions reveal whether the system is managed by a professional engineering process or whether it is held together by individual heroics.
Hour 16-32: Risk Calibration
After the inventory, I have a list of findings. The findings are never all equal, and a 48-hour assessment that returns a list of 40 items without prioritization is not useful.
I calibrate risk on two dimensions: likelihood and impact.
Likelihood: how probable is it that this issue causes a problem in the next six to twelve months? A query that is slow today will be slower at 2x load. An unaudited dependency might have a known vulnerability. A single-point-of-failure will eventually fail.
Impact: when this issue manifests, what happens? A slow query that affects the reporting dashboard is a bad user experience. A single-point-of-failure in the payment processing flow is an outage that affects revenue. A security vulnerability in the authentication layer is a breach.
The product of likelihood and impact gives me the risk level. Critical (high likelihood, high impact): must be addressed immediately, before any significant business event. High (high likelihood, moderate impact, or moderate likelihood, high impact): address within 30-60 days. Medium: address within a quarter. Low: document and track.
The output of risk calibration is a prioritized list of seven to fifteen findings, grouped by priority level, each with a description of the problem, why it matters, and what the remediation looks like at a high level.
Hour 32-48: The Deliverable
The deliverable from a technical architecture assessment is a written document, not a presentation. The document needs to be readable by the founder, the technical team, and an investor's technical advisor - three audiences with different levels of technical context.
The structure I use:
Executive Summary: two to three paragraphs. The overall assessment in plain language. What is strong? What are the top three concerns? What is the recommended priority for the next 30-60 days?
System Overview: a description of the architecture as I understand it. I write this myself, not just repeat what the engineering team told me, because the act of writing it reveals where my understanding is unclear - which means either the system is poorly documented or I need to ask more questions.
Findings: organized by priority level. Each finding has: the issue, why it matters, the remediation path, and a rough effort estimate. Not a detailed spec - a direction.
Strengths: what the team has done well. This is not padding - it is important information. It tells the founder where they have solid footing and do not need to invest, and it tells the engineering team that the assessment is honest and not just critical.
Recommendations: the specific actions I recommend, in priority order, with ownership suggestions and a 30/60/90-day implementation path.
The total length is usually 15-25 pages. Long enough to be credible, short enough to actually be read.
What I Am Actually Looking For
The surface finding in most assessments is the list of specific issues. The underlying finding is whether the engineering team is operating professionally.
A system with some technical debt but a professional team - one that reviews code, deploys carefully, monitors production, and responds to incidents quickly - is in a much better position than a technically clean system managed by a team that ships directly to production without review and has no idea what is happening in production at any given moment.
The engineering process is what determines the trajectory of the system. A professional team will address technical debt. An unprofessional team will create new problems as fast as they fix old ones.
After 200+ projects, I can usually tell within the first four hours of conversation which kind of team I am working with. The technical findings confirm it, but the answer is almost always in the culture before it is in the code.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr