Introduction
A year goes fast when you're building.
I joined Omaze as their first mobile engineer in June 2025. No mobile team, no mobile culture yet. An inherited codebase, a lot of ambition, and a product that deserved better than what it had on mobile.
The app existed. Users were using it. But underneath the surface, most of what they were seeing wasn't native. It was web, wrapped in a shell, doing its best to feel like an app. And for a while, that was enough. But "enough" has a ceiling, and we were hitting it.
I came in with context. Before I joined, I'd spent time doing a deep dive on the app, mapping what was native, what was WebView, where the gaps were, and what it would take to close them. That document became something of a north star for the first few months. Not a rigid plan, but a reference point. A before.
I also came in with experience. At THG I'd led the native migration of over 20 apps, taking them from WebView heavy experiences to fully native ones. I knew what this kind of transformation looked like, what it demanded, and what it unlocked on the other side. Omaze felt like the next chapter of that story, with a bigger opportunity to get it right from the start.
This post is the after. Or at least, the one-year checkpoint.
It's not a story about everything going smoothly. It's about inheriting something imperfect, understanding why it is the way it is, and making deliberate decisions about what to build next and how to build it in a way that lasts.
Where We Started
To understand where we are, you have to understand where we came from.
The Omaze app had its foundations laid before mobile had a dedicated home. You need something in the market, you move fast, you make trade-offs. The trade-off here was WebView, and when you're moving at that pace, that makes complete sense.
WebView isn't inherently bad. It gets you to market. It keeps web and mobile in sync. It lets a small team maintain one codebase without stretching across platforms. But it comes with a cost that compounds over time. Performance ceilings, limited access to native APIs, animations that never quite feel right, and a user experience that, if you pay close attention, always feels slightly off. Not broken. Just not native.
Before I joined, I mapped the app screen by screen. Home, draws, entries, account, checkout. I wanted to understand what was actually running under the hood. The only truly native screens were onboarding, the landing page, login, sign up, notification opt-in and the cookie opt-in. Everything beyond that first-time user journey was web inside a container.
I was energised by it. From a native perspective it actually felt like a greenfield opportunity. I wasn't inheriting years of native technical debt or conflicting architecture decisions. The native layer presented an opportunity to showcase what I do best, building thoughtful, performant native experiences from the ground up with intention.
The Challenges & Going Fullstack to Move Faster
The enthusiasm I came in with was real. But enthusiasm meets reality quickly.
The first challenge was the infrastructure the app was sitting on top of. The backend had been built to serve the web first, which made complete sense given where the product was at the time. There were APIs in place but the coverage for what mobile needed wasn't there yet, and without a headless CMS, pulling content into native screens in a meaningful way just wasn't possible.
The second challenge was speed. In the early days with a lean engineering team, when your mobile roadmap is bottlenecked by API limitations, you have two options. Wait, or get involved. I chose the latter.
I started picking up API contracts from the thinking stage, sitting in on early conversations, learning from the backend engineers around me whilst contributing to how data should be shaped, what endpoints needed to exist, and what the mobile experience actually required from the backend. It meant stepping well outside the traditional mobile engineer lane and into something more fullstack. But it was the right call. The speed at which we could move on native screens improved significantly once I wasn't waiting for contracts to land, I was helping to define them.
That shift changed how I operate as an engineer. It made me a better collaborator, a better systems thinker, and honestly a more valuable contributor to the product as a whole. Mobile stopped being a consumer of decisions made elsewhere and started having a seat at the table where those decisions were being made.
The Foundation We Built
Before we could build great native experiences, we needed to make sure we were building on the right foundations.
One of the earliest and most important decisions was moving away from the inherited codebase and into a monorepo setup powered by Expo. This wasn't just a technical preference, it was a strategic one. A monorepo gave us a single source of truth across platforms, cleaner code sharing, and critically, the ability to scale into new markets. Expanding into a country like Germany, for example, becomes a significantly different conversation when your architecture has been designed with that kind of growth in mind from the start.
From there we were deliberate about every layer of the stack. TanStack Query for data fetching and server state management. MMKV for fast, synchronous local storage. Zustand for client state. Each choice made with longevity and performance in mind, not just what was familiar or convenient.
On the tooling side, we set up EAS for our CI/CD pipeline, giving us reliable, scalable builds and over the air update capabilities.
The goal with all of this wasn't to be clever. It was to build a platform that the team could move fast on, that could grow with the product, and that we'd be proud to hand to whoever came next.
Native Experiences & Real Impact
Architecture decisions only matter if they ship things people feel.
One of the first fully native experiences we built was the basket. On the surface it sounds straightforward, a screen where users review their entries and check out. But the basket sits at the most critical point in the user journey, the moment between intent and conversion. Building it natively gave us full control over the interactions, the animations, the upsell moments. And the results reflected that. We saw a meaningful uplift in conversion that validated the investment in doing it properly.
From there the momentum built. The home screen went native, giving us full control over how users land in the app every single time they open it. The entries screen followed, one of the most visited screens in the app, now fully native and significantly faster. And most recently the house draw page, built on top of our new CMS, which is a landmark moment. It's the first content-driven native screen that proves the infrastructure investment is already paying off.
Beyond conversion, the native experiences we've built have contributed to growth in our monthly active users. When the app feels fast, responsive and intentional, people come back. That's not a coincidence, it's the compounding return on building things the right way.
Some of the most enjoyable work has been around Omaze's content moments. House reveal push notification campaigns, winning code experiences, winner reveal moments. These are emotionally charged touchpoints in the user journey and building them natively means we can do them justice. The anticipation, the timing, the feeling of the moment. WebView can't give you that level of craft. AI assisted tooling has played a part here too, helping us move faster on the implementation side so we can spend more time on the experience itself.
PostHog has been central to how we've approached all of this. We use it well beyond just experimentation. It's our data tracking layer, our feature flagging tool, and our window into how users are actually experiencing the product. Paired with AI assisted analysis, it's how we make informed decisions, validate what we ship, and move with confidence rather than assumption.
Where We Are Now, Still ~70% WebView
A year in and the honest picture is this. We have made real, meaningful progress but the job is far from done.
The native layer has grown significantly. The home screen, the entries screen, the basket, the house draw page. These are not small wins. These are high traffic, high stakes screens that users interact with every time they open the app. Getting them native has had a tangible impact on both the experience and the numbers.
But if you mapped the app today, screen by screen, the way I did before I joined, the majority of what users touch beyond those screens is still WebView. The draw entries selection page. The product landing pages for early bird prizes and the monthly millionaire draw. The charity pages. The winners pages. Most of the internal account screens. These are all still running on web inside the app.
That's not a failure. It's a reflection of where the constraints have been and the order in which we've had to tackle things. You build native where it has the most immediate impact first. You earn the infrastructure to go further. And then you go further.
We're at roughly 70% WebView right now. A year ago it was closer to 95%. The direction is clear. The pace is picking up. And the foundation we've built means the next set of screens will come faster than the first.
The Road Ahead, H2 and App-First
The next chapter is already in motion.
The CMS infrastructure that has been in the works this year is starting to bear fruit. The house draw page, our first fully native content-driven screen built on top of it, recently launched and it's already a marker of what's to come. With that foundation now in place, the pipeline for native screens in H2 is more loaded than it has ever been. What took months to unblock is now a repeatable pattern.
What's also shifted is the thinking at a company level. There is a growing App-first mindset at Omaze, an understanding that the app isn't just a companion to the web experience, it's a product in its own right that deserves to be treated as such. That shift in thinking changes everything. It changes what gets prioritised, how features get specced, and how early mobile is brought into the conversation.
The ambition is 90% native. Some experiences, like checkout, will likely remain a WebView for the foreseeable future and that is a reasonable trade-off. But everything that can be native, should be native. We're not there yet but the path is clearer than it has ever been. The infrastructure is in place, the team is growing, the company is aligned, and the appetite is there.
Expanding into new markets like Germany also becomes a different conversation from here. The monorepo architecture we've built means that scaling across countries isn't a rewrite, it's an extension. That's intentional. That's the payoff of building foundations properly.
The next year is going to be a big one.
Reflection, Growing, Speed & Culture
A year ago I walked into a company with no mobile team, an inherited app, and a lot of ground to cover. What I didn't fully anticipate was how much I'd grow in the process.
The most significant shift has been becoming more fullstack. Mobile engineering at a product company, especially early on, demands it. You can't just sit at the edge of the system and wait for the right conditions to build. You have to understand the whole system, contribute to it, and sometimes help shape it. That's what this year has required and I'm a better engineer for it.
The speed at which we move has also been something I'm proud of. AI automations and tooling have played a big part in that. What used to take days can take hours. What used to take hours can take minutes. That's not hyperbole, it's the reality of building with the right tools in 2026 and leaning into them.
But none of it happens without the right environment. The culture at Omaze is something I didn't take for granted then and don't take for granted now. There's a genuine trust in the people here to take ownership, make magic, grow together and move. That kind of autonomy is rare and it's a multiplier on everything else.
And then there's the team. The engineers, the PMs, the designers. Building is always a team sport and the people around me have made this year what it was. Great ideas, honest feedback, shared standards, and a collective desire to build something worth being proud of.
One year in. A lot done. A lot still to do. And genuinely excited about what comes next.
If you haven't already, you can download the Omaze app on iOS and see the work in action. Would love to know what you think.