Tranquifinanzas
A YC-backed fintech's debt-negotiation platform that surpassed 100M COP in negotiated transactions within 8 months, scaling from one bank integration to five.
Problem
Colombians in debt had no direct way to renegotiate with major banks. The platform was originally built assuming a single bank, and that logic didn't generalize as the business needed to onboard products from five different banks, each with different terms, tone, and data shape — with a team of just two engineers.
Solution
Founding engineer on two products: a personal finance PWA (React, Material UI, GraphQL, Node.js, PostgreSQL) and the debt-negotiation platform itself. Refactored the frontend into a multi-tenant architecture that treats each bank like a locale — dynamic forms per bank/product instead of duplicated logic — backed by a generic, TypeScript-generic backend model so onboarding a new bank became a config change, not new code. Built a comprehensive Cypress end-to-end suite alongside unit tests to keep the negotiation flow reliable as new banks came online.
100M+ COP
Negotiated in 8 months
80%
Written-off portfolio captured
5
Banks integrated, 2-person team
Tech stack
Banks as locales
The platform originally hard-coded one bank’s terms, copy, and data shape directly into the negotiation flow — which worked exactly until a second bank needed to come online with different fields, different tone, and a different approval process. Rather than branch the codebase per bank, I treated each bank the way an i18n system treats a locale: a config bundle (form schema, copy, validation rules, branding) that the same negotiation flow loads at runtime. Onboarding bank #3 through #5 became writing a config file and QA-ing it against the existing flow, not writing new negotiation logic — the only way two engineers kept pace with the business signing new bank partners faster than a small team could ship bespoke integrations.
On the backend, that meant a generic, TypeScript-typed model per financial product instead of a table and a service per bank — the schema described what a negotiation is, and each bank’s config filled in the specifics.
Two products, one two-person team
Alongside the negotiation platform, I was also founding engineer on a companion personal finance PWA (React, Material UI, GraphQL, Node.js, PostgreSQL) — budgeting and account-tracking tooling meant to keep users engaged between negotiation cycles. Running both products with one other engineer forced sharp scoping: shared GraphQL patterns and component conventions across both codebases so context switching between them cost minutes, not days, and features that didn’t directly serve either the negotiation conversion funnel or user retention got cut rather than deferred.
Testing discipline at high stakes
A negotiation flow touching real debt and real banks doesn’t get a second chance with a user mid-conversation with their bank — a broken form or a miscalculated offer is a trust problem, not just a bug. That’s what justified a comprehensive Cypress end-to-end suite over the negotiation flow specifically, layered under unit tests for the per-bank config logic: every new bank config had to pass the same negotiation journey in CI before it shipped, regardless of how different its terms were from the first bank the platform ever supported.
The reconciliation tool
Not every win was user-facing. A monthly reconciliation process that used to take a full week of manual spreadsheet work — matching negotiated amounts against what banks actually confirmed — was replaced with a small internal tool that cut it down to about a day. Small in scope, but it freed up the kind of operational time a two-person engineering team can’t afford to spend on spreadsheets while also shipping bank #4 and #5.
Details
A landmark result in a highly regulated LatAm financial sector — securing contracts with several of Colombia’s largest banks from a standing start of zero.
The product has continued evolving since this build — the live site today reflects several redesigns past what was originally shipped.
