How to read a fintech design agency’s case studies

The portfolio looks right: banking logos, elegant dashboards, a few large numbers. But your project is a lending workflow with difficult eligibility rules. Which case shows that the agency can handle that work?

A fintech client name is a starting point. The useful evidence is what the team actually did, why particular decisions mattered, and how closely that work resembles your problem. A marketing website, a banking app, and an API integration can all appear under the same fintech heading.

Read the cases as evidence for a specific assignment. The examples below come from agencies’ own public accounts. They help establish scope; they are not independent audits of results.

What does the case actually prove?

Take Eleken’s PayUp case. The account describes extending a mobile financial product into a web app and building a design system. It includes a concrete design problem: allowing workers to change payment terms for individual invoices. It also describes prototypes tested by the client with existing users.

Those details support a discussion about financial workflows and iterative product design. They do not, by themselves, establish a measured increase in revenue or the agency’s ability to handle every regulated banking process. The productive follow-up is to inspect how the payment-term flow changed after testing and what the team learned.

Now consider Eleken’s Prift case. It describes an MVP for personal financial planning, prioritization of features, and a working prototype. It explicitly says the client had completed the initial user research. That distinction matters if your brief includes research from the beginning. Ask which research the proposed team would conduct, rather than crediting the agency with every activity mentioned on the page.

Why does scope matter more than the logo?

Netguru’s Solaris case documents backend engineering: API work, support for debit-card and loan-product systems, and test automation. That is relevant evidence for an engineering integration brief. The page alone is not proof of a consumer banking interface redesign.

Apply the same standard to Humbleteam. The public One Bank case shows product UX/UI for an account overview, cards, transfers, transaction details, and related banking screens. It supports a conversation about mobile banking interface work. The published page does not establish a measured reduction in recovery failures or demonstrate a bank’s entire operational transformation.

This prevents a surprisingly common mismatch: a buyer asks for one kind of work and receives a persuasive case about another. It also keeps the evaluation fair. An agency should receive credit for the contribution it can substantiate.

How can you compare the evidence side by side?

Write down your assignment first. Suppose, illustratively, that you need to redesign how small businesses review and change invoice payment terms. The comparison might look like this:

This is a fit worksheet, not a ranking. Change the assignment to banking middleware and the relevance of the same evidence changes. Change it to a consumer planning MVP and a different case becomes useful.

Keep empty cells visible. “Need to verify” is an action for the next conversation. Filling the gap with a score would only make the spreadsheet look more complete.

What should you ask to see behind the polished screen?

Choose one decision from the most relevant case and follow it backward. What problem did the team observe? What alternatives did it consider? What constraint removed an attractive option? What changed after review or testing?

Then follow it forward. Ask how the design reached engineering, how exceptions appeared in the specification, and which parts shipped. A prototype and a live product answer different questions. If the agency cannot share confidential artifacts, a redacted walkthrough or a discussion of the decision can still be useful. Confidentiality is a limit on the available evidence, not permission to invent it.

Clarify who did the work. The people who present a case may not be the people available for your project. Ask about the proposed team’s contribution and who will own product decisions, research, and design review in your engagement.

When a case reports an improvement, ask what was measured, over which period, and what else changed. A conversion increase after a release might coincide with a pricing change or a different acquisition channel. Preserve those conditions instead of attributing the entire result to design.

What should the shortlist produce?

End each case discussion with a brief written conclusion: the part of your problem the evidence covers, the unanswered question, and the next artifact needed to answer it. For the invoice example, that might be a walkthrough of changing payment terms when an invoice is already processing.

You can then agree on a bounded working session or a scoped first phase. Give every candidate the same sanitized problem and constraints. Evaluate the questions they ask and the decisions they explain, with payment and scope agreed before any substantial custom work.

The fintech agency comparison can help build the initial list. This worksheet helps narrow it. The outcome is a shortlist supported by relevant work, with the remaining uncertainty written down clearly enough to resolve before the project starts.