Bohdan Marchuk helped build a mobile payment and loyalty platform serving 500,000+ users across 8 countries. Here, he explains what separates architecture that scales from architecture that quietly collapses, and what to do differently before the damage becomes permanent.
In February 2026, a new industry report valued the global mobile payment technologies market at $269.3 billion. It is projected to surpass $993 billion by 2033, growing at a 20.5% annual rate. Behind that expansion lies a harder problem that the numbers don’t capture. Most mobile payment platforms built for one market quietly fail when scaled to five, ten, or fourteen.
Bohdan Marchuk, Board Member at Boring Owl and Senior iOS Engineer, has spent twelve years on the right side of that gap, the distance between building a platform that works and building one that keeps working across every market it enters. He has built systems where failure is not an option, payment platforms processing transactions for over 500,000 monthly users across 8 countries and 2,700+ locations, fleet management for commercial operators, and a telehealth platform adopted by pharmaceutical companies in the UAE.
The mobile payment architecture he helped engineer for a major Fortune 500 convenience retail corporation earned the NACS European Convenience Retail Technology Award in 2021. It was the first recognition of its kind in Europe for license plate recognition payment technology.
Beyond engineering, Bohdan Marchuk has conducted over 30 independent architecture reviews. His work spans fintech startups and luxury real estate developers. In several cases, he served as the sole technical evaluator for investment decisions involving millions.
That field experience now extends into a broader body of work. His book, Building iOS Apps for Global Markets: A Practitioner’s Guide to Enterprise Mobile Development, is available on Amazon. He is a Council Member of AITEX, the Association of Information Technology Experts, California, a selective body whose membership includes experts from Google, Microsoft, Meta, and Amazon, admitted through demonstrated excellence and Expert Committee approval. He holds a Fellowship with Hackathon Raptors and serves as a judge at the AITEX Summit Winter 2026.
We spoke with him about what enterprise mobile architecture actually demands, why most pre-launch audits find the same broken patterns, and where the iOS development industry’s knowledge gap is costing companies the most.
Bohdan, a global enterprise mobile scales fast, but most platforms stall at international deployment. You architected a payment and loyalty platform that successfully operated across 8 countries and 2,700+ locations, reaching 500,000+ monthly active users. How do you actually hold speed and structural integrity at the same time when the stakes are that high?
The answer is that you don’t hold them at the same time; you sequence them correctly. Speed in the wrong layer kills you. Speed in the right layer is exactly what you want. The mistake I see constantly is teams optimizing for delivery speed at the architecture layer. They make structural shortcuts because it gets the feature out faster, and those shortcuts feel invisible until scale exposes them. By then, the cost of fixing them is five times what it would have been upfront.
What we did on the payment platform was spend significantly more time than we felt comfortable designing the core architecture before writing product code. Payment flow abstraction, regulatory configurability per market, loyalty module independence- those decisions took weeks of debate before a single screen was built. And because of that, when we moved into new markets, we were configuring systems, not rebuilding them.
You’ve completed over 30 architecture reviews, serving as the sole technical evaluator on investment decisions where your findings directly determined whether capital got deployed. In those reviews, you’re opening up systems that real businesses depend on. At what point in a product’s lifecycle does that damage become irreversible?
Almost every time, I find business logic living inside the UI layer. Controllers are doing things they have no business doing. Payment validation embedded in views. The app runs, the demo works, but try changing anything structural, and everything’s connected to everything else. It happens because of delivery pressure, not incompetence. Teams under sprint timelines make fast choices. The problem is, mobile systems age badly when built this way.
The point of no return is usually the first major third-party API deprecation. One external change suddenly requires touching fifteen places simultaneously. I’ve watched that cost companies eight months on a two-week integration. At that point, you’re not fixing, you’re deciding whether to rebuild or absorb permanent drag.
You restructured the client portfolio at Boring Owl so that five clients now generate the same revenue that previously required nineteen, and you increased average contract value by 3.8x. From the outside, that looks like a business decision. But you came in as the technical leader. What was actually happening on the engineering side that made those numbers possible?
The business result came from a technical diagnosis. The company had strong engineering capability deployed on work that didn’t reward it, small contracts, limited scope, and constant context switching. They could build enterprise-grade systems, but were spending capacity on projects where none of that capability was visible or valued.
When you’re running eighteen or nineteen clients simultaneously, the overhead alone becomes the work. Every engagement carries the same fixed costs, onboarding, handoffs, integration testing, and smaller contracts don’t have the margin to absorb them. The shift was a positioning decision backed by technical evidence. I documented where the capability actually sat and what clients would recognize and pay for it. Then we stopped competing for work that didn’t fit. The 3.8x increase wasn’t charging more; it was stopping underselling.
Every company publishes case studies about scale and performance. But your work spans healthcare in the UAE, fleet management in 8 countries, BlueAir IoT accessibility, and iSing, one of the leading karaoke applications in Poland. When the client brief changes dramatically across genuinely different problem domains, what stays constant, and what does that reveal about what enterprise mobile actually is at its core?
The domain changes completely. Healthcare, payments, fleet management, different users, regulations, and failure consequences. A missed notification in healthcare has clinical implications. A failed transaction has immediate financial consequences. But here’s what stays constant: the relationship between data consistency and user trust. The moment a user sees information they don’t believe, a balance that seems wrong, a status that doesn’t reflect reality, the app loses. Not that session or the relationship. People don’t debug apps. They uninstall and leave reviews. So enterprise mobile, regardless of domain, is making distributed systems feel locally reliable. Your job is to make clients behave as though they have complete information when they never fully do.
The iOS development community has no shortage of resources, tutorials, documentation, and courses built by experienced engineers. Yet most enterprise systems you review were built by those same experienced engineers, and they still got it wrong. What is the question mainstream iOS content never asks?
Most iOS content teaches you how to build something that works once, in controlled conditions. That’s useful, but very different from enterprise reality. Tutorials focus on creation, not consequence, what happens when your system is live across countries, APIs deprecate, OS updates break flows, and changes risk regressions.
The question mainstream content misses is: how does this decision behave at failure? What happens when the network drops mid-transaction in markets with inconsistent infrastructure? These have architectural answers, designed in, not bolted on. I wrote the book because most struggling systems weren’t built by bad engineers; they were built with the wrong frame. This fills that gap.
As a judge at AITEX Summit Winter 2026, you evaluate technical submissions from teams building under real enterprise constraints. What qualities genuinely impress you, and what signals immediately that a team is building theater instead of substance?
What impresses me is evidence that the team thought about failure before it happened. Not just defensive code, but architectural choices that show they asked, what breaks when volume doubles? You see it in module boundaries, dependency management, and choosing harder patterns early. What signals theater is a system built for the demo path. Happy path is perfect, but error handling and retries are weak. Data assumptions fail in real conditions. The other red flag is documentation that explains what, not why. If tradeoffs aren’t clear, the architecture wasn’t deliberate.
You’re opening Boring Owl’s Chicago office with a US team, bringing European enterprise mobile experience into a competitive, relationship-driven market. What’s the real challenge, and how does that experience translate when the client is sitting in Chicago?
The technical side translates more directly than people expect. Multi-state US complexity mirrors what we handled across European markets. Payment integrations, architectural depth, it’s all structurally similar. What’s different is trust-building. In Europe, credibility comes from shipped systems and measurable results. In the US, clients look earlier for signals, thought leadership, affiliations, and proof that you understand their space. That’s where published work, institutional affiliations, and judging roles compress that trust gap; they signal credibility before a single reference call happens. The challenge isn’t engineering. It’s making proven work legible to a new market that hasn’t seen it yet.
