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 exactly 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 the process could not be designed out of the problem
- Why stopping was worth more than fixing it
The hypothesis: Brands would buy a payment guarantee as a standalone service, outside of the marketplace.
The assignment: build a proof of concept, test it with clients, learn what to fix, keep going.
What I came back with: stop.
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 on the table was to unbundle 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 real cash.
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.
- Negotiated and translated the fintech partner's (frequently shifting) requirements into a usable experience.
- Built a fully functioning HTML prototype to test with real clients (using Claude Code and wired to our actual Design System).
- Tested the business model and prototype with 9 client companies.
- Analyzed the user tests and distilled the insights (AI-aided).
- Presented results and a recommendation to leadership: no product-market fit, close the initiative as currently scoped.
- 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 scope with 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. A brand had to produce a proof that the buyer relationship was real and had antecedents, then a finalized invoice with the right copy, then a signed proof of delivery, each at a different moment. I worked on three revisions making it as painless as the constraints allowed. But no amount of interface craft removes a step the partner requires.
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.
Because it was AI-assisted from the start, iteration came easy. The prototype went through 3 real revisions during the test window, driven by user feedback and the partner's shifting requirements. That turnaround isn't 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, not just the screen
We weren't testing a UI. We were testing an entire business model live: 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:
- Test the prototype first
- Make the sales pitch only 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. Invoice, preorder, proof of the buyer-seller relationship, a signed proof of delivery — a document requirement well past what most of these brands could produce on demand.
But the core problem was the price for what clients actually got. We were charging close to what a full payment guarantee costs, while only partially protecting brands if their buyer never paid. Clients who already used payment protection guarantees elsewhere spotted the mismatch immediately.
"I understand your process if there's a payment guarantee on the other end. If there isn't, I don't really see what I gain from it."
— Specialty artisan food brand
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, for the level of protection they expected us to carry, Ankorstore loses money on the transaction. Push the price up to where it's profitable and you're back to the number they had already 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.
Why this is the case study, not a footnote
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.