CTO Advisor

A 40% maintenance tax is already a crisis. Most teams don't measure it this clearly — the fact that you have this number is actually good. Here's how to think through it.

First, resist the big-bang rewrite impulse. "Migrate to microservices" is often the wrong answer at your stage — it's 12–18 months of engineering investment, high execution risk, and delivers nothing visible to customers. The Strangler Fig pattern (incrementally extracting services from the monolith) is almost always the right path for a 2019 monolith at your scale.

Diagnose before you prescribe. What's causing the 40% tax?

• Fragile integration points: If the monolith has circular dependencies and no test coverage on core paths, extraction is urgent
• Database bottlenecks: If it's primarily query performance or schema coupling, targeted optimizations may buy 12–18 months
• Deployment coupling: If all 3 features require touching the same modules, the pain is architectural, not just debt

A framework that works at your scale:

1. Quarantine the debt — identify the 3–5 modules causing 80% of the maintenance burden. Freeze them: no new features in those modules.
2. Extract one bounded context in the next sprint cycle — pick the module that (a) blocks the most-demanded enterprise feature and (b) has the cleanest API boundary. Ship the feature and the extraction together.
3. Negotiate a 70/30 sprint allocation with product: 70% new features, 30% architectural cleanup. This is the only sustainable path that doesn't leave either engineering or product fully blocked.

What to tell your board: Frame this as technical foundation investment with a specific 6-month velocity recovery target. "We will reduce maintenance tax from 40% to 20% by Q3" is a trackable commitment.

This is a build/buy/partner decision with a compliance overlay. Let me structure it.

The three distinct concerns you raised are actually separate decisions:

1. Data privacy for fintech/healthcare customers: This is non-negotiable to resolve first. OpenAI's API (not ChatGPT) does not train on API data by default, but you need to review your customers' contracts. Healthcare customers with PHI will require a Business Associate Agreement (BAA) — OpenAI offers BAAs on Enterprise tier. Fintech customers may have contractual restrictions on third-party data processors. Audit your top 20 customers' data processing agreements before committing to architecture.

2. Cost modeling: At 1,100 customers, cost depends entirely on how the feature is used. Run this estimate: (avg tokens per AI call) × (calls per user per day) × (MAU) × ($/1M tokens). GPT-4o at $5/1M input tokens can run $15–40/customer/month for moderate usage — meaningful at your ARR. Build a tiered approach: lightweight models (GPT-4o-mini at $0.15/1M) for classification/extraction tasks, full GPT-4o only for generation tasks.

3. Latency: For synchronous UX features (user waits for response), target <2s. Streaming responses solve perceived latency better than raw speed. For async features (background processing), latency is irrelevant.

Architecture recommendation:

• Start with an AI abstraction layer in your codebase — a single interface that calls the model provider. This lets you swap providers (OpenAI → Anthropic → self-hosted) without rebuilding features.
• For your regulated customers, evaluate Azure OpenAI (same models, data stays in your Azure tenant, easier compliance story).
• Pilot with 50 opt-in customers before general release. Instrument cost per customer from day one.