zendit

zendit connects businesses to thousands of prepaid products through APIs and a management console. One customer might be adding airtime top-ups to a wallet; another might be offering eSIMs, gift cards, or utility payments.

The range was useful, but it made the company hard to describe. There was no brand, no shared product language, and no easy way to show buyers how the pieces fit together. I joined while the team was still working out what zendit should look and sound like.

I was hired to make a visual identity and marketing site. That lasted about five minutes. The promise on the website had to match the software behind it.

I ended up working across the client console, internal admin tools, product UX, frontend, icons, illustrations, and brand guidelines. A buyer should have been able to move from a landing page to a product screen or sales deck without wondering whether another company had taken over.

The catalog alone contained more than 16,000 products across 190+ countries. Operators also had to deal with availability, pricing, margins, balances, reports, alerts, users, currencies, and permissions.

The product was dense because the work was dense. I had to decide what needed attention now, what could wait, and which patterns should repeat. The brand also needed some personality without making financial infrastructure look like a toy.

“16,000+ products” sounds impressive, but it does not help someone picture the work. The story became clearer when I organized it around jobs: launch a new revenue stream, send a reward, keep a traveler connected, or manage products and balances.

That worked in the console too. I gave the common jobs priority: find a product, check availability, review a balance, change a margin, or investigate a report. Everything else could wait.

I did not finish the identity and then hand it over to product. I moved between the two. A color that looked good in a campaign had to remain useful in a dense table; a console pattern had to feel at home on the marketing site when shown as product proof.

Weak ideas showed up quickly this way. I built the website in the browser, designed the main console flows with real content, and turned repeated solutions into components, icons, illustration rules, and written guidance.

There was no dramatic reveal. We shipped an identity, a website and developer story, a client console for products and accounts, admin tools for internal operations, and a library of reusable visual assets.

The cherry-red palette and hand-drawn illustration style made zendit recognizable, while the product stayed quieter and more functional. I reused the same type, spacing, components, and icon rules without forcing every screen to look like a marketing page.

Before this, zendit had a powerful platform, but every new page or screen had to work out what zendit looked like again. Afterwards, product, engineering, marketing, and sales could draw from the same set of patterns and assets.

As the work grew, new pages, console features, campaigns, and event material could start from something proven. The guidelines did not do anyone's job for them. They just stopped every new page becoming another debate about which red to use.

A brand can look brilliant in a mockup. Then you put it beside a table with thousands of products and find out whether it actually works. Designing the identity and the console together kept both honest: the brand could not become theatre, and the product could not become anonymous.

I would use the same test again. Can the idea explain the business in ten seconds? Can it survive the messiness of the real product? If yes, keep it. If not, back to Figma.