The architecture decisions that destroy company value are rarely the obviously bad ones. No engineer intentionally builds a system that cannot scale. The dangerous decisions are the ones that are reasonable given the context at the time and only reveal their consequences years later.
These are the architectural choices we most frequently find creating invisible business risk in independent assessments.
1. Synchronous Service Dependencies in Critical Paths
When Service A makes a synchronous HTTP call to Service B during the processing of a user request, the reliability of Service A is now bounded by the reliability of Service B. If Service B has 99.5% uptime, Service A can no longer achieve better than 99.5% uptime — regardless of how well it is engineered.
This compounds with every additional synchronous dependency. Three services in a chain, each with 99.5% uptime, produce a composite availability of 98.5%. At scale, this becomes a compounding reliability tax that is very expensive to undo.
Every synchronous external dependency in a critical user-facing path reduces your maximum achievable reliability. Map these dependencies before they compound.
2. Shared Database Schemas Between Product Domains
When multiple product domains — billing, user management, product catalog — share a single database schema with cross-domain joins, you have created a coupling that will eventually prevent independent deployment, independent scaling, and independent development.
This pattern is not wrong for early-stage products. It becomes structurally dangerous when the team wants to move fast across domains, or when an acquirer assumes they can operate domains independently post-close.
3. Implicit Operational Knowledge
When deployment procedures, incident response runbooks, and infrastructure topology exist exclusively in the heads of two or three engineers, the organization has created an operational risk that cannot be quantified until those engineers leave.
This is the architectural decision that most frequently destroys post-acquisition value. The platform looks technically sound until the key engineers resign post-close, and the new owner discovers that nobody else knows how to deploy it.
4. Untested Disaster Recovery
A disaster recovery plan that has never been executed in a controlled test is not a disaster recovery plan. It is a document. The assumption that documented recovery procedures will work under actual failure conditions is almost always wrong in systems that have not been regularly tested.
The common thread across all of these risks is that they are not visible until a specific business threshold is crossed — a traffic spike, an acquisition, a security audit, or an engineer's resignation. By then, the cost of addressing them has compounded significantly.
Facing this decision? Anubis can independently assess the system, establish the technical facts, and give you a decision-ready recommendation.