When do you go native?

So you’re a startup founder. Or you’re in charge of a new project at a big company. (Or maybe you just imagine being either of these things.) And you suddenly realize: you have to make a whole slew of massive decisions right now, based on imperfect information, which will reverberate for months or years, and […]

So you’re a startup founder. Or you’re in charge of a new project at a big company. (Or maybe you just imagine being either of these things.) And you suddenly realize: you have to make a whole slew of massive decisions right now, based on imperfect information, which will reverberate for months or years, and may spell the difference between success or failure.

Among the most dreaded and dangerous decisions are the technical ones. Your web stack. Your cloud provider. Your datastore. But it’s fair to say that the most contentious, lately, is for projects which involve a smartphone app. There, the biggest question of all, the one which must be answered before any work is done, and the one which will probably hang over you for years, is: do you go native?

What that means is: do you build separate native Android and iOS apps, each from scratch in a native language, almost certainly meaning two development teams? Or do you use one of the many tools which promise you two apps for the price of one?

You can of course just build one app at at time. That makes sense if iterating swiftly to product-market fit is more important than doubling your initial addressable market. But if you do so with a native app, be aware you’re implicitly deciding to have two development teams, and two separate and out-of-sync codebases to maintain, somewhere down the road.

Choose your technologies (and your developers) wisely, and you will be able to move deftly, hire (relatively) easily, iterate quickly, and pivot gracefully. Choose poorly, and you’ll be burdened with technical debt that weighs you down until you’re barely able to fix bugs, much less roll out new features.

Speed matters. Cost matters. The long-term benefits of a single codebase are obvious — as are the costs of subpar apps which wind up costing far more than your initial gains. You could conceivably be betting your whole company on this decision. So what’s the right answer?

This is a decision I see a lot. For context, I’m the CTO of HappyFunCorp, and we wrestle with this decision multiple times a year, as we design and architect new apps for clients, or do major overhauls or existing ones. So I can tell you with great confidence that the answer is: “It depends.”

Data & News supplied by www.cloudquote.io
Stock quotes supplied by Barchart
Quotes delayed at least 20 minutes.
By accessing this page, you agree to the following
Privacy Policy and Terms and Conditions.