How a small team ships across two markets

The standard advice for a small team is to go deep on one thing. Pick a single problem, build the best possible answer to it, and don't get distracted. It's good advice, and we ignored it. solveX builds across trust, money, and mobility, in two countries, with a team you could fit around a dinner table. That should be a recipe for shipping nothing well. Instead it has taught us more about how to ship than any single product ever could, because when you are spread thin, the habits that don't actually matter fall away fast, and you are left holding only the ones that do. Here are the four that survived.

Build problems, not products.
The temptation, especially when you can build things quickly, is to fall in love with an idea and go looking for someone who has the problem it solves. We have learned to run it the other way around. We start with a problem we have watched real people struggle with, whether it's a stranger in a Nigerian marketplace who has no way to know a seller won't vanish with their money, or a UK worker walking into a salary negotiation with no idea what the role actually pays, and we only build once we are sure the problem is real, specific, and painful enough that someone would change their behaviour to make it go away. Ideas are infinite and mostly worthless. The discipline isn't generating them; it's refusing to build the ones that aren't attached to a genuine problem. That single filter has killed more of our projects than anything else, and every one of those deaths saved us months.

Ship by subtraction.
The fastest way to never launch is to build the complete version. The most useful decision we make on almost every product is what to leave out, and often the thing we leave out is the hardest and most expensive part. Think about what it takes to make two strangers trust each other enough to trade. The maximal build is to become a full logistics company that owns every step of the journey. With Kwick we did the opposite. We found the single thing that was actually breaking trades, money changing hands before either side felt safe, and we solved just that with escrow, then let the rest stay simple. Paycheck works the same way. We could have built an entire career platform around it, but the thing people actually needed was the one number they were never given, so that is what we built first. Subtraction isn't cutting corners. It's finding the smallest thing that genuinely solves the problem, and having the discipline to stop there.

Let the second market be a forcing function. Building in Nigeria and the UK at the same time sounds like double the work, and in some ways it is. But two markets keep you honest in a way one market cannot, because you can never mistake a local quirk for a universal truth. The moment you assume "this is just how people behave," the other market shows you people who behave completely differently, and that forces you to find the actual principle underneath. Trust, information, dignity: the deep problems turn out to be shared, even when the surface behaviour is nothing alike. Working in two places at once didn't slow our thinking down. It stripped the parochialism out of it.

Treat a small team as a constraint that clarifies, not one that limits.
When you don't have the people to do everything, you are forced to answer a question most teams avoid for far too long: what actually has to be done by us, right now, for this to work? A small team cannot build the whole roadmap; it can only build the next real thing. So we prototype before we commit, we sequence our bets instead of running them all at once, and we say no far more than we say yes. The constraint does something a bigger team makes easy to dodge. It makes us decide. And deciding, over and over, is most of what shipping actually is.

None of this is unique to us, which is exactly why it's worth writing down. If you are building with a small team, in a hard market, without the luxury of doing everything, the answer isn't to wish for more resources. It's to get ruthless about problems, ruthless about scope, and honest about what only you can do. We didn't arrive at any of this because we are disciplined by nature. We arrived at it because building wide left us no other choice, and the constraints turned out to be the best product managers we ever had.

solveX is a product studio building digital tools for African and diaspora communities across Nigeria and the UK.