A printing and imaging brand wanted its distributors to browse and present the product range from their phones. The final catalog API was being built by another team, so in three weeks I built a working React Native prototype around a replaceable API layer: distributor login, categories, search and filters, and detailed product pages. When the real API is ready, it drops in without rebuilding the app.
At a glance
Distributors sell printers in person. Carrying brochures or digging through a website on a phone makes it hard to find the right model and show a customer the details.
There was a second problem: the real product catalog API was being built separately and wasn't ready. Waiting for it would have held the app up.
The app is organised the way distributors sell: by product line (inkjet, office, laser, and photo), with search and filters to narrow down quickly, and product pages with images, specifications, and features ready to show a customer.
Log in
An app only for the distributor network.
Browse the range
Inkjet, office, laser, and photo printers.
Search and filter
Narrow down to the right models fast.
Open a product
Images, specifications, and features.
Show the customer
Everything needed, on the phone in their hand.
Instead of waiting, I built the app against placeholder endpoints behind a separate API layer. The screens only talk to that layer, never to the placeholder data directly. When the final catalog API is ready, only the layer changes and the app stays the same.
That meant the prototype could be demonstrated on its own while the backend was still being built.
The real API was coming from another team. Keeping the app independent of placeholder data means swapping it in is a small change, not a rebuild.
Trade-off: Extra abstraction during the prototype.
One codebase for iOS and Android, so every distributor can use it whatever phone they carry.
“Our catalog API wasn't ready, but Milan still gave us a working app our distributors could try. Plugging in the real data later was easy.”
Yes. Build the app against placeholder endpoints behind a separate API layer, and agree the data shape with the backend team early. The app can be demoed and tested straight away, and connecting the real API later only touches that layer.
Often, yes. A clickable, working prototype lets real users try the flow and gives stakeholders something concrete to approve. It's much cheaper to change a prototype than a finished product, especially when other parts of the system are still being built.
If they sell in person and need to find and show products quickly, yes. A good catalog app with search, filters, and clear product pages beats brochures and a mobile website that wasn't built for presenting.
More work
2024
Vet clinic website that grew bookings from about 20 to 120 a week
2024
Executive search website: enquiries up from 7 to 20 a month
2026
D2C food store: 30K+ monthly visitors and 75% repeat customers
2026
AI chatbot SaaS: 30+ businesses and 100K+ messages handled a day