Origination, credit limits and commissions out of three people's heads — operational software for lenders
Make It Happen builds production platforms for lenders: origination modelled as a state machine, credit limits and commission scales in software instead of in somebody's memory, monthly close through an approval flow, role-based access control, row-level rules and an audit trail behind every decision.
This page describes what the studio builds for this kind of business. It does not claim a delivered engagement in that industry — where one exists, it is published on that industry's own page.
What this looks like today
Three people know which applications get approved and why. One of them decides limits, one maintains the commission scale in a spreadsheet with tabs going back four years, and one closes the month. Nothing is written down, and the business cannot grow past their calendars.
Six months later somebody asks why that application was approved at that limit. The answer is a search through chat, and the person who decided has left. Modelled as a state machine, every transition is stored as an event with the actor, the timestamp and the values before and after.
Commissions are the argument nobody wants. Tiers, thresholds, clawbacks and a scale that changed in March, reconciled by hand against a month that is already closed. In software the scale is a rule, the calculation is reproducible, and the disagreement is about the rule rather than the arithmetic.
What you get
Origination as a state machine — application, review, decision, disbursement — with every transition stored as an event carrying the actor, the timestamp and the values before and after.
Credit limits and commission scales as rules in software, versioned, so a calculation can be reproduced months later.
Monthly close moving through an approval flow, with threshold validation and a queue of what is waiting on whom.
Role-based access control edited from a panel, with row-level rules so an analyst, a commercial officer and a partner each see only their own rows.
An exportable audit trail and handover documentation written so a new engineer, or your auditor, can read the system without its author.
What this is not
No compliance certificate. We build the audit trail, the permission model and the documentation an audit reads; the certificate itself is issued by an auditor, not by a studio.
We do not write your credit policy. Scoring criteria, limits and risk appetite are decisions your own risk function owns; we turn the policy you approve into rules the system enforces and records.
We do not become your accounting or your regulatory reporting of record. The platform reconciles against your books and exports what a filing needs; the books and the filings stay on your side.
Service
Questions buyers actually ask
Can we prove who approved a loan and on what terms?
Yes. Every transition is an event with the actor, the timestamp and the values before and after, and the trail is queryable and exportable. An auditor reads it directly instead of asking somebody to reconstruct a decision from chat. Removing a person's access never removes what that account did.
What security proof can you show before we sign anything?
The mechanism, in writing, before the contract: role-based access control, row-level rules enforced where data is read, two-factor authentication, the audit trail and the handover documentation. What we will not show is a certificate, because a certificate is issued by an auditor and not by a studio, and anyone who says otherwise is selling a logo.
Do you have experience with lenders?
This page claims no lending case. Where we have delivered work in a sector, it is published as a case with the sector named on it; what is not published there we will not claim here. Judge this on the mechanism instead — the permission model, the audit trail, the handover documentation — and ask us directly in the first conversation.
Who owns the platform, and can we take it in house?
Ownership is a term of the agreement, not a default, and the proposal names it in writing before work starts. The documentation is written so a new engineer can run it without its author.
The possible part of the impossible.
If you have an idea that shouldn't work, bring it. We will tell you which part is genuinely impossible and which part is only hard. Most of it is the second one.