So how can we help your business thrive? Well, we are an award-winning digital tech powerhouse, equipped with a wide range of skills such as mobile apps, IOT, chatbots, and complex software development, UX/UI design, digital IT business solutions and more.
We equip our clients with top-notch solutions, guidance and the necessary tools to dominate the ever-changing digital world, always providing innovative and unique solutions.
We are thrilled to see that a few of our clients have left us reviews on Clutch, a B2B ratings, and review firm in Washington, D.C. which connects businesses. Our reviews have given us a 4.9/5.0 star rating and helped us rank also as one of the leading user experience designers in Israel!
We recently worked with Ness Technologies and we provided custom software development and machine learning services.
We kept up excellent communication with the company and always delivered on time!
We also provided iOS and Android development for Fitfully, a virtual shoe size measuring company. The app was able to use a legacy theorem to scan a customer’s foot, produce a 3D model and then connect users with good shoe options.
The app helped the company sign a partnership they had been trying to close for a long time!
We love seeing our clients succeed, so we thought we should share!
In addition to Clutch, we have been featured on The Manifest – a business news site which has ranked us a frontrunner in Israel app development!
You can also find us on Visual Objects, a platform for visual and creative design firms to post their portfolio items and of course, you are invited to visit our highly ranked and reviewed Clutch page.
We want to thank our clients once again for helping us become the award-winning company we are today. If you have any questions or inquiries, please come by our website and get in touch with us, we are here to develop your success.
(or Save precious time and money by avoiding these common mistakes)
Mobile application projects are very popular but tend to show poor success rates. We decided to assist readers by sharing our experience. moblers is a specialized mobile apps development boutique since 2007. We were involved in dozens of applications, hold an install base in excess of 100,000,000, and won global awards. From the position of a market leader, we are able to share insight from our perspective and help you avoid mistakes.
Mistakes are very common when creating something new or as Albert Einstein said: “A person who never made a mistake never tried anything new”. You have plenty “opportunities” to make mistakes so why to repeat the mistakes others already did!?
moblers is in the business of creating new things constantly and we witness many mistakes companies and entrepreneurs make with their mobile apps development. This series of articles deals with common mistakes we experienced in regards to app development.
Having a great service idea with the potential to succeed is still a long way from success. So what is preventing many great companies with excellent ideas to launch successfully!? The short answer is poor planning and problematic execution and these are exactly the 2 categories the mistakes we will cover belong to.
So? What are the mistakes you should avoid?
Because this is an introduction post, I don’t want to delve into any specific mistake which should be covered in a dedicated article. Leaving this post as is would not serve the article. I decided to mention the planning mistakes done by one of the biggest apps today.
So what planning mistakes they made?
They did not clearly understand how to create value for their users
Their targeted market was not focused
Their product did not take into consideration the generated expenses
Their pricing plan did not fit their financial abilities and needs
They changed their pricing often
They maintained several business models and pricing plans depending on OS, geography, and seniority as a user.
This list of mistakes was done by a very successful company that was bought in a multi-billion deal. It is only fair to state that every company makes mistakes while the market and the product evolve. Isolating mistakes in retrospect is easier than pointing them in real time. After stating that, I can finally reveal the app referred to is WhatsApp.
A brief history of the company
Whatsapp was founded in 2009 when the app market started to boom. The company planned to launch a mobile messaging service based on data as an alternative to SMS. Whatsapp has launched:
iPhone in November 2009
Blackberry on January 2010
Symbian on May 2010
Android on August 2010
The app started as free, then became a premium on the AppStore. The app then introduced the first year free and annual fee (Android) that was never truly enforced. In January 2016, it was announced that WhatsApp will be free and remain free.
Below is a short explanation on some of these mistakes
Product and audience related mistake
The biggest and most fundamental mistake WhatsApp made was by not understanding completely the essence of the service and the audience. A messaging service worth to a user inherently correlates to the number of connected peers the user has that use the service. A messaging service must remove all barriers to get critical masses in social circles and dominate them. Only a large number of users within a specific social circle makes the service more attractive to potentially targeted users. WhatsApp did “chase” the platform support goal expanding their OS support in the first year. It seems like they pushed towards wide growth rather than a targeted higher value growth. Their strategy did not address the critical mass requirement of services with such a nature. Their focus had to include the critical mass factor and make sure their product and go-to-market strategy corresponds with that. They charged for the service which is a big barrier and they had no segmentation to concentrate their efforts on. There are many ways a company which acknowledges such an important factor in its service can take to keep its growth and they took none of them. The chart below demonstrates that the actual user burst occurred in mid-2013. At that time, their Android user base was already significant and they changed their pricing model on iOS as well. The growth of their user base is very impressive but it is clear they take off only around year 3 (they hit 200M users in April 2013).
By removing the pricing barrier WhatsApp was able to hit a critical mass, grow and fulfill its potential
Expenses derived from product definition and market segmentation
WhatsApp plan was to verify users using SMS, to send invitations through SMS and to target the global market. Users could request many verification messages with every installation. Users could chat with unregistered users via SMS on WhatsApp’s expense. Global market (as discussed before critical mass) requires increased expenses to generate value. The company miscalculated expenses derived from these decisions and fell into a vicious cycle that generated more mistakes. The company changed its pricing selectively, made changes to the product, and modified its relations with partners. They had a series of patches and “features” that were aimed to counter the bad effect of earlier decisions. The company needed to deal with a lot of SMS messages their service produced.
There are some easy ways the company could control its expenses. They could use premium SMS to charge for verification messages. This step would have required them to adjust the product and work with local providers. To deal with the endless number of outbound messages (invitations and cross chat) they could alter the way they deal with registered users. Users could get a limited amount of messages to external users. Other creative ways even include a local premium short code that is used by unregistered users to respond and covers the service costs. The company could even send messages to unregistered users who used the premium service informing them about the free service. The people at WhatsApp worked on deals with operators, they must have read articles about premium SMS perception at the time. Every research showed that because the charging is covered with other costs in the phone bill, users tend to overlook and dismiss these costs. They could also cut deals with the operators to send SMS through their gateways for a fixed price. There were many good ways to deal with the challenges of a messaging service in 2010, but WhatsApp failed to choose one good solution. The steps the company took were uneven, unjust, had no correlation with actual user’s generated costs etc. With attention to potential generated costs by their service in the definition phase, they could find much better ways to deal with the expenses. Ultimately, they could better define the product and choose specific initial markets to generate fewer expenses and more value faster.
Confused pricing (evolution) mistake
From the brief history mentioned above, you can learn that WhatsApp was very unstable with its pricing model. They started with a free version that turned into a premium one on iPhone. Android users got the application for free until the company decided new users will pay an annual fee from the second year. Users from developing countries were not charged at all. iPhone then turned to free for the first year and an annual fee from the second year like Android users. iPhone users were accustomed to premium apps and Android users were not, but does that mean that they should charge only from iPhone users!? From a simple search in Google, you can find many confused discussions about their pricing. People published ways to “hack” the application and get it for free. These discussions happened when the application was already attractive to users but they did not want to pay for it while others do not. This behavior demonstrates that users who needed to pay for their service felt exploited because they knew other users do not pay for the service. The inconsistent pricing model hindered WhatsApp’s growth but also damaged the users’ perception of the service. Users felt the company tried to charge them for something they know others got for free.
This is what happened when WhatsApp started to fix some of the mistakes it made and removed barriers
And yet…
I intentionally chose to present the case of a very successful company like WhatsApp. The WhatsApp management was able to recognize mistakes it made and constantly adjust their product and offering. They attempted to overcome the issues and to try and fix these mistakes. There are many factors in the success of WhatsApp but from the angle of this article, the adaptive nature of the company was key. A good dedicated team of professionals that constantly reevaluate the product and the market transformed a service that suffered from big mistakes to succeed.
From ancient Greece to mobile product planning , the issue lingers. A fundamental requirement in the planning process of a mobile product is to know your product. This is a philosophical question in its essence; quite similar to “know yourself” which is an ever-lasting always evolving process. Putting the philosophical aspects aside, the clearer you see your product, your core, your differentiation, and your positioning, the better chance you have to attract users and become successful.
Knowing your product serves:
Your product – it is a mature product with less distractions
Your project – the project becomes easier to manage once the product is clear
Your time – with less uncertainty and last minute realizations, the shorter time it takes until your product hits the market
Your financials – a well thought and well specified product costs less to develop and is less likely to cause costly surprises
Your potential customers – they get a service they know what to do with that answers a need they have
Short recap
If you haven’t read the previous article, Tagged is an imaginary start-up to showcase the points covered by the series of these articles by mobers. Tagged service is next gen electronics and appliances insurance service. You get a quick price quote based on the devices you own, and when time comes you get an instant fixing or replacement service.
The imaginary product definition meeting
Because Tagged is an imaginary start-up, let’s assume we had an imaginary product definition meeting. The experienced team immediately started to bring up ideas to make our service one that will make an impact. We want to simplify the process, to streamline the user through the initial acquisition with no keys pressed. The user will also be able to get a real-time indication to where nearby service providers are located, to track the progress on devices they sent for fixing, and so on. Less than an hour in the meeting we already wanted real-time video processing to identify which devices need to be included, an automated scan of device and model (OCR), location based service, ticketing system with real-time tracking including GIS, and more.
The imaginary team of the imaginary start-up Tagged is obviously very knowledgeable about technologies and industry standards but the one hour meeting could eventually cost the company about 4 times the price of the actual product we need to launch with many potential pitfalls, hurdles, and time spent.
Do we really need this!?
If the product path is clear, we can easily clean all the clutter and see that our product is not about the automatic acquisition and automated pricing process. We are also not in the service ticket and item tracking business as well. The decisions about the MVP (minimum viable product) will be discussed on another article but the mindset is already demonstrated in this paragraph. If we maintain our focus on the essence of the service we can weed out many “nice to have” features that somehow get communicated by mistake as “must have” requirements. Our initial product can require people to manually choose devices and models to get the price quote and based on our mandatory SLA we can inform customers with a timer the latest date on which they should get their device fixed. We do not really need to implement the video acquisition and processing, the OCR, the GIS, the ticket tracking mechanism etc.
It was done before
I am sure the software wizards at Tagged could do a great job but there are companies who specialize in specific products and technologies and offer off the shelf services, libraries and API for many functionalities. There are OCR libraries, GIS components, and many other elements we specified that were developed and also are being maintained by specializing companies and groups. Our engineers will never be able to perform their Tagged related tasks, and still produce better results than products that are owned by specialized companies. It is not just a matter of ability but more of a price performance ratio. We do not want to specialize in OCR and we are not able to capitalize on the potential revenues from this development so no reason to put our efforts in that direction. This is obviously just an example that shows how easy it is to avoid complex projects being tangled by taking too many tasks and challenges that are not mandatory to our solution.
Know your competition
You can utilize the information you collect on your competition to better understand what your focus should be and therefore better identifying your core value and the core of your product. Nevertheless, remember, if your competition targets the same market with a similar approach, your product should resemble in some ways their product. You should be able to distinguish your product from theirs and you should have your own “angle” but the majority of the core elements will probably be very close. This can be used as a test because in most cases if your core product seems to be doing the same things (maybe differently) than what your competition does, your core is relevant to the market. That is a very important statement to be able to say about a product in its planning phase.
Manage priorities
Prioritization of elements in your product is also a valuable tool to distinguish between your core and your features. Your core can never be prioritized as something else than must have. If you remove from your initial product everything that is not must have, you are very close to release a coherent clear product that involves less risk. In order to reduce risk in implementation, make sure in the prioritization process you dedicate a column per each element or feature to the risks and costs (resource based) involved. The risks will assist you to plan ahead and overcome potential challenges that may rise.
The enlightenment
Becoming featureless means you do not develop or maintain features. At the early stages of your product, features carry with them risks and costs and also distract you from perfecting your core service or product. The essence of your service is your core, it is not comprised of features, this is your engine this is one unit that is crucial for your goal. The challenge is to truly identify what this core is for your company / product. When you concentrate on only building this unit you do not burden yourself caring about features and you become featureless which is as close to product enlightenment as possible. You are required to leave the emotional sentiments aside and really strip your product to its bare bones in order to achieve this state.
The guidelines to become featureless
This is not easy to do but I will try to provide a list of steps that can be used to remove features and become featureless.
Bring perspective to your product specification meetings. The addition of business development professionals, financial professionals and other perspective less directly connected to the product will probably challenge your perception and assist you to reduce less important features.
Ask yourself what your people do the best. Your product should be within these strengths or you should rehire.
Ask yourself what happens if you remove each feature, if the system cannot work without it, this is not a feature it is part of your core.
Make a research on existing solutions that can be used in your product. If you find companies that offer these abilities and are not direct competitors, good chance these are features and that you should not spend resources developing them.
Make a weekly or even bi-weekly assessment of feature list and prioritization. Remove every feature that is not must have. Don’t worry, if you made a mistake and removed a crucial part, it will reappear very soon.
Try to make the “technology free” version of the service that provides the same value to your customers (minus the efficiency or other aspects that were achieved through the use of technology). Your product definition should correspond directly with the offline version. In most cases everything that is not aligned with the offline version is a feature.
Our innovation team at moblers is very skilled in isolating products and find the essence of the product. We are good at it because we have done it dozens of times with many customers and many products. With time, we became more aware of standard distractions and leeching features and with each new project we handle, we improve this ability.
Hello world is usually the first application developers code in a new language they learn. When it comes to choosing your audience, hello world actually means the death of your project in most cases. Targeting the WORLD has its costs and challenges that are usually too big for any new project to handle.
Several years ago I was invited to lecture to mobile operator employees about innovation in the mobile market. I asked the HR manager about the background of the participants and I was told they are engineers from the R&D department. The lecture I prepared focused on the future of mobile technologies, devices, peripherals, connectivity, proximity, content, and the role of these technologies to enable new mobile services. Long story short, I never used the lecture I worked on because the participants were the CRM and billing engineers of the company. Needless to say this is not the audience to hear the lecture I prepared. I had to transform the lecture to an open discussion about future challenges of mobile operators’ IT departments. Of course you do not need me to tell you to make sure your service has an audience and that it fits its needs. When planning a mobile service the definition of adjusting your service to the relevant audience has a much broader impact than just its relevance. The decision on the service audience has a direct impact on expenses, operations, technological challenges, and other aspects. Based on the targeted audience, you are required to choose the product specification, the supported OS, the devices, the geography etc.
Working on strategy and innovation at moblers, my work is basically to incubate new projects and to meet potential clients and partners. I don’t use a reference handbook but there are questions I ask every company I meet with in order to get the feel of the market, of the service, and of the team. So when I ask them about their initial targeted audience I hear too many times the answer “global, everybody needs our service”. If I care about the company and the team, I recommend them to read this book:
(source: http://orig13.deviantart.net)
It is good to have big dreams and I really wish everybody I meet with that their dreams come true but unless you have unlimited resources, you should make sure you target an audience you can actually support and provide good value to. This is the essence of this article and although it seems trivial, many companies are tempted to feel they are so good, they don’t need to focus.
In order to demonstrate the mistakes companies make in choosing their audience, I bring you “Tagged”. Tagged is the imaginary start-up I created for this article. Our product is simple, use our app and your smartphone camera to “tag” every home appliance and consumer electronics you own. You get a detailed list of your devices and the price we charge to insure them. This is not the standard theft or fire insurance but a supplementary service of fixing electric malfunction. We work with local technicians who registered with us and they fix the devices in accordance to a simple clear SLA.
Basically, “Tagged” audience is huge, do you know anyone who doesn’t have any devices!? So before we do the mistake and state that we want to target everybody, here are some points to consider.
Your service is only a list of features based on assumptions and some research. Yes, I am sure many of your friends, your family, and even people you asked on the street told you great stuff about your planned service. You never know what your service should be until you actually have a product and you test it in the market. The kind of feedback you get from actual users who actually use your service is the only real feedback that you need in order to shape your product.
Is the cost of insurance (the cost of fixing * statistical probability of malfunction + your fee) the same on a global perspective?
Is it a cultural property to insure home appliances and consumer electronics? Is it a cultural tendency to fix rather than buy new products?
What is the capacity you can handle of the listed service providers? (you need to verify all is working well)
Can you enforce the SLA which is the way YOUR clients are treated by the service provider?
[If your audience only virtually “with you” on your product, their feedback has only virtual worth to your product.] (image from: http://cl.jroo.me)
The list of questions gets longer the more you truly think about the viability of such a wide audience. The answers should aid you in getting your real initial target audience which in most cases should be very small and very relevant.
Concept vs. real product
Because your product is likely to change (a lot) after its launch, managing a complex project of continuous development for iOS and Android is very problematic. The better options you should take are either develop the application on a hybrid framework to get the mvp to the market or choose one OS to start with. [Wait, don’t say that you need it to be slick and on both OS, we are not talking about your final product. One thing I can advise you is to stabilize the product and only then with that perspective implement your final product the way you want. Your product will be a patchwork and managing the project with two unstable versions and feature lists will always be more expensive and more risky]. The choice between Hybrid or just one OS is based on your product and your audience’s demographics. In the case of Tagged, the choice will probably be a hybrid app because we do need to work with both OS and we do not need features that will be problematic to implement. The audience is not young users (they don’t own the devices) so there is no need to have rich graphical user interface or the quick response they are used to.
Get feedback
Your audience should be the type of audience that can provide you with significant honest and prompt response. You want the audience to be almost a captive audience, the kind that needs your product and feels dedicated to assist you with insight and suggestions. In the case of Tagged, it is logical to get an audience where Tagged personnel can access by car in order to monitor or assist when relevant.
[make sure your initial audience stays with you and provides you with feedback] (image from: http://captionwit.com/ )
Learn from Icarus
Make sure you expose your initial immature product to audience that will not have a dramatic impact on your reputation. The initial audience is the sand box in which you test your assumptions so make sure they don’t “burn” your name and influence your potential growth with the mature product. Tagged, as an example, should address a local suburban area and make sure there are no residents who are close to the subject and may have access to significant media exposure.
Be cautious
Choose an accessible audience and market that you can easily help or fill the gaps for in time of need. Your product and your procedures get tested for the first time and are most likely to experience difficulties so choose an audience that lets you monitor these situations and fix them. Be with your audience when things break and have the resources, the creativity, and the agility to assure things still operate. Tagged, for example, needs to be launched in a place where there are enough technicians or even Tagged own technician can easily assist if needed. Tagged also needs to be able to change servers easily and get support in Tagged office hours so the audience should be in a close timezone for instance. There are more byproducts to this direction but I hope you got the idea.
Allow yourself to improvise
This is very general and dependent on your type of service but it fits most services. You need to be able to have alternatives for components in your product. Choose the audience that uses the service in an ecosystem that is familiar to you. Tagged for example needs to operate in a place its management knows of electricity technicians, insurance companies, investors, and device models in order to be able to alternate resources and evolve according to the feedback.
The summarized advice
The above points are summarized only to make them more accessible to readers but there is a lot more to say about each of them and many more elements that should direct towards the right audience. Every influencing factor you consider will serve you in isolating the targeted audience you should approach. There are many companies who only use a single factor of product relevance but they usually suffer from the lack of planning when they need to face the outcome of the lack of focus. Make sure you think thoroughly about your targeted audience and choose exactly the kind of audience that fits your service and your circumstances. You will find that the right choice can really be the difference between failure and success.
Knowing your audience in the planning phase provides you with valuable input to the process and allows you to plan effectively. Follow the next article in the series to avoid another common mistake many companies and entrepreneurs do with mobile apps development.
You’ve got yourself a pretty good idea. You’ve even drawn wireframes and have your idea documented on paper. You’ve written your functional needs, and now you want to step up and develop your app for Android, iOS and the Web. You approach your favorite app development studios and request a quote, but the prices are way over your small budget…
What do you do then?
First-time app entrepreneurs generally do not understand how long and difficult it is to develop a working product, with its millions of features, and have it developed for all platforms.
MVP Your App
Before you overload your app with a lot of features, think only about the core features to start with. Most features are not necessary in the beginning. The only thing necessary at first is your core idea because you don’t have users yet. Once you do get a few users, you do not want them to get lost but to have a clear interaction with your service. Also, features should be thought of and designed to meet the users’ demands, so you have to have at least some users to start with.
Get Your App Working on ONE Platform First
Choose only one platform to start with! This way, you can not only decrease your quote but also learn from your users and fine tune and change your app as users’ demands change. This will also allow you to determine if your service is working the way you thought of spending more money.
Summary
By implementing the suggested points, you can decrease your app quote and have it developed on a smaller budget than you were initially quoted and start your journey to success sooner. Also, if your app is successful, you will have a better chance of attracting investors to fund the next steps.
When developing an app, there are lot’s of decisions you’ll need to consider, including those regarding the design, UX, look and feel, functionality, and navigation. There are also technical decisions to consider such as which APIs to use, third-party components, server-side decisions and whether the app should be developed in a multi-platform environment or to use native code. The answers to these questions will have an impact on the cost, functionality, and performance of your app. Therefore, it is worthwhile to look at the pros and cons of each option.
In this article, I’ll be focusing only on the client side decision for developing environment.
As a mobile studio owner, I work with a range of companies, including start-ups, so I have a good understanding of the importance of the budget. I strive to develop the best possible solutions for our clients for the lowest possible price. Apps built in multi-platform development environments cost less, while native options cost more. Let’s a take a deeper look at the two options beyond cost.
What Is Multi-Platform Development?
Most businesses and organizations want their app developed on the major platforms – To achieve this while also reducing development time and costs, we can use multi-platform development tools so we can develop once for all platforms such as:
• PhoneGap
• Fuze
• Codenameone
• Xamarin
And many more …
The Case for Native Apps
Native apps are developed for each platform separately aka Android, IOS, Windows phone. So they cost more of course.
One of the downsides of using a multi-platform development environment is that these environments have to compromise on other areas in order to ensure their service is functional. These compromises make it harder – and sometimes impossible – to create complex apps, or apps that incorporate a lot of internal APIs.
Another downside is the lack of support for all third-party components and libraries. The effect of this is either to restrict the functionality of the app or increase the cost of development. There is also a reliability concern. Working with the native platforms means working with Google and Apple directly, so there is a significant community of developers and comprehensive support provided. No multi-platform environment can match this.
Should You Choose A Multi-Platform Development Environment or Native?
In most cases, I use the following rules:
Smaller, uncomplicated or demo apps can be developed in a multi-platform environment. This will save money and will have little (usually zero) impact on functionality and performance.
Larger, more complex apps should be developed using native code to ensure proper functionality, good user experience, and optimum performance. The initial cost of the development is likely to be higher, but it makes more sense in the long run. Anyway I always advise my clients to test and release the app on one platform before developing it on another.
You should always discuss the decision with your developer studio since they will be in a position to determine which option best suits your needs.
