When I entered the company, there was a project that a colleague started earlier that year. Let me explain the technical and non technical way (pick the one you prefer):

The technical background

Our company wanted to develop a mobile app, and an external consultant suggested to use Cordova/Phonegap, as he used it as his main tool. This would allow the "code once, run everywhere" premise and have it running in Android and iOS, but time has determined it takes more time to tune apps than the expected.

Also, our boss complains about responsiveness issues (like clicks not triggering, or screen being frozen for a while) and issues that are tied to Cordova compatibility issues between different devices.

I'm a fervent supporter of native apps, as you skip one extra layer (the WebView one) and lets you make every app specifically well designed for each platform. It doubles the work, but exclusive features and design patterns specific to every platform makes it a good decision in terms of user interfaces.

The non technical background

Our company wants to deliver an app made in a really generic technology. This decision was taken because our boss was told that technology would reduce costs if we delivered it to Android and iOS. However, after some time using it, I have seen it's not that magical, and in fact requires more time making it "not break" in every single phone we try, rather than making the app itself.

I, of course, prefer to use another technology, more specific to each platform. It, in that case, obligues you to do one different app per platform, so the costs of changing it will increase at last, but the benefits of it may be pretty good. Each platform (Android and iOS) has its own features the app could take advantadge of, only truly available and accessible through its own specific technology.

The conclusion

Moving from what's currently being used to my preference is quite a problem, as it could possibly be seen as a not decisive thing to do. However, non of our competitors is using our company approach. They have better ratings (though I have to say ours are pretty good, but we still fall behind them), and complains to our app are always about issues related to this technology limitations that could be pretty well surpassed with another, more specific, solution.

Plus, I see that when I talk about this to the designer, he admits the app is not well fitted and should be redone from scratch, and my coordinator accepts this may be a good solution, but when I want to talk about this to my boss, the designer tries to hold the change back, and the coordinator says it's not business critical and would not give any higher income, so I still haven't openly talked about this to my boss (which lastly decides this).

I've previously demonstrated I'm proficient in my approach, and actually have been a consultant for quite a long time in this company, until the previous developer was fired for, actually, confronting my boss and making him see this couldn't go any better with our current approach. Screams and reprovals, and a week later he was asked to leave straightaway.

I fear this may happen to me as well, but I also fear this technology burns me out (it's pretty stressful to make things work in every device, individually), and still my boss can't see he took a decision without thinking the benefits of other choices.

This decision may obligue my boss hiring another developer (as I'm only proficient in one of the platforms), and it may take up to half a year to develop each app (quite the same time that took my colleague to develop the current state), so it's all about money and time, as always.

This kind of decision, that may change the path of a whole project, after it's almost finished, is a pretty tough decision, and looks like I'm half alone in this. So how to make your boss see a huge, non-profitable change may increase the ratings and profit in long term?

closed as primarily opinion-based by Jim G., gnat, Jan Doggen, IDrinkandIKnowThings, Garrison Neely Oct 9 '14 at 14:18

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.


I do full stack Javascript, which allows me to skip the issues that your company is running into :) Having said that:

  • The external consultant suggested Phonegap, but as you are experiencing, Phonegap has limitations that force you into doing quite a bit of resource consuming customization, with time as the biggest resource consumed followed by money and people-hours.

  • The native app approach has its own drawbacks where you need to develop and customize for each platform separately. If you go Phonegap, you have to compromise. Ditto if you go native. Otherwise, nothing gets built.

The decision which way to go is no longer a technical decision but a business decision. A business decision that accepts that whichever approach is used, necessary compromises must be made in the interest of getting the product to market quickly. Because if it doesn't get to market quickly, it has a good chance of getting killed and your firm along with it, if it's a startup.

You try to rationalize your approach on business grounds - that's good because arguing with management on purely technical grounds is most likely a nonstarter. Unfortunately, your knowledge of the business grounds is skimpy and sketchy as you don't have all the facts in hand including the resources available to the firm.

Your management is the one that has all the facts and who therefore must make the decision. They will have to live with their decision and if things go South, go down with it. At this point, they may already be in too deep to change their approach.

I do agree with you that if users find that their experience with the product sucks, an unpleasant denouement is at hand. At the hands of the customers. You usually don't get a second chance at a charging rhino with just one bullet in the barrel.

  • +1 For emphasizing this as a business decision. Most people who want to develop mobile apps in the native code aren't the ones writing the checks. – user8365 Oct 7 '14 at 12:41
  • Nice metaphor for dealing with customers. I'd prefer to see this as an app reboot, since we're already online, with thousands of clients. So, my option at last is just introducing this as a feature to think about, and hope for the best? – Korcholis Oct 7 '14 at 12:48
  • @korcholis Question is, does management have the time and resources to execute the reboot that you are advocating, and if they do, would the time and resources be better allocated to making the existing approach work? :) It's a judgement call and again,management has to be the one make it for better or for worse. – Vietnhi Phuvan Oct 7 '14 at 14:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.