Yusr
A Buy Now, Pay Later platform for the UAE automotive services market. Repair shops submit loan applications for their clients; the platform verifies identity, scores credit risk and sets up the payment plan.
Context
Lending decisions had to be made in about a minute, without a human in the loop, for clients walking into a repair shop. That means identity, fraud signals and credit risk all have to resolve while the customer waits at the counter.
The constraint: everything ran on a no-code stack. The front end was Bubble, so the decision logic, the integrations and the money handling had to live in the database layer and stay auditable there - not scattered across workflows.
Role & scope
What I owned
Backend logic in Supabase (PL/pgSQL), all third-party integrations, the underwriting engine that turns those inputs into a decision, the security model, and the migration onto the banking core. The credit model itself belongs to the client’s analytics team - mine is everything feeding it and everything that happens after its answer.
Who else was involved
A cross-functional team: a second developer, QA, designer, PM, analyst and DevOps.
How long it ran
October 2025 to August 2026. The project ended when the client outgrew no-code: compliance requirements called for a custom stack, and the product moved to code.
Process
01 · The decision engine
The core is a PL/pgSQL trigger that fires the moment identity verification completes. It pulls from five sources - KYC, credit bureau, device fingerprint, WhatsApp verification and the applicant’s own loan history - assembles them into one package and sends it to the client’s scoring service through an AWS Lambda hop, because Supabase runs on RDS and RDS cannot make outbound HTTP calls on its own.
The answer comes back, gets stored, and the underwriting function weighs it against six other indicators before returning a decision. A good score does not approve a loan by itself, and failing an earlier rule ends the application before scoring is ever consulted.
Identity deduplication uses Levenshtein distance to match a submitted name against the Emirates ID, because real names arrive misspelled, reordered or truncated by the bank.
02 · When the score isn’t enough
Some applicants come back from scoring with “needs a closer look”. For them the platform offers to connect a bank account through Lean, an open-banking provider. Their widget is a JavaScript SDK, so it runs inside Bubble through a script hook.
My side is what happens after the applicant presses Connect: pulling their identity, their accounts, and six months of transactions per account, storing all of it, and walking it in loops before a PL/pgSQL function makes the final call.
The hardest part wasn’t the data. It was that the widget silently refused to open in Safari and inside WhatsApp’s in-app browser, where overlays and cookies are restricted - which we only found by asking applicants for screen recordings.
03 · A data leak, fixed at the root
In June a third-party Bubble plugin turned out to behave differently against
demo and production, and merchants could see each other’s data. The quick
fix would have been patching the query. Instead I replaced the plugin with a
SECURITY DEFINER SQL function that enforces company-scoped
filtering on the server, where a client-side mistake cannot reach it.
The same principle shaped the rest of the security model: row-level security policies across every table, with separate rules for merchant, client and admin scopes.
04 · Moving the loan book
The client moved onto a banking core, and the entire live portfolio had to go with it - without pausing lending. I built a Python ETL that converted five Supabase exports into the core’s schema, handling malformed CSV, rounding mismatches and duplicate customers.
It ran demo first, then a thirty-five batch dry run, then production, checked by a nine-point SQL verification framework. Every balance reconciled: 1,395 loans, 1,294 clients, 7,496 invoices, 5,634 payments.
Afterwards the underwriting had to change too. Decisions now query the banking core live at three points - active loans, overdue status, credit limits - instead of trusting a local copy that could already be stale.
Outcome
258
Active merchants, up from 10 in seven months
1,395
Loans migrated, zero balance discrepancies
~1,000
Loan applications a month through this logic
Julia and I spent about a year building YUSR bnpl together - not just an MVP, but a full working BNPL fintech system: the website, the customer portal, the merchant portal, and the admin backend. She’s one of those people who just gets things done - if something’s broken or unclear, she’ll dig until she actually understands why, not just patch the symptom.
She’s also one of the most reliable people I’ve handed a task to. You can give Julia something and just not worry about it - no need to micromanage or check in constantly. She’ll ask the right questions upfront, figure out the rest herself, and you can trust the implementation will be solid.
What stood out most was how she handled Bubble’s limitations. Building something this complex on a no-code tool means running into walls constantly, and Julia was consistently good at finding a practical way through instead of just shrugging and saying it’s not possible. On top of that, she is just genuinely easy to work with, clear communicator and reliable.
We eventually moved off Bubble as the company grew and needed a custom stack for compliance reasons, and Julia helped with that migration too. I’d happily work with her again, and I recommend her without hesitation.