Transitions 19 April 2026 9 min read

The Betzone build

A case study in skill transfer. What it actually took to move an idea from a brief in a Nairobi office to a licensed business with a shopfront in Juba.

The brief

There was a moment in 2023 when everything the humanitarian sector had taught me was active at once.

The CEO of Nile Capital gave me a brief that sounded simple. Take Betzone, an online betting startup the company was developing, and build it into a business. Not manage the communications for it. Build the business.

I had spent fifteen years doing specific things well. Researching in difficult environments. Writing under deadline. Coordinating across stakeholders who did not share context. Translating between specialists and the people their work affected. Running projects whose plans had to survive contact with the environment. The Betzone brief required all of those at once, pointed at a subject I had never worked in, inside a company much smaller than any humanitarian institution I had served.

I took it. I did not know, going in, whether any of what I had built in the sector would actually do this job. I know now that it did. I also know now, in a way I did not know then, what the limits of skill transfer are. This essay is both of those learnings, held together.

The research phase

The first thing I did was what I had always done. Research the environment before moving.

Betzone’s original concept was a crypto-based lottery platform. I approached the industry the way I had approached food-security dynamics in Jonglei State. Triangulate primary sources. Work with partial and sometimes contradictory information. Build a defensible picture of the market from what was available. Be explicit about what you know, what you are inferring, and what you do not yet have good evidence for.

The research pointed away from the original concept. A crypto-based lottery in the South Sudanese market faced regulatory uncertainty that the company was not positioned to absorb. More importantly, the product-market fit question pointed in a different direction. The market was already comfortable with sports betting, the licensing path existed (with difficulty), and the revenue model was clearer. We pivoted. The third-party licensing fees for existing betting software were prohibitive, so we decided to build our own.

That pivot, documented with the same epistemic hygiene an assessment cycle required, held up under review. The next twelve months proved it was the right call. Not because the business became profitable, we will get to that, but because the alternative would have been worse.

Building the institutional infrastructure

Before the platform could operate, the company had to exist.

I handled the company registration process, located and secured office space in Juba, and assembled the documentation portfolio that a licensed betting operation requires. Corporate registration papers. Tax compliance filings. Technical specifications for the platform. Application materials for a government betting licence. None of that was technical work in the software sense. All of it was procedural work that required understanding a system of rules, producing the correct documents in the correct order, and maintaining relationships with the authorities whose approvals the business needed.

A humanitarian professional has been doing this kind of work for years, usually without calling it “government affairs” or “regulatory engagement.” Every humanitarian programme requires negotiation with ministries, registration with national bodies, and ongoing compliance with oversight requirements that shift without warning. The documentation portfolio for Betzone’s licence was a new subject. The discipline of assembling it, reviewing it against the regulator’s expectations, and maintaining the relationship with the licensing authority while the software team was still building the product the licence was meant to cover, was not new at all.

The licence came through after months of sustained engagement. It was not automatic. It was also not impossible. The difference between those two states, in a regulatory environment, is almost entirely a matter of whether someone in the company is treating the regulator as a relationship to be stewarded rather than an obstacle to be outmanoeuvred.

Managing the development cycle

Managing the software build was the longest phase and the most sustained test of the project management and leadership skills I had built across humanitarian responses.

The development team was building a betting engine from scratch. Odds calculation. Payment rails. User account management. Anti-fraud compliance. A front end that had to work on both web and mobile. I was not a developer and I had no formal authority over the team. I was the person coordinating between the business requirements, the licensing requirements, the CEO, and the engineers.

Leadership without authority is a skill the humanitarian sector builds early. A communications officer in a field response is responsible for getting a public statement out by the end of the afternoon, and has no formal authority over the field teams whose verified facts the statement depends on. The work gets done by convening, coordinating, and carrying the responsibility for the shared outcome, without ever being in a reporting-line position to compel anyone. At Betzone, the engineering team, the marketing team, the regulator, the CEO, and the field testers had me as their coordinator, not their boss. The work got done by the same muscles.

I onboarded field staff to test the platform in advance of public launch. Defining test scenarios. Collecting structured feedback on the user experience. Translating that feedback into language the development team could act on. A tester who says the deposit process is confusing is not submitting a technical specification. Converting user experience observations into buildable requirements is exactly the same translation work I had done for years between programme staff and monitoring and evaluation teams. The subject was different. The craft was the same.

Taking it to the street

While the software was being built, the marketing had to begin.

