Image generated by google nano banana (Not sure how cherubs made it into this one..)
Commercial due diligence is thorough. The technical due diligence is so often a checklist, partially reflecting the risks a lot of technical assessors wear when carrying out audits, and partially because for most profiles doing this work are either too hands-on and miss the commercial focus or too hands-off and miss a lot of critical poor design and flawed technical choices. AI assessments are a real gap. Most investors don’t find out about the real technical problems until they’re already on the board.
Early stage scaling
PoCs that went to production
Is common in a lot of businesses. Built fast, never refactored, not documented, owned by someone who may even have since left. The key issue here is that no one has understood or mapped the demands to scale. Non technical founders see a solution “that works” and are unable to guide the process and founding engineers often lack the knowledge even if they are excellent executors.
Signs: no test coverage, no deployment pipeline, infrastructure provisioned manually, issues with errors and customer churn risk or poorly formed requirements.
How to solve for this
General software products: As a general rule system design should be based on rough sales forecast and have a view of between 2 and 5 years in terms of scale. You should be able to generate a growth forecast otherwise what is your business valued on? These customer acquisition targets will guide the technical team to how many likely transactions, storage, ingress vs egress and level of automation and types of solutions to support it. This is an exercise done in the space of hours on paper and gradually qualified and adjusted over time. Software design patterns, common frameworks and technologies and architectural patterns should guide teams here. Find a similar product model that matches your product and business proposition and there will be a common architectural pattern to support it.
AI software products: Much of what is outlined above is also applied here. There are design patterns for AI models, and things like assessing AI model data preparation, extraction, data pipelines, processing, model training and management, quality assessments and benchmarking. There is plenty of documentation out there to guide best practise here. Its also fairly practical to identify existing research based approaches to solve a similar problem and formulate your use case around it.
Databases - can be a real pain point
Databases can get expensive if design and data schemas are not considered up front. Often a solution is put in place at an early stage, the requirements evolve but the design doesn’t. A dead give away for this is high costs for your database. If your monthly cloud bill is unreasonable and its all centered around read and write operations then you need to reconsider design. The most common error here is to not document queries, because if you don’t document queries you can’t design the schema and if you can’t design the schema you don’t know if you’re getting the right database for the job. Caching, indexing, read replicas, splitting reads from writes, even using more that one database to handle specific sets of complex queries, there are a lot of possible solutions for scaling here. The specific ones will need to reflect your scenario.
Unusual technology choices
Most businesses should be using common frameworks, technologies, and choices should be based on design patterns which fit the product, and the organisations ability to support and maintain that over time - size of community that uses said technologies is a good indicator for ongoing support. Ability to hire for those technologies and anticipation of how they will evolve is important. You don’t want to invest in a technology that may be obsolete in just a few years.
The CTO that selects based on their personal preferences and not the context of the business that they serve is not cut out for a leadership role.
Microservices and other over engineering
I have seen frequently that immature teams want to jump straight to enterprise solutions for business demands which are far into the future before the business requires it. This is most often a lack of technical roadmap and a target architectural model, as much as lack of knowledge within the role. These things are not fixed but need to be done on paper and built incrementally to support the businesses growth.
Microservices is a complex architectural pattern and is often mis-understood. Distributed systems generally need senior engineering expertise and should not be attempted by inexperienced engineers unless they are part of a larger team of senior expertise. Execution matters a lot in these scenarios as dependencies can create cascading failures.
Solving for mono-micro
Microservices bundled into a monolith, creates a lot of scaling problems and has the limitations of both, its a frequent pitfall. To solve for it you need to split out each service one by one and end to end testing and validating it, and depending on your scenario, migrate it to a new environment. This is painful as a process, but if you have a scenario like this technical debt will not be limited here.
Changing cloud provider
If you are very early stage with a simple monolith solution and web stack application with 3rd party APIs for your AI services. You can probably change cloud provider. But steps to do this need to be mapped, planned, costs assessed and migrated in structured stages. Beyond this, unless you are using some niche vendor with limited capabilities you should not consider to move provider. Most providers have similar solutions and its down to you and your team to understand enough about infrastructure to cost optimise, and ensure your product can be supported in all regions that you do business. The cloud providers themselves are very good at supporting early stage businesses to understand their services and there are many consultancies which specialise and can support.
Rebuilding the product from scratch
There is often an assumption from engineers even very experienced ones sometimes, especially in the accelerated world of agentic coding that you can just rebuild an existing solution from scratch. Beyond a very initial pre-seed stage regardless of AI tooling it is almost never a good idea. I work in B2B and enterprise scale and scope even at an early stage precludes this as a realistic option. The issue is always that the person who has this idea has no idea of scaling enterprise solutions, services and teams, and has only a limited concept of the requirements and process of validation with the customer. Some challenge to their set of assumptions usually kills this one pretty quickly.
What a SaaS actually is
Software as a Service is the automation of the entire end to end customer journey and lifecycle. You are not a SaaS without that. What should be automated:
Customer onboarding, invoicing and billing, account maintenance and support tiers. This logic needs to attach to each customer tenant. If this is not implemented at an early stage the cost to retrofit this is significant. Its a lot of logic which gets passed across the whole service.
Customer identity and access administration should not be a bespoke solution but should be handled by standard cloud provider products and services. Billing providers you would normally integrate a 3rd party service. Its a very expensive and unnecessary bespoke build.
Tenants - this is a misunderstood concept, and I have frequently seen even experienced senior leaders term multi-tenancy as single tenant designs. Its well documented out there what tenant type fits what scenario. Mapping your services to your tenants and understanding the amount of isolation required will give you a guide on possible dependencies.
End-to-end customer journey automation is the most commercially impactful technical issue and often does not appear in technical due diligence. Can a customer sign up, onboard, bill, and churn without touching your ops team?
How to solve for this?
Well end to end walk throughs of the system design and architecture, reviewing growth forecasts against existing design and assumptions and then working through this with product teams to understand the customer lifecycle, and then with operating teams to understand headcount and other resource dependencies. Mapping those gaps gives you a more realistic view on what you need for growth.
AI and SaaS
Even the big model providers are essentially software services with a large AI component. AI did not change the fundamental model of service and consumption is just the invoicing model. AI is a component of an overall software service. The operating mechanics of that should not be underestimated.
Deployment models
Deployment models can be a significant part of your code base. 30% in some cases. Business who have more than one deployment model often also have a product definition and requirements problem. If you are a product led company that means that one solution serves everyone. What is most likely to have been sold into the customer is a consulting service. The only way to solve for this is to have discussions with the commercial team to get every customer onto the same contract, terms and solution and make a plan to migrate them.
But automation is also often missing. CICD pipelines, ability to roll back changes and deploy frequent small features and bug fixes is important for reducing errors in production. A lot of manual configuration is often a bottleneck and inefficient. Again deployment models are well documented in terms of applying best practise design patterns. There are benchmarks for SaaS companies for measuring deployment frequency, these should be applied to help assess level of maturity here. Errors in production, slow delivery of new releases all indicate technical debt here. AI tooling has compounded speed here, with a lot of more frequent changes needing to be deployed in many cases.
Cloud providers have a lot of good documentation here for reference.
Environments that don’t match
This is a super common issue in all types of businesses. But poor network infrastructure and environment set up can lead to comparisons between testing, development and production environments which are unrealistic. Again there is a lot of best practise documentation out there, and consulting services which can support here. It is most often a lack of experience and endless managerial changes which drive poor outcomes here.
Code reviews, versioning and quality disciplines
If code quality is poor this is most often a problem of prototypes and immature or lacking technical leadership. Mostly seen at the pre-seed stage. Code slop from founders who have used agentic solutions or inexperienced developers who have given themselves the CTO title. Early stage teams who have drunk the agentic cool aid often let go a lot of quality checks as AI solutions write applications. Automation doesn’t take away human reviews or consideration of what good looks like.
Solutions here are obvious
Setting code quality standards which reflect best practise for the types of programming languages and technologies you are using, use and train the team on versioning an quality reviews. Pair programming with agents and each other. Its important to balance exploiting AI solutions with building existing team knowledge and competencies.
Map the SDLC and review at each stage what are the quality parameters which need to be either autonomously resolved or human reviewed and write jobs for the automation, and adapt tooling to ensure standards are met.
New standards are emerging. Loop engineering is the current hype, which should if used properly have durable state and bounded execution which is a hybrid of previous continuous delivery approaches. Google has good reference documentation and best practise guidance for this.
But the more fundamental question here is one of maturity. If the team have executed that poorly then those who have executed and led those that led them need to go, and be replaced by more experienced hires. Its too well documented what is best practise and how to apply it here, there are really no excuses for really poor code. The more common problem is the inexperienced hires leave and its up to someone more experienced to pay it down.
Later stage scaling problems
Infrastructure and application inventory sprawl from M&A
Each acquired business brings its own stack. The default is to run them in parallel longer than planned. This creates operational overhead that compounds: separate deployments, separate monitoring, separate on-call rotas, data that never consolidates. Integration debt keeps a lot of organisations inefficient.
The solution here is to map the technology estate, and identify operating efficiencies against organisational goals and then map the tasks to tactically and incrementally deliver on improvements here. There is a high level pass which can be executed in a matter of days in terms of investment of effort and a more detailed piece which may require internal teams and specialist consulting to assess details and implement. Often the biggest blocker here is politics and people change, and willingness to spend on enough consulting to map enough detail to understand implementation, or just support an iterative investment in ongoing improvements which is sustained over a significant enough time window to make a difference. Execs that believe there are a lot of quick wins here might be disappointed and have failed to understand the complexity they may be sitting on.
AI-generated code and technical debt
This is also a problem at early stages, but should not be under considered in more mature organisations. The Software Improvement Group’s 2026 benchmark report demonstrates AI-generated code carries roughly double the security risk violations of human-written code. It scores lower on maintainability. Critically, the report’s core conclusion is that AI amplifies whatever engineering discipline already exists — it makes disciplined teams faster and undisciplined teams more fragile. SIG explicitly names startups and scale-ups as the cohort with the most room to improve on maintainability. Forrester adds that by 2026, 75% of technology decision-makers expect to face moderate to severe technical debt, much of it tied to speed-first AI-assisted development.
Much of this is simply that teams operating AI solutions need to mature with them, they have not mapped quality parameters at each stage of the SDLC and as a result simply compound issues. This is also an indicator for poor operational engineering leadership.
Security and governance at scale
There is generally a lack of goverance and security and compliance viewed as box ticking issues. Agentic solutions need services to track and monitor their activity. There are solutions which are emerging on the market but this is not mature yet. The biggest gap here is that box ticking doesn’t ensure compliance and that specialist audits from security professionals really need to be undertake to ensure you’re covering all your bases. I can quite sympathise with a lot of IT services professionals directly responsible for ensuring a business with these demands is secure when you have no tooling and mechanisms for visibility here. Frameworks will emerge.
IT services should be separate from customer production environments, this is to limit blast radius of security breaches and ensure separation of concerns and impartiality for customers, vendors and staff. These are often bundled together early stages. Most product led business should consider to outsource IT services and transfer risk to a provider who has operating efficiencies as they serve a number of businesses with this service.
Coding security standards
One important issue here is to make sure product coding standards consider security as much as compliance and security audits do. OWASP has great guidance and best practise here to solve this. Teams should apply these standards within code writing and reviews. This applies to early stage teams as much as later stage ones.
Infrastructure, legacy systems and lack of strategy
The biggest pain perhaps in larger organisations is lack of strategic clarity and often firms compromise on operating improvements to make the reporting figures look good. If you customer journey isn’t automated that means the product wasn’t properly specked and is under invested. Legacy infrastructure is costly and effort intensive to change. Most businesses understand what needs to be paid down here, surfacing that and estimating the effort to change should be done and prioritised against business goals. This most often turns up that there is a lack of defined business strategy and leadership has simply set growth targets and KPIs. Consultants can help facilitate and join tactical initiatives to better defined strategic goals and help support existing internal staff with hard priorities.
Lack of documentation and system for internal knowledge
Onboarding and off-boarding engineers is often affected by lack of documentation and knowledge transfer. This is a broader operating problem its only a technical issue as corners of poor solution choices and execution are also left undocumented. Documenting this and using LLMs to accelerate what the legacy code actually does as an initial assessment can really help help give clarity to understanding possible resolutions here.
Missing business intelligence and how investors assess technical performance
EY identifies three gaps investors consistently miss: (1) R&D spend not segmented into growth vs debt remediation — meaning investors can’t tell whether a roadmap is realistic; (2) past delivery credibility not assessed against future commitments — management teams make lofty claims about timelines;
(1) This is most often a lack of operating and business intelligence reporting across the business. Consuming that data is easy but mapping and surfacing it is often a challenge. Siloed data stores or buried in 3rd party applications which were never design to extract that set of data from. If RevOps is missing it needs to be implemented and evolved over time. You can’t bullshit that AI is making your teams more productive if you don’t measure anything in the first place.
(2) The roadmap should reflect anticipated product and service development and allocations for areas of investment. Delivery cadence should be well established and customer error rates low. Delivery staff should have forecasts and a repeatable project management and delivery framework, and demonstrate that forecasts are delivered on.
Headcount should scale within benchmarks which are considered reasonable for the industry and sector you are in. AI should enhance and and optimise delivery cadence. Those are good indicators for ability to scale.
Technical solutions and commercial impact
All technical issues need to be framed as a commercial impact, risk and value. Most investors will be looking for quality benchmarks, low error rates which should correspond with customer satisfaction and productivity. I have rarely seen operating outcomes from technical teams measured by customer business value despite that its a good indicator for exec reporting and new business confidence. You can build a lot of trust for new business if you have existing satisfied customers willing to give you a good reference and you can back up your claims with data.
Most poor execution is also simply poor hiring. The issues I have outlined are mostly issues born from lack of experience in the space and lack of knowledge of how to resolve them. From that perspective most technical and operational problems are actually not that hard conceptually to solve. Roles under pressure in these environments can be very demanding.
I have written previously on the most common issues I see with PE and VC backed scale-ups. This article has been focused on technical solutions and its not an exhaustive list. In my next article in this series I will consider solutions to scaling business problems.
This is Part 2 of a 4 Part series.