Factoring: A Fast Fail

A bet

This project wasn't set up as a go/no-go. A team had been assembled, a partner had been signed, a squad was allocated. The default was to keep going, iterate on the pricing, and try again. Four weeks in, I brought back relevant feedback from real clients and an unexpected answer: this doesn't work in its current form, it can't be made to work at a price that makes us money, and here is why.

This case study covers:

• Why the hypothesis looked sound on paper
• How I built and tested it with real clients in 4 weeks, using AI at every stage
• Why design couldn't fix the core problem
• Why stopping was worth more than fixing it

The problem

Supplier brands sell to retailers, but retailers don't pay right away. The norm is 30, 60, even 90 days of margin to sell the stock before paying the brand back. Great for retailers. Hard on small brands, who need that cash to reinvest and build new stock in the meantime.

Ankorstore already solves this on the marketplace: brands get paid the moment a shipment is delivered, while retailers keep their deferred terms. The idea was to that value prop and sell it on its own, as a factoring service outside of the marketplace.

Not the first attempt

This wasn't the company's first swing at it. An earlier product, "OrderPay," tried to solve the same problem and ran for 16 months despite high default rates, without being stopped or meaningfully pivoted. It cost real R&D time and money.

This new pilot existed specifically because OrderPay had finally been shut down. It was framed internally as the safer, better-scoped follow-up, and it carried momentum: a partner deal in progress, a squad assigned, an expectation that this version would be the one that worked.

What I did

A small cross-functional team formed: a sales agent to reach real clients, a PM to coordinate and negotiate with the fintech partner providing the financial infrastructure, engineering support for the integration, and me, designing the experience and running the research.

What I did:

1. Negotiated and translated the fintech partner's (frequently shifting) requirements into a usable experience.
2. Built a fully functioning HTML prototype to test with real clients (using Claude Code and wired to our actual Design System).
3. Tested the business model and prototype with 9 client companies.
4. Analyzed the user tests and distilled the insights (AI-aided).
5. Presented results and a recommendation to leadership: no product-market fit, close the initiative as currently scoped.

My recommendation was accepted.

The partner: a pilot on top of a pilot

The fintech partner (unnamed here) was the key to unlocking Factoring. They already offered this kind of service, had the infrastructure to run due diligence and assess risk on each loan, and saw us as an opportunity to expand into a white-labelled offering of their own. We were a pilot to them, while we were building a pilot on top of theirs. A pilot-ception, if you will.

Requirements changed weekly, the list of "must-have" documents kept growing (from 3 to 7 documents per order, depending on the week), and building the prototype became as much a tool for negotiating scopewith the partner as it was for testing with clients.

This is where the real design problem was. Every requirement they added was non-negotiable and had to land somewhere in the user's flow. Proof was requested that:

• the buyer relationship was real and had antecedents
• finalized invoice with a special adjustment: the buyer will pay our FinTech partner, not their own supplier
• signed proof of delivery

Prototyping AI-first

There was no time for polished Figma flows and handover docs. An engineer on my team had recently built a lightweight HTML starter kit wired into our Design System, and I used it as the base to build the entire flow myself with Claude Code, publishing it live on GitHub Pages so it could be tested like a real product.

Live prototype

Open in a new tab

Because it was AI-assisted from the start, iteration came easy. The prototype went through 3 significant revisions during the test, driven by user feedback and the partner's shifting requirements. That turnaround wouldn't have been realistic with a traditional Figma prototyping process. The dev team didn't need to be involved at this stage at all.

Testing the business model

On top of the UI, we were actually testing the entire business model: commissions, payment timing, document requirements, all of it moving while we tested.

I ran the sessions with the sales agent, whom I'd trained beforehand on unbiased questioning and moderated usability testing. Even though his end goal was to sell the service, we were both in researcher mode in the room. Every session ran the same way:

1. Test the prototype first
2. Make the sales pitch after

Two weeks of synthesis in two days

I had 9 recordings, ~45 minutes each, and 2 working days before the decision meeting. What would traditionally take up to two weeks of transcription, tagging, and pattern-finding, I compressed into that window using an AI-assisted research workflow, without giving up rigor.

Sessions were recorded with an AI note-taker that also handled French-to-English translation. I fed the transcripts into a Claude project connected via MCP to our call-recording tool, and built the research plan with Claude. To train the "researcher" and make sure it wasn't hallucinating or inventing patterns, I rewatched several sessions myself, tagged the quotes I judged relevant, and sent each one with the angle I wanted flagged. That output became a structured CSV I could scan for cross-interview patterns. Only after "training" the process on 5 sessions this way did I let it run analysis on the remaining 4, under my supervision.

What the data surfaced

The requirements were the problem. The 3-4 documents at different points in time was a requirement well past what most of these clients were willing produce.

The core problem was the price. Compared to other competing providers, such as banks, we were charging more. Being in the middle of the provider and the client didn't allow us to make money on a project expected to be sustainable from the get go.

Of the 20 client companies pitched (not all were shown the prototype), not one gave an unconditional yes.

The opportunity cost

The usual course of action would have been to tinker with it: reduce the commission, restructure the payment terms, negotiate the document list down, push harder on sales. However, at a price clients told us they would accept, Ankorstore loses money on the transaction. Push the price up to where it's profitable and you're back to the number they had rejected.

The document overhead was the partner's condition for carrying the risk, so cutting it meant either a new partner or carrying that risk ourselves. Every direction to tinker in led somewhere we had already been (OrderPay), or somewhere unprofitable.

Meanwhile, the marketplace itself, our actual business, had known experience problems that were driving churn on the core product. Those were fixable, by the same squad, on a much shorter timeline, with a return we could already estimate. So the real question was never "can we make this work." It was "what else could we be doing."

The decision: refocus, don't tinker

The recommendation landed. Leadership closed the initiative and moved the squad back to the marketplace.

Closing it at four weeks kept the cost to a short pilot instead of a squad's salary, a partner integration, and a sales onboarding effort that a green light would have triggered next. That's the tens of thousands of euros this saved. The 16 months spent on OrderPay is what that decision looks like when nobody makes it.

Learnings

In a world where designers are asked to build and deliver, being able to stop and ask whether something should be built at all is a different kind of value, one that's much harder to see on a roadmap, but shows up very clearly on a P&L. Sometimes the most senior thing a designer can do is hand leadership the answer they didn't want, early enough that it's still cheap to hear.