I commissioned a designer and briefed him on the brand identity and the marketing materials. Digital graphics for social media. Print-ready layouts for physical distribution. Once the materials were produced, I secured the print resources, coordinated with the printer, and took the campaign to the street.

This meant going out in Juba with posters and stickers, covering the city’s physical advertising spaces, and approaching raksha drivers, the auto-rickshaws that carry most of the city’s daily traffic, to carry Betzone stickers on the backs of their vehicles. The raksha fleet became a mobile advertising network moving through every neighbourhood in Juba. The campaign was low-budget and ground-level, and it worked in exactly the register the product needed. The market became aware of the brand. The shopfront began to see walk-ins.

A humanitarian communicator does this work constantly. Information-product dissemination in a humanitarian context is not glossy. It is posters on the walls of community health centres. Briefing cards handed out at cluster meetings. Radio spots recorded in four languages. The theory is the same theory that marketing rests on: figure out where the audience already is, meet them there, and give them something they can remember. The raksha fleet in Juba is an information-dissemination channel. Treating it as a marketing channel required no new capability, only the willingness to see what was already there.

The hard stretch

I owe the reader a section on what went wrong.

The platform went live and the software kept failing. There were months when the load broke the system. There was an influencer campaign I had commissioned, using the budget I had been given, that brought users to a product that was not ready for them. The retention numbers that followed were predictable in hindsight and painful at the time. The costs kept rising. The revenue did not. Eventually, we had to reduce staff significantly. People who had built the product with me were not among those who stayed.

I have not tried to clean those months up. They were part of the work. They are part of the honest answer to the question of what this essay exists to answer, which is whether the humanitarian toolbox does this kind of work.

The answer is: yes, and. The skills transfer. They do not, by themselves, guarantee the outcome. A business also needs timing, capital, market conditions, and, eventually, some luck. The skills are necessary. They are not sufficient. What they are is yours, regardless of what any single venture does with them. You carry them into the next assignment, the next company, the next decision, whether the venture you just ran made a profit or did not.

Where it stands

As of today, the Betzone website is live. The mobile app is running. The shopfront is operational in Juba. The product that began as a brief in a Nairobi office is a licensed, functioning business with a physical presence.

What it does not yet have is the scale at which a betting platform becomes self-sustaining. That question is still open.

I want to be careful about how I characterise this, because the honest characterisation is neither a success story nor a failure story. It is a story about what it actually takes to move an idea from a conversation to a running product. The research to understand an unfamiliar industry. The institutional work to register a company and obtain a licence. The project discipline to manage a year-long software build with a team that had never worked together before. The marketing discipline to take a new brand to a city that had never seen it. The communication discipline to keep a regulator, a development team, and a CEO telling the same story about the work.

Every one of those was a humanitarian skill, re-pointed. None of them were new capabilities I had to acquire from scratch. The industry was new. The subject matter was new. The capabilities were not.

What the case study is, and what it is not

If you are a humanitarian professional reading this because you are weighing a move, I want to be specific about what this case study does and does not demonstrate.

It demonstrates that a former humanitarian communicator, working inside a small firm, can be handed a brief to build a business from architecture to launch, and can execute the brief. The building happens. The regulatory work happens. The product ships. The brand takes hold. The capabilities that make that happen are, in almost every instance, capabilities the sector trained.

It does not demonstrate that every such venture will succeed. Mine has not yet, in the market-scale sense. The question of whether Betzone becomes profitable is outside the skill set this essay is arguing for. That question belongs to capital, market conditions, competitive dynamics, and the kind of luck every early-stage business needs. The case study is about whether the work you have already done can do this work. It can. Whether this particular version of this work becomes profitable is a separate question, and pretending otherwise would be dishonest.

The sentence I come back to

None of that is starting over. All of it is the humanitarian toolbox, applied to a domain that uses different words.

The research is from the same discipline I built across years of REACH and IMPACT Initiatives assessment cycles. The regulatory work is from the same discipline I built in ministry engagement for humanitarian programmes. The project management is from the same discipline I built running multi-stakeholder humanitarian responses. The marketing is from the same discipline I built disseminating information products in field contexts. The hard weeks, when the software failed and the staff were reduced, are the same hard weeks any humanitarian professional has lived through when a programme closed, a funding cycle ended, or a response had to contract faster than any of us wanted.

You already have the toolbox. The work is learning to name it in the market’s vocabulary, and then going to use it.