Designing as the owner
Why I retired Meerakl's messaging, and why I built Ansarr as my live website inside a native shell.
When I design for a client, I can argue for a feature or against one. The decision, and the bill for it, belong to someone else.
I also run my own company, Zoluna Ltd, and I build my own products. There the decision is mine, and so is the bill. Two decisions from this year came out of that. I retired Meerakl's messaging. And I built Ansarr as my live website inside a native shell, not as the faster app it could have been.
Neither was a design decision in the usual sense. In both cases the reason came from outside the design, and the design had to live with it.
Saying no to Meerakl's messaging
I built Meerakl as a CRM for small businesses in Africa that sell on WhatsApp and Instagram, starting with Nigeria. A seller connected their accounts, and their conversations and customers sat in one place, with broadcasts and automations on top. Underneath sat the connections to Meta's platforms, one for WhatsApp and one for Instagram.
In September 2026 I retired the messaging. The WhatsApp and Instagram connections came out, and with them the inbox, the broadcasts and the automations, and the database tables behind them.
I had two reasons, and neither was about the product.
The first was Meta. Most of the features I was building, a CRM for businesses, were being built by Meta itself, into WhatsApp and Instagram. I was building on Meta's platforms, and Meta was building the same things into them.
The second was trust. Nigerians have issues with trust, especially towards startups. Meerakl asked a seller to connect the WhatsApp and Instagram accounts their business runs on, and it asked as a startup.
A better screen fixes neither. I could have made connecting an account clearer, or the inbox faster. I could not make Meta stop building, and I could not make a country trust a startup sooner.
What would I do differently from the first day? I would check what Meta was building before I built on its platforms. And I would find out whether sellers would connect their business accounts to a startup before I built everything behind that connection.
Saying no still cost something. The work was real, and I deleted it.
Shipping the smaller version
Ansarr is my own product: a marketplace where researchers pay people to take part in their studies, and respondents are paid in naira for their answers. It is not on the app stores yet. It is coming to Google Play and the App Store, and Apple's verification is still pending.
Smaller here is not about features. It is about how the app is built. The Android app is not a second app. It is my live website inside a native shell. There is one codebase. When I deploy the website, the change reaches every phone at once. Only changes to the shell itself go through the app stores.
The cost is speed. Every screen is a trip to a server, and that sets a ceiling on how fast the app can be.
I measured before I optimised. I built a test page that talks to the database straight from the phone. Data came back in about 200 milliseconds on 4G, so the database wasn't the problem. That pointed at the expensive fix: move the interface into the app and fetch only data. I built Ansarr without it.
So the trade is plain. One codebase that ships everywhere at once, in exchange for an app with a ceiling on its speed. I know where the ceiling is, and I know what raising it costs. That is a different kind of smaller from cutting features. It is the version one person can keep shipping.
For a client with a bigger budget, my advice would be different: build the interface into the app from the start and fetch only data, so that speed is not capped by a server. Measure first all the same, and pay for the fix the numbers point at, not the one that looks obvious.
What the owner decides
Both decisions made something smaller. One took a product away. The other built an app with a ceiling on its speed.
Neither was free, and neither was a design fix. Retiring the messaging meant deleting work I had built, for reasons no screen would have changed. Building Ansarr in a shell meant accepting a slower app, for a reason that had nothing to do with its screens either: one person, one codebase, every phone at once.
As a designer I can argue for the better screen. As the owner I have to know when the better screen is not the answer, and say so. Then I have to say what the answer cost. On the Ansarr case study, every decision sits next to its cost. This essay does the same for the two decisions I made as the owner rather than the designer.
If I had one sentence for another founder who designs, it would be this: when the reason is the market's, stop. When the constraint is yours, ship the smaller version. Either way, write down what it cost.