From a tool
to infrastructure.
A complete platform for remote collections.
Born during the Covid emergency as a solution for digital payments, SinerPay is today a complete platform for remote collections.
The flow is essential by design: a campaign, a list of contacts, a personal, expiring payment link delivered on the chosen channel. Whoever receives it pays in seconds, from any device — no counters, no queues, no sign-ups.
In 2020 their customers
could no longer pay.
Counters were closed, physical collection points out of reach. Bills went unpaid not for lack of will, but for sheer impossibility.
On one side, people who wanted to settle up and couldn't; on the other, companies with cash flow at a standstill.
The product's first version was born to solve exactly this. No platform ambitions: a single flow, stripped to the bone. The company uploads the contact list, the system sends each person a personal link, the recipient opens it and pays.
The interface was minimal because the problem was clear — and nothing else was needed.
It worked.
Same problem,
a completely different scale.
Then a large financial operator arrived. The product was no longer a tool on the side of the process: it entered the critical flow of a regulated organization, with volumes an order of magnitude higher and a margin for error close to zero.
The context was high-pressure: deadlines set long before, a client who had already announced a date to their own organization, a calendar that left no room.
In those conditions the temptation is always the same: cut reviews, skip tests, claw back days. We did the opposite. Test cycles kept, reviews kept, discipline kept — precisely while everything pushed the other way.
Generalization is the phase
where products lose their way.
A product that grows in a volatile context accumulates choices made in a hurry. It's natural, and pretending otherwise is dishonest.
The difference between debt suffered and debt managed is awareness. Every time a priority put an area of the product on hold, it was a decision made, noted and planned — not an oversight discovered two years later.
A log of what hurt the people who used the product.
We started keeping a log. Not of bugs — those get fixed and forgotten — but of which operation took three steps instead of one. Where people got stuck. What they asked for on the phone in a tone that betrayed their frustration.
After years, that log had become something no product management meeting could ever produce: the exact, verified list of the points where the product let its users down. Three themes came back more than all the others.
Designed for a year,
before a single line of code.
With this data we could have pushed much further: device, client, browsing behavior. Technically it was within reach. We stopped.
What to collect is defined together with the client, based on their privacy requirements and policies. In a regulated sector, collecting less than you could isn't a product limitation: it's part of what makes it installable.
The same goes for discarded ideas. We explored emotion analysis during payment and abandoned it: asking for an invasive permission to get a datum that two direct questions give better isn't innovation — it's friction.
The three decisions
that hold up v5.
In earlier versions each component lived in a separate repository: the API on one side, the panel on another, the apps elsewhere. On paper, modularity. In practice, no: whoever installs the API necessarily installs the panel too.
They were parts of a single product, kept artificially separate. The result: versions to align by hand, changes crossing several repositories, technical onboarding slower than necessary.
Uploading a contact list was processed during the request itself, contact by contact. With a few dozen recipients it worked.
With a few hundred, the user was stuck in front of a frozen screen — exactly when they needed to do something else.
Rewriting a product in production at clients in regulated sectors can't be a single event, with everyone migrating the same day. No client accepts that risk, and they're right.
The v5 architectural patterns were back-ported to the existing installations, incrementally, starting from the areas of greatest pain.
Five versions.
The product keeps evolving.
A product born to solve one company's problem during an emergency, today installed at operators in two regulated sectors, with thousands of transactions handled every day. v5 is in production.
In five years it's not just the code that changed. What changed is how you decide what to build: no longer from a request that arrived by email, but from what we saw happen in the field — installation after installation, call after call.
This project tells
the studio's method well.
