How to build financial software for complex asset finance.

The first mistake in financial-software projects is often designing screens before defining the decision the software is supposed to improve. In asset finance, a user rarely needs a prettier form for its own sake. They need to know whether a case looks plausible, what makes it stronger or weaker, what structure may fit and what should happen next.

Waaza therefore models the case itself. The current data layer includes clients, vessels and assessments rather than treating every calculation as an anonymous one-off submission. A client record can carry residency, available liquidity, net-worth band, income type and ownership intent. A vessel record can carry purchase price, build year, usage type and intended flag. That creates a usable product foundation before any score is calculated.

A repayment calculator answers a mathematical question: given a purchase price, deposit, term and rate assumption, what does the repayment picture look like? That is useful, but it is not the same as answering whether a transaction is financeable or how a broker should frame it.

Waaza keeps those ideas distinct. Its public yacht finance calculator helps users explore price, deposit, term and indicative-rate scenarios, while the wider platform introduces readiness scoring, risk factors and recommended paths. This separation prevents a clean monthly-payment number from being mistaken for a lending decision.

When qualification depends on repeatable conditions, burying all of that logic inside UI components becomes difficult to maintain and almost impossible to audit. Waaza's schema separates rule sets and individual rules from the assessment record itself.

Each assessment can record a rule-set version, and each assessment run stores both the rule-set version and engine version that produced the result. The run also preserves an input snapshot, rule hits and an output snapshot. That architecture matters because a result from six months ago should still be understandable even after the underlying logic evolves.

Financial decision software should not end with a hidden boolean such as pass or fail. The output has to help a broker, buyer or adviser understand the case.

Waaza's assessment model can store a readiness score, financing tier, indicative loan-to-value range, risk flags and a recommended path. Those fields are deliberately closer to the language of the workflow. They allow the product to surface both a high-level view and the specific issues underneath it.

This is also why the readiness scoring layer is separate from a calculator. One explains a financing position; the other models arithmetic.

Complex financial cases often leave the application. A buyer may need to speak to a bank, accountant, lawyer, broker or finance adviser. That makes document output part of the product experience.

Waaza's report workflow is structured around six recurring sections: executive summary, readiness score, indicative financing structure, LTV and cost projection, risk considerations and next steps. The codebase also includes PDF tooling, so structured application data can be turned into a shareable document rather than manually copied into a separate template.

The important product principle is consistency: the report should be another view of the same case data, not a second version of the truth.

Good broker software should reduce the amount of interpretation required between steps. A strong flow usually moves from basic case facts, to structured assessment, to an intelligible result, to a clear next action. The interface should make that progression obvious without pretending the underlying finance decision is simpler than it is.

In Waaza, the public calculator is an early-intent entry point, the readiness intake adds context, and platform pages such as scenario modelling, broker dashboard and case tracking describe the deeper workflow. That product architecture is more useful than trying to force every job into one giant calculator screen.

Finance software almost always becomes more complex after launch. New asset rules appear, underwriting assumptions change, workflows split by user type and reporting requirements expand. A disposable form architecture becomes painful very quickly.

Waaza's PostgreSQL model gives users, clients, vessels, assessments, assessment runs, rule sets, rules and audit logs explicit relationships. Prisma provides the application data layer. That gives the product room to add logic without losing the history of the cases already processed.

The application is built as custom production software rather than a no-code workflow. The current repository uses Next.js 16, React 19 and TypeScript, with Tailwind CSS 4 for the interface. Prisma 6 connects the application to PostgreSQL. The codebase also includes Stripe libraries and pdf-lib.

The broader lesson from Waaza is that custom financial software is rarely about reproducing an Excel calculation in a nicer interface. The valuable software layer is the system around the calculation: persistent case data, rules, traceability, scenarios, structured outputs and the UX that moves a user from uncertainty toward a decision.

That is the part of the Waaza build handled by Wall & Fifth: product architecture, interface design and the custom software system that connects those pieces into a usable platform.

For a product-specific breakdown, read How Waaza Was Built: Yacht Financing Software by Wall & Fifth.