Skip to main content

1. Introduction and Goals

1.1 Requirements Overview

PSSaaS (PowerSeller SaaS App) is a modern, multi-tenant SaaS platform that replicates the mortgage secondary marketing business logic of the PowerSeller Desktop App — a ~30-year-old PowerBuilder application with ~2,100 source files across 25+ PBL libraries.

The desktop app serves lender secondary marketing desks with pipeline management, best-execution pricing analysis, trade lifecycle management, pooling, risk analysis, and reporting. PSSaaS delivers this same value through a native web application built on a modern technology stack.

Core Capabilities Being Ported

CapabilityDesktop App ModuleSaaS Bounded Context
Pipeline managementPipeline windows + NVOsPipeline
Best-execution pricingBestEx NVOs + DataWindowsPricing
Trade lifecycleTrading windows + NVOsTrading
Pooling enginePooling NVOsPooling
Risk/hedging analysisRisk windows + NVOsRisk
Document trackingDocTracking windowsDocTracking
Bid packagingBidPackaging windowsBidPackaging
Import/exportImportExport NVOsImportExport
ReportingDataWindows + reportsReporting

1.2 Business Goals

PriorityGoalDescription
1Expand to new customersOffer a modern SaaS experience that attracts lenders who would never adopt a desktop app. Modern UX, cloud deployment, no installation.
2Maintain existing customer baseProvide a migration path for current desktop customers to a supported, modern platform — at their own pace.
3Build an ecosystem platformPSSaaS is one product in the PowerSeller ecosystem (alongside PowerSeller X and MBS Access). API-first design enables cross-product integration.

1.3 Quality Goals

PriorityQuality GoalScenario
1CorrectnessFinancial calculations (BestEx pricing, pooling constraints, risk positions) must produce identical results to the desktop app when given the same inputs. Validated via side-by-side comparison against production data.
2UsabilityNew users complete core workflows (lock a loan, run BestEx, create a trade) within 30 minutes of onboarding. Power users (migrating from desktop) can opt into a dense, keyboard-driven mode that matches their existing efficiency.
3MaintainabilityEvery feature has a specification before code is written. All architectural decisions are documented as ADRs. New developers (starting with Rudy) can onboard from documentation alone.

1.4 Stakeholders

NameRoleExpectationsContact
LisaCEO, PowerSeller SolutionsStrategic direction, customer relationships, product roadmap validation. 40 years in secondary/capital markets. Also CEO of MWFI Holdings (design partner).Executive sponsor
SawyerCTO, Product OwnerArchitect of ecosystem modernization. Builds with Cursor + AI agents. Owns architecture, specifications, and implementation direction.Product Owner
GregContract President (domain expert)Deep hedging and risk management knowledge. The "oracle" for business logic that nobody else fully understands. Time-limited resource — knowledge must be captured before contract ends.Domain expert
TomSenior DeveloperPowerBuilder veteran (decades). Maintains desktop app. NOT migrating to SaaS dev. Source of legacy knowledge for how things actually work in PB. ~5 years to retirement.Legacy knowledge
RudyJunior DeveloperLeading TFS → Azure DevOps Git migration. Future SaaS dev lead. Will be exposed to docs and progress organically. 10-15 year horizon.Future SaaS developer
JoeIT / InfrastructureManages infrastructure, security, customer support, customer migrations. Azure/Docker ops, CI/CD.Infrastructure & ops
JayOperations ManagerCustomer advocate, power user of desktop app. Former secondary marketing professional. Acceptance testing, UX validation, domain knowledge for "how users actually work."UX validation & acceptance