11. Risks and Technical Debt
11.1 Risks
High Priority
| ID | Risk | Impact | Probability | Mitigation |
|---|---|---|---|---|
| RISK-1 | Greg's knowledge not fully captured before contract ends. Greg is the only person who deeply understands the hedging, risk management, and certain pricing business rules. Some of this knowledge exists as institutional memory, not code. | Critical — Risk module may be incomplete or incorrect without his validation. | High | Prioritize structured knowledge extraction sessions. Use documentation as an interview guide. Record sessions. Capture business rules in specs, not just code. |
| RISK-2 | Loan table customization complexity unknown. It's unclear whether customers customize the loan table schema (add columns, change types). If they do, the SaaS data model strategy changes significantly. | High — Could require JSON extension columns, configurable schema, or tenant-specific migrations. | Medium | Ask Jay about current customer customizations. Review existing customer databases for schema differences. |
| RISK-3 | PowerServer transaction semantics unknown. Does PowerServer's web API preserve the same SQL transaction semantics the desktop app uses (manual commit/rollback via n_cst_transobj)? If not, Hop 2 migration may have data integrity risks. | Medium — Affects coexistence strategy and migration path. | Medium | Evaluate Appeon documentation. Run controlled tests against a non-production database. |
Medium Priority
| ID | Risk | Impact | Probability | Mitigation |
|---|---|---|---|---|
| RISK-4 | Identity strategy undecided. Three options (Keycloak, Azure AD, Odoo) with different trade-offs. Delayed decision blocks authentication implementation. | Medium — Delays security implementation and tenant provisioning flow. | High (decision delay is certain until research is done) | Conduct architecture spike. Document trade-offs. Make decision in ADR-013. |
| RISK-5 | Single CTO as primary developer. AI-assisted development amplifies individual output, but key-person risk exists. If CTO is unavailable, development stops. | High — Development velocity drops to zero. | Low (but non-zero) | Documentation-first approach means another developer (Rudy) can onboard from docs. Specs define what to build, not just how. |
| RISK-6 | Desktop app backward compatibility. Schema changes must be backward-compatible with the desktop app during coexistence. This constrains schema modernization speed. | Medium — Slower modernization. More complex migration logic. | High | Add new columns rather than renaming/removing. Use views to present legacy-compatible interfaces. Test schema changes against desktop app before deploying. |
Low Priority
| ID | Risk | Impact | Probability | Mitigation |
|---|---|---|---|---|
| RISK-7 | Agency format changes. Fannie Mae, Freddie Mac, and Ginnie Mae may change their delivery formats or requirements. | Low — Affects pooling output format, not core logic. | Low | Abstract agency formatting behind interfaces. Monitor agency bulletins. |
| RISK-8 | Rate sheet format variability. Different investors may provide rate sheets in different formats. | Medium — Affects price ingestion pipeline. | Medium | Build a flexible rate sheet parser with per-investor configuration. |
11.2 Technical Debt
Current State: None (Greenfield)
PSSaaS is a greenfield project — no code has been written yet. There is no accumulated technical debt.
Inherited Debt (from Legacy Schema)
The legacy database schema (~170 tables with pscat_/rmcat_/pxcat_ prefixes) carries structural debt from 30 years of PowerBuilder development:
| Debt Item | Description | Resolution Plan |
|---|---|---|
| Table naming | Prefix-based naming (pscat_, rmcat_, pxcat_) is not self-documenting. | Preserve initially for validation. Rename in a later phase after coexistence period. |
| Missing foreign keys | Many relationships are enforced in application code, not the database. | Add foreign keys incrementally during schema mapping. |
| Missing audit columns | No standard CreatedAt/UpdatedAt/CreatedBy/UpdatedBy. | Add to all tables via migration. |
| No soft deletes | Hard deletes with no recovery. | Add IsDeleted/DeletedAt columns where needed. |
| Denormalized structures | Some data is duplicated across tables for PowerBuilder DataWindow performance. | Evaluate each case — some denormalization may still be appropriate for read performance. |
| Implicit business rules | Some business rules are encoded in PowerBuilder DataWindow validation expressions, not the database. | Extract all rules into feature specifications during port. |
Debt Prevention Strategy
- Specs before code: Every feature specification documents business rules, data model changes, and acceptance criteria before implementation.
- ADRs for decisions: Architectural decisions are documented with context and consequences, preventing "why did we do this?" debt.
- Code review: All code reviewed before merge (initially by AI, later by human developers).
- Linting and formatting: Enforced via CI/CD. No style debt.