Architectural assessment
The company is preparing to enter a new market vertical that requires a different data model and a different regulatory regime. Leadership is debating whether to extend the existing platform or build a parallel one. This assessment was commissioned to answer that question with evidence rather than opinion.
The system, the question, and the boundary of this report.
The subject is a B2B enterprise SaaS company with one primary product, ~120 engineers, and a Java/Spring codebase that has been in continuous development for eleven years. The company is preparing to launch into a new vertical that requires a substantially different data model and regulatory regime.
We were asked to characterize the current architecture honestly — including its strengths — surface the constraints that would shape either option, and recommend a path with the reasoning made explicit. We did not produce detailed implementation designs. That work follows the decision; it does not precede it.
How we gathered evidence.
- Read the architecture documentation that exists, and noted where it does not.
- Sat with three architects across two days for a guided code tour.
- Reviewed bounded contexts and identified actual versus stated ownership.
- Audited the data layer: schemas, foreign-key relationships, shared tables, multi-tenancy implementation.
- Interviewed fourteen engineers and architects, the VP of Engineering, two product VPs, and the head of customer success.
- Read the past year of architecture review notes.
- Modeled three forward scenarios on paper with stakeholders.
What we observed.
A. The data layer is the most coupled part of the system, by a wide margin.
80% of services share a single PostgreSQL database. The accounts table has forty-seven foreign-key references from twenty-three other tables. Multi-tenancy is implemented via a tenant_id column on most tables — but inconsistently; there are thirty-one tables without one. Migration of any heavily-referenced table requires coordinated downtime, which is why it does not happen.
B. Service boundaries reflect 2018, not 2026.
Service boundaries were drawn during an early decomposition effort that prioritized team autonomy over domain coherence. Several services own data that no longer belongs to them; ownership has drifted. Two services have become "god services" handling 60% of inbound traffic each, for different reasons in each case.
C. The code that touches the new vertical's regulatory domain has not been isolated.
Compliance-relevant logic — audit logs, data retention, region pinning — is spread across the codebase. There is no compliance perimeter. The new vertical will demand one, and retrofitting it across the current architecture is expensive in both time and risk.
D. The team has the skills, but not the slack, to do this well.
The senior architects can describe the system clearly and have strong, defensible opinions about where it should go. They are absorbed in delivery work and have not had protected time to lead a major architectural transition. Architectural work has been happening in margins, with predictable results.
The real question and three honest options.
The architecture is workable for the current product. It is not workable for the new vertical without substantial change. The question is not "extend or rebuild" — that is a false dichotomy. The real question is: where should the boundary between the two markets live?
There are three viable options, in order of risk:
Option A — Build the new vertical inside the existing platform.
Lowest cost initially, highest cost over time. Compliance becomes a cross-cutting concern that no one owns well. Risks contaminating the current product with regulatory complexity.
Option B — Build a separate platform from scratch.
Highest cost initially, fastest velocity once running. Defers but does not solve the integration problem — many customers will live in both verticals. Has the highest organizational risk: two platforms, two teams, two cultures.
Option C — Extract a shared core and build the new vertical alongside it.
Medium cost, highest long-term option value. Requires honest investment in the seams between the two products. Demands a team dedicated to the shared core — we estimate eight to ten engineers for the first year.
We recommend Option C.
What we would commit to, in priority order.
1. Commit to Option C and name the leader.
The shared-core platform team needs a tech lead protected from delivery work for at least four quarters. This is the single most important decision in the report.
2. Begin the data perimeter work immediately.
Before any new vertical work begins, audit and consolidate compliance-relevant data flows. This is six to eight weeks of platform work that will compound for years.
3. Establish a quarterly architecture review with teeth.
The current review meeting produces no decisions and assigns no owners. Restructure it as a small group with the authority to approve, defer, or reject architectural changes. Document the outcomes.
4. Resist re-platforming the existing product.
The temptation will be to "rebuild what we should have built." Resist it. The existing product earns the revenue that funds everything. Extract, isolate, and bridge — do not rewrite.
5. Hire one principal engineer with platform-extraction experience.
The current team is strong but lacks one specific role: a principal engineer who has done this kind of work before. This person is the most valuable hire the subject can make this year.
A sequenced plan.
Weeks 1–2.
Leadership commits to Option C and assigns the shared-core tech lead. Communicate the decision and its rationale clearly to the organization.
Weeks 3–4.
Begin the data perimeter audit. Identify the worst-coupled tables and the compliance-relevant flows. Produce a written extraction roadmap.
Weeks 5–8.
Stand up the shared-core team formally. Pull two senior engineers from delivery. Begin the first extraction; we suggest the audit logging subsystem — high value, contained scope, good practice for the team.
Weeks 9–12.
First architecture review with the new structure. Begin recruitment for the principal engineer. Reassess the new-vertical timeline with realistic platform constraints.
We typically remain available to the shared-core team as a sounding board through the first extraction. This is structured as a small monthly engagement, not an embedded role.