Technology

Engineered, not assembled.

PPE1 is one coherent system on a modern, mainstream stack — .NET and C# on the back end, React and TypeScript on the front, SQL Server underneath — built to disciplined standards that a technical team can read, run, and extend. No exotic dependencies, no black boxes; the kind of codebase that survives a forensic review.

.NET / C# React / TypeScript API-first SQL Server Stored-procedure data layer Temporal history As-of pricing

One stack, top to bottom

Six Products. One Platform — sharing a single database and identity.

Presentation
React 18 + TypeScript (strict mode) for web & mobile, over a shared UI-agnostic core in an npm-workspaces monorepo — business logic written once. Material UI and RTK Query, built with Vite; the Manager hub is server-rendered Razor / jQuery by deliberate choice.
Identity
A dedicated, stateless authentication service issues one signed JWT — the same issuer, audience, and key validated by every product and the API. Stateless two-factor (no server-side session store), per-session refresh-token rotation, and anti-enumeration throughout.
Application / API
ASP.NET Core (C# / .NET 10) web APIs and MVC in a uniform Controller → Provider → Repository layering — interface-segregated dependency injection throughout, nullable reference types enabled, and source-generated object mapping (Mapperly — no runtime reflection).
Engines
A six-stage Program Engine (chain-of-responsibility) decides eligibility; a Pricing Engine then computes and ranks best execution — the same core behind the web UI, the mobile app, and the Bulk Pricer, with every run replayable field-by-field for audit.
Data
SQL Server behind a stored-procedure data layer (Dapper) — 490+ procedures, minimal inline SQL by policy — with 92 foreign keys enforcing integrity (every one trusted and enabled), 51 system-versioned temporal tables carrying full row history, and soft-deletes throughout.

The standards a technical buyer checks

Discipline that's enforced — in the build, the database, and the code.

Stored procedures, by policy
Effectively all data access runs through ~490 parameterized stored procedures — injection-safe, plan-cached, DBA-tunable. The rare inline statement is a deliberate, reviewed exception, never the default.
Temporal history
51 system-versioned tables retain full row history automatically — every change preserved and queryable, not bolted on. It reaches the whole pricing chain, which is what makes as-of pricing possible (below).
Soft deletes, always
Nothing is hard-deleted; deactivation is recoverable, so the data layer never destroys its own history.
Null-safety at compile time
Nullable reference types are enabled, turning a whole class of runtime errors into compiler errors.
Compile-time mapping
Object mapping is source-generated (Mapperly) — no reflection, no runtime mapper — for speed and transparency.
Modern, current tooling
A Vite-built front end and consolidated, patched dependencies — a codebase kept current, not frozen in time.
Referential integrity, enforced
Foreign keys throughout the schema make the database itself reject orphaned or inconsistent data — integrity is guaranteed at the data layer, never left to application code to remember.
Test-gated by CI
Every solution ships an automated test suite wired to continuous integration — 3,400+ tests gate each change, with golden-master coverage guarding the calculation core against regression.

Priced as of any moment

Most pricing engines can only answer what is this worth today. Because the pricing chain itself is versioned, PPE1 can answer what was this worth then
— which is the question every locked loan eventually asks.

The whole chain, versioned
Not just the loan. Guidelines, LLPAs, SRP, rate sheets, investors, programs and reference data — 51 system-versioned tables — so the inputs a price was built from are still there months later, exactly as they were.
As-of, at every entry point
Every Program- and Pricing-engine entry point accepts an as-of date, and the clause propagates through the data layer — so one date governs an entire run rather than being stitched together query by query.
A lock keeps its evidence
At lock, the quote stops being a quote and becomes a commitment, captured as a pricing snapshot. Every later repricing is an update to a versioned table, so each one leaves the prior version behind automatically.
A change, priced with its cause
When underwriting changes a committed loan, the platform compares it field by field against the locked snapshot and re-prices as of the lock — so the desk sees what moved, and what that movement cost, not just a different number.
Worse-case market, measured
A lapsed lock re-prices at the worse of the committed price and the current market, per investor policy. And when the market genuinely cannot be established, the platform says so — “cannot be determined” is reported as an answer, never quietly rendered as “unchanged”.
Lock policy as data
Extension and relock cost ladders are authored per program as data — tiered by the period being extended or relocked into — so a lock desk's policy is configuration a manager maintains, not logic a developer ships.
⏱
Why this is hard to add later

Point-in-time pricing is not a report you bolt on — it is a property of the schema. If the rule that priced a loan in March was edited in place, no amount of application code can recover it. Versioning the pricing chain is the feature; everything above is what that makes possible.

API-first — built to integrate

The pricing logic lives in a pure, UI-agnostic API. Nothing is welded to a screen
— which is exactly what lets PPE1 sit inside your stack, not just beside it.

One engine, many faces
The web app, the mobile app, and the Bulk Pricer all call the same pricing API. The brain is written once; every surface is a thin client over it.
Built to be embedded
Because pricing is API-first, it's designed to run behind your own LOS or POS — originators price without ever leaving your system, authenticated by the shared identity token.
One identity, everywhere
A dedicated service issues a signed JWT trusted by every product and the API — single sign-on across web, mobile, and anything built on top.
Integration-ready groundwork
A documented API surface, a session handshake for external entry, and a stored-procedure data layer — the foundations for LOS connectivity are designed in, not retrofitted later.
⚙
The right tool for each surface

The customer-facing pricing experiences are React + TypeScript single-page apps; the Manager admin hub is deliberately server-rendered Razor + jQuery — the proven, pragmatic choice for a dense, form-heavy internal tool. One framework is never forced where another fits better, and every surface still shares the same API and identity underneath.

Don't take our word for it.

Read the full Forensic Code Review — an unflinching, file-level assessment of the architecture, code quality, and ownability of the entire platform.

Read the CIO / Executive Summary Read the Forensic Code Review About the Review