Latest information from the mobile development industry. Analytics, reviews, forecasts and even more.
Background color
Background image
Border Color
Font Type
Font Size
  • Software Estimates: Minimum Viable Product Jul 6, 2016

    All inspired entrepreneurs, who want to create a mobile startup, always have ideas, many ideas at the earliest stages, twice as many during the development. It's vital to structure these ideas and it's quite logical that every project starts with defining cost and delivery deadlines; in other words, with an estimate. The entire project must be divided into smaller blocks, until each block is understandable and can be evaluated.

    To see the full article please visit
  • 5 Things You Should Know About Healthcare App Development Feb 3, 2015


    There are certain peculiarities that unite all apps related to the healthcare industry. These peculiarities define the development process and ensure the quality of the outcome. If you are busy in this industry, you know the rules of the game. Demands as for quality vary from very high (conventional health & fitness apps) to exceptionally high (software for internal use at medical institutions). Here are 5 rules that play the most significant role by development for healthcare.

    #1. You need to pay special attention to the quality of your software, and demand this quality from your development team.

    The industry has exceptional requirements for the precision of data and measurements. Even if your MVP is the smallest fitness tracker. People spend plenty of time with their personal mobile devices; interactions with apps have to be seamless, otherwise they'll abandon it. Here it doesn't matter how often the software is used. If it has quality, value, and convenience in the first place, it runs very low risks of getting erased from a person's smartphone.

    #2. The interface has to be easily understandable, user-friendly and intuitive at first touch. The risks of a user not finding and/or accessing the needed information or feature must be at an absolute minimum.

    For example, this is essential for internal apps for patient care. It's all about precision and automation, while any piece of data can be requested immediately. In healthcare time is vital in every sense of the word. It can be up to building a complex system with different levels of authorization among hospital staff, and plenty of hospitals utilize such software.

    #3. Users of healthcare apps may not be active mobile users in the first place. That's why it's reasonable to minimize and simplify complex logic.

    For example, you may be interesting in creating an app for health insurance management. There are hospitals and other required health establishments to search for on the map, scheduling within the app and a place to store contacts, pharmacies and hospitals. There's insurance management itself: tracking expenses using invoices or changing the insurance program. Or maybe your users are interested in various health-related events that are dedicated to particular problems? You know the system perfectly, but there is always room for optimization of logic. This is where the help of a great UX/UI designer is invaluable. Whatever your core set of features is, it works well only when combined with the knowledge of UI guidelines for every mobile platform you want to cover.

    #4. There is also huge competition on the health & fitness market. Relevance of data and visual attraction are vital as well.

    What's good about the health & fitness market is that you can rather easily identify the target audience. You can identify their exact needs and give them the product they are looking for. That's a narrow niche. At least, it's way more narrow than social networks, which gather together people of completely different interests, countries, and mindsets. Fitness fans are more predictable: their habits, evident goals, and attitudes. Your designer will help you make your app a distinguished, preferable, and obvious choice.

    #5. Security is the key. The confidentiality of private health data equals that of financial information.

    Such software is obliged to meet HIPAA security standards in the first place. It has to be built to prevent any leaks of private information: patient profiles and histories, visits and scheduled examinations, treatment details and prescriptions, requests and forms, and any data stored in medical apps. Trying to cut costs where possible obviously doesn't work for healthcare. You'll need a custom backend to contain business logic and databases that you'll have complete control over.

    Since our team has been into healthcare development for quite a time, we are confident that sticking to these five rules really helps maintain your product at an all-time high. Great tools enhance the industry and work for its users, thus working for software owners. Whatever your particular branch, whatever your product is, we believe that our experience in combination with your knowledge in the subject matter is a perfect foundation for a product of high quality. Feel free tocontact us with any further questions.
  • What Are The Pitfalls Of Bad App Architecture? Jan 29, 2015


    Most of the time it's design and user experience that receive most of the attention when it comes to mobile apps. Cool designs, trend of flatness, content-is-king, and all similar things overshadow the architecture-related issues, which are nonetheless crucial for the end result.

    App architecture is a high-level structure of the whole software system and code; it contains elements of the system and their correlations, and it's designed for easy scaling and improvement of the software code. When expectations of users rise and they become more and more demanding, it's not only visual design that requires highlighting. After all, it's the 'user-invisible' part that your software is based on. If costs and efforts get cut, what does it mean for software?

    It Means Poor Security

    If we put the human factor aside, it's architectural vulnerabilities that stand behind a huge number of security breaches that happened over the last couple of years. This means bad architectural decisions were taken by people who have probably the biggest influence on the inherent security of software. Afterwards, fixing a security issue will be more costly than building everything correctly from the beginning.

    Any software that involves financial transactions and accounting, secure messaging and mailing, enterprise apps with confidential commercial data, any apps that have security as a cornerstone, mustn't have its costs cut on paying special attention to architecture and secure channels.

    It Means Hard Maintenance

    In the long term, maintenance costs can be reduced by investing more at the beginning. More money, more efforts from experienced software architects, and you rid of a bad side effect of saving money. If you are planning to grow big, eventual maintenance costs are much less likely to go out of your control.

    It Means Bad Adaptation To Changes

    If a certain degree of flexibility is not inherent to your software architecture, it may be technically impossible to add new functionality or new deployment environments in the future. The world of technology is constantly changing, and you might not know which changes you will introduce to your software in half a year, let alone over a longer period of time. Even a change that you'd consider quite basic, could break the logic elsewhere in your system. Good architecture is essential for eventual functional changes that are dictated by your current business purposes and requirements.

    It Means Underdeveloped Scaling And Integration

    When your business grows, your product has to grow simultaneously. Scalability cannot be neglected; otherwise you'll have to spend plenty of time altering the architecture – or rebuilding it anew so it can work in multi-server environment. Complex software systems depend on architecture like nothing else, since there is correlation between each other, as well as integration with third-party services and software that has to be foreseen.

    It Means An Inevitable Waste Of Time And Money

    A serious approach to the software architecture saves your money and time in the long run, and is more open to further enhancements, which will definitely take place if you succeed with the product. If you look to the future and foresee where your system should be expanded, it's a double win.

    Good architecture is really 'invisible'; it just operates clockwork, being easy to maintain. Bad one has a short lifespan and may come to the point when your software is no longer operable, no longer integrates with your business well, and limits your options as for expansion.

    A strong foundation makes a strong software product. If you have a project that requires experienced architects and developers, feel free to contact us at any time. We are always glad to provide you with a qualified consultation.
  • Creating A Mobile Startup: Team And Advisors Jan 27, 2015


    Nobody wins success without a strong team. To say a bit more precise, no startup wins success without a great development team. Nothing happens without proper structuring, selecting, and building interactions. Since about a half of our clients are startups, we know the specificity of this work. We know how to build right interactions with the startup owner. We know the common pitfalls. All of this we'd like to share with you.

    Most startups deal with remote teams, and it's a great, efficient way of building a startup. It worked for plenty of startups before, and it can work for you as well.

    What Is A Team?

    How do you define a team? It must be a group of people very close to you, people who you trust. Together with these people you can achieve and deliver, be it your soccer team or your startup team.

    Your startup team are people who can implement your ideas. Every person in the team must deliver, be they your longtime friends or recently hired professionals. A startup is not merely based on fun (although it's quite a good place to have fun), it's the place where you build your product, where you sell, where you change the world. Everyone who is involved in your business, either your employees or partners or your wife, are a part of your team. You have a common goal – to create a product, to establish a company, to fulfill the needs of your customers. Together you are working to achieve these goals.

    Team Structure

    You start with a core team of one or more co-founders. You also might have advisors, investors and contractors in your team. Over time you grow, and more and more people are added to your team.

    At the beginning you're small and you don't have a lot of resources. In order to grow you have to be wise with distributing the resources. You cannot afford having a big team. At the same you should take care of lots of important things: vision, product, sales, promotion, accounting and legal.

    A very convenient way for startups to organize their business is hiring a remote team with contractors. In this way you can focus on your core business needs. Your core competence is understanding your client's needs and finding a way to satisfy them with the software you build, so you cannot delegate these in any case. The rest (accounting, promotion and product implementation) can be delegated to contractors who specialize in that.


    Core Team

    The must have here is CEO. CEO can be accompanied by another co-founder: CTO, or co-CEO, or COO. The main point here is sales. If you don't want to sell, you shouldn't start a new business. There is no 'if you cannot sell', because we believe everyone can – or everyone can learn how to do that. A lonely CEO is also quite a widespread scenario.

    How should you spread responsibilities inside the core team? Let's look at a startup canvas.



    Advisors are smart people from your product niche. Typically they have either a business or technical experience and knowledge which can be highly important for you. It's great to involve advisors to your team; at the same time you cannot be sure that gurus will come and solve all the problems for you. They won't do it instead of you. They will give you advice; you are here to solve problems. In a rare case you might meet a senior entrepreneur who'd like to use their sales channel to spread your product. But you cannot count on that, and experience tells everyone to rely on themselves.


    Investors are a combination of angel and devil. They give you money, they help, and later they come back for your soul. The money comes without a problem when the investor sees the value in you and your business. You must become valuable before going to the investors. You must create this value. They must see how they'll get the money back with you. Investors won't solve the problems instead of you either.


    Freelancers. These are people who want to live on their own without taking too much responsibility. If they are in a good mood and know how to do it, you'll have a result. Otherwise your'll just lose your time and money.

    Agencies. Solid agencies are a better option. Agencies provide services to help you with specific questions. It can be legal & accounting, marketing & promotion, or product development. According to our experience and the experience of the startups we work with, extending your product development team with an agency is a wise and efficient option. Especially if you have a limited budget for an MVP. You may delegate product implementation to an agency and focus on your core business.

    How To Get Maximum Benefits From An Agency?

    1. Get a consultation before and during the collaboration.
    Feedback on idea, suggestions on implementation, approximate estimates. Viability of the project on the emotional level. This doesn't spend your budget.

    2. Use agency expertise and consider suggestions.
    Get options, decide how they suit you, and choose.

    3. Hire top people for the tasks.
    Feel free to talk to team members. It's your team and you're going to work with these people. Be confident in them.

    4. Agency is responsible for delivery.
    Once the contract is signed, the agency has its own responsibility and liability. You provide money and availability to answer different questions. So demand results from them!

    5. Let them guide you.
    Software development is a complex area of knowledge. It's not necessary that you know everything. The agency is here to help you with processes and technologies. Ask for explanations if you want to understand what's happening behind the scenes.

    6. Flexibility.
    Hire and fire on demand, fast. Scale up and down, fast. It's not easy to do with the internal team members whom you hired, and it's evil. But it's easy with an agency. You don't have the employer responsibility.

    7. Share problems and ask for solutions.
    Agency is interested in your success, so they will find some ways to help which you might have not even thought of.

    How To Wisely Select An Agency That Will Bring You Profits

    1. Define your cost category.
    Be reasonable. Don't participate in the lottery called 'the cheapest wins' (making a Facebook for $300). Buying a cheap car, you'll run into a lot of problems.

    2. Get access to the key people in the agency.
    Talk directly to chiefs, so they can feel you're an important client and treat you accordingly.

    3. Good agency asks LOTS of meaningful questions.
    Smart people ask relevant and thoughtful questions about your goals, about your customers and the product, because they want to help you achieve these goals. Questions about requirements and technical questions are asked. Questions should show the level of their understanding and involvement into the talk.

    4. Get a dedicated person responsible for delivery.
    Typically on the agency side it's a PM. Project manager helps you to keep things organized and manage the remote team. In a team you might have at least one developer, one QA, one designer. So it's easier to have a single point of contact. It's nice to brainstorm together. At the same time everything should be transparent so you could communicate also with each individual.

    5. See and Feel proven track of records to discover the ability to deliver.
    Talk to the people who made the portfolio projects, talk to the existing clients. How does it correspond to your product from technical and business perspectives?

    6. The next point is critical for working with any team especially with the remote one – it's Communication!
    а) Mutual understanding & talking the same language; b) time zone; c) culture and values; d) being easy to meet. Every point in the estimate must be explained and thus be understandable.

    7. Honesty.
    Rarely is a complex software product implemented without any issues. If you're informed about issues and risks straightforward and beforehand, then your product is in good hands.

    What Else Must Be Considered?

    Even if you choose a reliable agency, there are pitfalls you should be aware of.

    1. Start with understanding your goals!
    If you want to build a product fast and you know what you want – a remote team is the perfect choice. If you're looking to get the next round of investment, your local team members would typically increase company evaluation. Know your goals, share your goals.

    2. Track the progress!
    In order to make sure that your goals are achieved, see how smaller steps are made. Do it on the regular basis, ask for regular demos or reports. See the results with your own eyes.

    3. Trust-control balance.
    On one hand you want to see the results and make sure the milestones are met. On the other hand it may end up in microcontrol, which would consume a lot of your time and distract the team from their tasks. So it's easier to let the team do their job and use smart tools which show you the real situation: code repository, task/bug trackers, agile boards, etc.

    4. The worst thing in working with remote teams is assumptions.
    Don't make any assumptions, question everything, ask how people understood you, ask about the complexity of the tasks, about ideas. In this way you'll manage your own and team members' expectations positively.

    All in all, we wish you to work with reliable partners, find awesome team members and launch new great products! Feel free to contact us with any further questions – or if you are in search of a contractor agency.
  • 11 App Development Myths That Hinder Success Jan 23, 2015


    There are persistent myths about app development that just don't seem to go away. These 11 myths have been hindering appreneurs' success for quite a time. Let's refresh and bust them all.

    Myth #1. Idea is everything.

    Some people are overprotective about their app ideas, which results in someone else with the same idea taking that place on the market. It happens just because they tend to hide ideas instead of implementing them as soon as possible. Because it's not the idea that matters the most, it's the way you implement it. And if we take a concept of 'truly unique idea', chances are that it isn't practical or widely applied on the oversaturated mobile market.

    Myth #2. A mobile app for your business will take lots of time, efforts, and money.

    Well, it's hard to tell without a little clarification. It may be so that your business needs a mobile app to showcase your products and/or services, and you can simply get a pre-built solution. Some are provided by companies that create custom software, such as Presentation Box by MobiDev, which offers equally great user experience for your customers across all mobile platforms. It's faster, easier, and cheaper than a fully custom solution – and it offers easy content management for your employees to keep it up-to-date.

    Myth #3. 3 months of development works means 3 actual months.

    Effort and duration are different things. Your developers might be unable to dedicate full 8 hours each day to your project, for example, while they are simply waiting for your answer. Duration obviously takes a longer period, even if the required effort remains roughly unchanged.

    Myth #4. Every detail will be discussed before the development starts.

    Changes are inevitable in software development for being at a high ebb on the market. This is the usual reason why actual development takes more time than it's previously estimated. Enormous amounts of time writing detailed documentation for a complex product makes it dated – unless the industry itself is so stable that no market changes appear for long periods of time (usually more than 1 year).

    Myth #5 . You can easily overtake project management responsibilities.

    If you have the core business part to take care of, being a PM for your own project is simply impossible, considering the huge list of responsibilities handled by professional PMs in software companies. In this case you'll have to sacrifice something, which isn't good for your future product in the first place.

    Myth #6. You have to choose between good UX and fast development.

    There are many ways to have both, including multiplatform development based on PhoneGap and such performance boosters as RAD.js.

    Myth #7. You'll reap huge benefits if you use the latest technologies.

    In case of Apple's Swift it's true. But as for smaller technologies and frameworks, it's better to be consistent and apply technologies according to the experience of your developers. Any latest product has certain drawbacks to be fixed, even Swift. Let's say that you'll reap huge benefits if you value your developers' suggestions and trust their reasoning and expertise.

    Myth #8. Employee UX is expendable.

    This is a misconception. High productivity is achieved only through polished and convenient experience, whether you build for a world audience of users or for your employees. They have to use your software, but how effective their work is, depends on its convenience.

    Myth #9. Corporate apps have poor security.

    In fact, the only software that can't suffer a security breach is non-existing software. Just remember all of those news about breaking into the databases of Twitter, Google, Dropbox, when all users were recommended to change passwords. However, it's quite possible to ensure a high level of security with effective means of authenticated access, encryption protocols, or simply remote data wiping in case the device is lost or stolen.

    Myth #10. Once the app is out, it's all over.

    Marketing campaign, tactics for increasing sales, app store optimization, special offers for users, tackling changes in user expectations, maintenance works, updates and redesigns for new versions of operating systems, UX improvements and polishing, analytics and feedback – we can go on here. Being a startup owner is a daring but rewarding experience, and product development is just a half of the way.

    Myth #11. You know how often you'll need app updates.

    To a certain degree you do, but there are API updates or bugs that require urgent releases of new versions of your app. Moreover, your competition is continuously struggling to improve their own products and take over your users by offering something better, and you have to retaliate. The market is changing, your users' habits are changing, even the whole philosophies of mobile brands sometimes change. You won't have any monopoly here.

    Knowing these myths, it's quite easy to keep on working for success without letting them slow you down. In case you have any further questions about software development, or a project that requires detailed attention, contact us and we'll be glad to discuss them.
  • 33 Myths And Misconceptions About User Experience Jan 21, 2015


    What are the most common myths and misconceptions about user experience on the web? The famous UX Myths website gives 33 of them. While it's directed mainly at designers, we believe that every software owner should take notice of them.

    Myth #1: People read on the web.

    Their eyes scan web pages for relevant keywords, headings, lists, shorter paragraphs – no small talk and long blocks of text allowed. Only if they find the content they are really interested in, will they read it thoroughly.

    Myth #2: All pages should be accessible in 3 clicks.

    It isn't true that your users will leave your website if they can't find what they need within 3 clicks. Clicks don't affect user satisfaction – intuitive navigation does. If your website or app persuades users that they'll soon get what they need, they won't think of how many clicks and taps are required. However, for apps that require certain repeated actions, the fewer taps, the better.

    Myth #3: People don't scroll.

    Scrolling is natural and it works way better than dividing lengthy content by separate pages. Yet as usual, what's placed at the beginning must grasp the reader and persuade to move forth.

    Myth #4: Design is about making a website look good.

    For both websites and mobile apps, design is not decoration; it's the combination of how it works and what it looks like. Great design solves users' problems; it's made for use, for easy and fast one at that.

    Myth #5: Accessibility is expensive and difficult.

    Creating a website that's accessible on different devices with different screen resolutions requires good planning beforehand, and not some extra features or extra content. Yet making redesigns of a poorly accessible site may take time, although it always pays off.

    Myth #6: Accessible sites are ugly.

    Accessibility means making content available to users/visitors with different devices. The main requirement of accessibility on the web is separating content (HTML) from visual appearance (CSS). Accessibility in itself doesn't negatively affect the visual part.

    Myth #7: Graphics will make a page element more visible.

    On the contrary, too colorful elements can be easily mistaken for ads and avoided. What eyes really look for, are links and text that hints on the needed information. They can and should be emphasized, though.

    Myth #8: Stock photos improve the users' experience.

    Pure decoration is not about enhancing UX; it often comes otherwise.

    Myth #9: Design has to be original.

    There are certain UI design patterns, and you musn't shun them when approving your design. These patterns have already been tested as for usability and worked for numerous businesses: why wouldn't they work for yours?

    Myth #10: If your design is good, small details don't matter.

    Take Apple – they pay huge attention to details, because details make the design in the end. Details, informative messages and calls to action, enhance the experience and influence users' decisions.

    Myth #11: You need to redesign your website periodically.

    Radical redesigns don't increase your conversions. Sometimes people hate radical changes even if they introduce better experience – take the iOS 7 example. On great websites, you will see only minor (yet substantial) improvements that step by step perfect their design.

    Myth #12: More choices and features result in higher satisfaction.

    More choices and features means more complexity, so don't be excessive. Thus it's harder to understand the UI of your product. It has to be as simple as possible, and perform all the required functionality in as few steps as possible. This will earn higher satisfaction.

    Myth #13: Icons enhance usability.

    The overall rule is: text labels next to the icons work for usability. In apps, where the space is limited, it's great to use commonly understood icons, such as save, delete, play, print, etc. Stylish icons will make the look more pleasant to the eye of the user, unless they contradict with usability.

    Myth #14: You are like your users.

    If you set this as a rule, you'll end up with inefficient design. You are biased, you love your product, and you always have lots to learn about your users. Involve outsiders to test your product, and you'll see how their goals and approaches can be different.

    Myth #15: Users make optimal choices.

    Upon first contact with an app or a website, people might be 'guessing' where they'll find what they need. They try to select the first reasonable option that catches their eyes, the quickest and the easiest, which is not necessarily optimal.

    Myth #16: Search will solve a website's navigation problems.

    One or several clicks are easier than typing. That's why search is used when users are unable to find what they need through navigation – in some cases this may mean it's not good enough.

    Myth #17: The homepage is your most important page.

    Say, your homepage has links to pages and articles about your products and services – and it's exactly these pages and articles that people spend most of the time on – and it's these pages that should be optimized in the first place.

    Myth #18: Flash is evil.

    The overuse of Flash is evil – not the technology itself. It has improved over time and become SEO-friendly.

    Myth #19: You don't need the content to design a website.

    Content is king. Content is never secondary. Content is what your website visitors are here for. Design is more of an enhancement that helps people easily access your content.

    Myth #20: If it works for Amazon, it will work for you.

    This is about copying features without thinking how they will work for you, and whether they will at all. The same software and interface doesn't mean you'll receive just as much profits. As for copying design – it's reasonable when you understand why it works for another company and how it's supposed to work for you.

    Myth #21: People can tell you what they want.

    Listen to your customers, but know what to ask. When it comes to an unfamiliar design, people's predictions about their behavior can be confident but delusive. Besides, preferences and tastes tend to change often – yet usability guidelines can cover them. So listen to your designer in the first place.

    Myth #22: Usability testing is expensive.

    You don't need plenty of labs, prototypes, and participants to test your website as for usability. It's generally quite enough to test specific tasks with 5 participants.

    Myth #23: Choices should always be limited to 7+/-2.

    This is about limiting options in a dropdown list to 7+/-2, which is the number of items a human can hold in the short-term memory. There's no need to hold them, they are visually present on the page and easy to manage.

    Myth #24: People always use your product the way you imagined they would.

    Once a user finds a way to use your app or website, they'll stick to it. And it's not necessarily the intended way. Collect feedback to be aware of these ways.

    Myth #25: Aesthetics are not important if you have good usability.

    Value usability, but don't neglect aesthetics that attract people, make them relaxed and pleased, and evoke positive emotions towards you and your company.

    Myth #26: Usability testing = focus groups.

    These two notions have different goals. Usability tests show how people use your product by assigning certain tasks, while focus groups assess what people say, their preferences, feelings, feelings, and opinions about certain aspects of your product.

    Myth #27: UX design is about usability.

    Usability allows to accomplish certain goals. UX is about allowing people to do it in a meaningful and delightful way.

    Myth #28: White space is wasted space.

    White space works for good readability and prioritization of content and user interface elements. It also makes your product look elegant and harmonious.

    Myth #29: People are rational.

    We don't always stick to careful analysis of what we do. We use emotions when we make decisions, and that's a fact. Yet for UX design our irrational behavior is predictable, and a good designer will keep you aware of possible complications.

    Myth #30: If you're an expert, you don't need to test your design.

    Usability testing and expert opinions tend to show different outcome and work best when combined. You need to have a comprehensive analysis to build a great product.

    Myth #31: UX design is a step in a project.

    UX design is not just a UI sketch. It's not just a step or a checkbox in your project. It's an important aspect that affects the whole lifecycle of your project and your business strategy. And after the launch there are constant adjustments and improvements.

    Myth #32: Mobile users are distracted.

    Distractions are everywhere, and mobile doesn't have to be necessarily used on-the-go. People use mobile devices at work or at home. Mobile engagement is higher than desktop. Mobile users are more concentrated and result-oriented.

    Myth #33: Success happens overnight.

    Almost none of the famous products was an overnight success, no matter how it may seem. It takes plenty of time, efforts, feedback and improvements to make a game-changer on the market. But if you are a determined person and you have a great development team by your side, you may go for it – and reach it over time.

    Our designers know how to create perfect user experience that follows guidelines, people's actual feelings and positive emotions towards the products we create. Contact us if you need a designer or a consultation regarding your own software product.
  • Cross-Platform Development: Challenges & Opportunities Jan 19, 2015

    Creating one app that works on all platforms is quite a tempting endeavour. Adjust it to every platform you plan to cover, and to all devices you want to cover, which takes much less time than going native anyway, and there you have it! Right? Not really.

    If the cross-platform was that much universal, native development would have gone out of business. Yet software owners thoughtfully launch apps crafted with PhoneGap, and keep their users more than satisfied. User groups can have the choice between iOS and Android as just a personal preference. They may have an Android smartphone beside them on the table, yet they'd prefer to use an iPad to access the same app sitting having a lunch in a café. Thus, the multiplatform is a good choice for those who know its pros and cons, its challenges and the opportunities it offers.

    Opportunity: Reduced costs, less time required, and unified marketing. The obvious pro that outweighs many cons taken together.

    Challenge: Since mobile platforms are completely different, from typical navigation controls to general philosophies, use the correct design approach. Great designs must be natural for each covered platform – not identical.

    Opportunity: See whether PhoneGap is a good solution for your project. It's one of the most widespread technologies for cross-platform development, makes use of JavaScript/HTML5 development tools, which allow your developers to do the job fast and easy, with average code reuse approaching 97-99%.

    Challenge: New mobile devices emerge on the market continuously. Not only you have to ensure great user experience from the beginning, the app should be fit for new devices with new OS versions, better screens, and performance capabilities. Your software is easily adapted to different sizes and resolutions, aspect ratios, and orientations.

    Opportunity: Functional strength and performance of JavaScript/HTML5-based apps is already at an advanced level. They incorporate native capabilities of mobile platforms. They consume less energy on mobile devices. HTML and CSS obviously aren't going away in the observable future.

    Challenge: You must look for a company that has experience in the multiplatform. They know how to create software with inherently optimized performance, and what tools to use. Most of the talk about bad performance of cross-platform apps appear owing to poorly built examples with non-optimized DOM structures, unsuitable image scaling, bad handling of long lists of items, etc. What's the result of the right approach? The smooth UX that your users are looking for.

    Opportunity: Multiplatform apps can be both deployed/viewed in browsers as web apps and distributed/monetized as native ones. They are easier deployed and have decent support for cloud services.

    Challenge: Advantages and flexibilities of one mobile OS may be missing on another one. The more complex your business logic is, the harder it is for multiplatform implementation and integrations.

    Opportunity: There's plenty of cross-platform frameworks, plugins, modules, and toolkits that extend the functionality of your software. Some of them, like RAD.js by MobiDev, allows to enhance performance as well.

    Challenge: Every time a feature is added/modified in native development tools, it has to be reflected in the cross-platform ones, and the code of your app will have to be adjusted as well. Such updates for the multi-platform lag behind those for the native.

    Opportunity: The multiplatform is a good solution for enterprise and BYOD. Your employees will be easier to satisfy than any niche of the global user audience.

    Challenge: Limited graphics and 3D capabilities. That's why for most mobile games native development is currently the only way.

    We can't deny the fact that major players on the market can afford to stick to developing separate native apps for every platform. But in the case of startups that only start growing, multiplatform software can be the best place to start. And if you need a technical specialist for your own project, please contact us and we'll be glad to consult you.
    Martina Wade likes this.
  • Backend-As-A-Service: Pros And Cons Jan 13, 2015


    Any website or complex mobile app requires backend, the 'invisible' side of software that contains logic and databases. While many startups and other businesses use custom-built solutions, fully created and integrated by their software development teams, others choose a popular alternative - backend-as-a-service. It provides your team with a pre-built backend API, so that your developers conduct data modeling of your business logic and specify it in BaaS.

    Like any solution, it has advantages and limitations that can help decide whether it's going to work in your particular case. There are some general pros and cons that you should know.


    • The BaaS market is constantly growing. It's trendy. As it reaches new heights of popularity, its technological sophistication and flexibility of options will grow as well; yet it will mostly concern well-established providers with big marketshare.

    • You save weeks and months of backend development. It takes quite a lot of time, and does it quite monotonously for developers. If compared, a BaaS solution will be simply 'plugged in'. Though it's not a momentary job either, it will obviously help you roll out the product faster.

    • With a fast solution quickly provided, you can concentrate efforts on the front-end and user experience matters.

    • An off-the-shelf BaaS package can be a good solution if you expect your startup to be relatively short-lived on the market - for example, up to 2 years, which is common for mobile games.

    • You don't have to take care of hosting and maintenance. You pay your vendor for a product that works. The same goes for scaling - however, you will be charged for that additionally.


    • You have less control over the infrastructure. Only the features and data are under your control.

    • Although a suitable BaaS package can be rather cheap from the beginning, it can be that your project requires simple backend that in the long run becomes cheaper if custom-built within a short amount of time. Details are a matter of calculations.

    • Minor adjustments are impossible with third-party backend. You can't increase performance or reduce response time with server optimization. In most cases you select a BaaS package.

    • If you select a smaller vendor, there is always a risk they will go out of business.

    • The logic of your software might be too complex for standard BaaS solutions. For example, these may be real-time apps that involve complex or delayed calculations. If your vendor doesn't have enough powers, and the BaaS is deployed on a single cloud platform, loading time may drag for your users from other corners of the earth.

    • If security is the cornerstone of your software, BaaS is not the best solution. Whether it's all about secure communication using such cryptographic protocols as Off-The-Record Messaging, or transferring confidential commercial and financial information, your channels should run through custom backend that's fully yours.

    Even if you consider BaaS a good option for you, take time to address a software development company for a qualified technical advice. The financial side depends on the pricing system of your BaaS vendor and your strategy and budget. The vast majority of your users will not care where your backend is stored, unless they are overcautious about security issues. They'll appreciate their user experience in the first place. In case you have any particular questions, contact us and we'll be glad to help you.
  • Hidden Costs Of Mobile Software Development Jan 5, 2015


    How do you estimate the total costs for your software project? Your software team gives you rough estimations for design, then development, testing(additional 30-40%) and project management (additional 10-15%). Meanwhile you add the costs for marketing and any other expenses that are fully under your control. But what is there that tries to escape your eye?

    If this project is your first one, it's quite usual to have unrealistic expectations. One of your primary tasks as a software owner is to ascertain all costs and risks related to development and deployment, as well as further maintenance of your product. The hidden costs follow you during the whole process, and it's easy to exceed the scope. Then come the hardships of borrowing more money from investors, draw it from your business, and in the worst cases put the project on hold or cut the development costs. The success of your startup/mobile product will be up in the air.

    Prevention lies in knowing the cost-related pitfalls. The very first advice is to choose a software company that offers the full cycle of development, has business analysts and project managers to help you be more realistic. Freelancers and companies that offer incomplete development cycle (e.g. without designers or QA engineers) will not be able to make estimates to rely on.

    Here are the hidden costs to be prepared for. You won't face all of them – some concern mostly corporate software, for example – but it will be useful to take notice.

    Preliminary Stages

    • Involvement of a business analyst and/or technical consultant. Research as for project implementability.
    • Legal consultations and trademark registration, if needed.

    Design And Development

    • Backend development, server hosting. These costs depend on the complexity of your software's logic.
    • Changes of requirements in the middle of development are quite undesirable; some are easy to handle, some may call for substantial recoding.
    • For corporate software – data migration from the old system or the previous version of software. Integration with other systems. Expenses for storage of the old system's backup.
    • Releases of new devices and platform versions in the middle of development – involves extra adjustments and purchases of new hardware (for corporate users).
    • Paid libraries and other software used in your project.

    Deployment And Maintenance

    • Application store fees for native and hybrid apps. Apple App Store: developer's account ($99/year) and enterprise account ($299/year for proprietary apps for internal use). Windows Phone Store: individual account ($19/year) and company account (approximately $99/year). Google Play: one-time $25 fee for an account.
    • You get only 70% of all revenues brought by your app, be it upfront charge or in-app purchases. The rest is taken by Apple, Google, or Microsoft – whichever platform you build for. Exact amounts may vary.
    • Training users, if necessary – for corporate software.
    • CMS management – continuously providing your users with up-to-date content.
    • The way you see your software and the way your users want to see it is always different. After the release apps are continuously updated and tested, tailored to users' preferences, new OS versions, changes in third-party APIs, etc.
    • Customer support service. You have to invest into it and keep providing quick responses to customers' requests.
    • If your network starts rapidly growing users, you'll need to expand the backend so it can handle the load.

    Your software team can consult you on these issues more closely after they study your project. There's nothing a good team can't handle – you only have to be thoroughly prepared and know the weaknesses of your project. Together with a great team you'll be able to turn them into strengths under your control.
  • App Localization: How To Prepare Your App For Global Audience Dec 24, 2014


    Major application stores (App Store and Google Play) are currently available in more than 150 countries with apps supporting over 50 languages. If your app concerns selling and buying real estate across the USA, presenting a nation-specific product line, local HORECA services, or corporate software for internal use, the language question is easy.

    But if your app targets a selected a target user niche that's not limited to a particular country, you'll go global for market opportunities outside English-speaking areas. For brands it's building presence in various countries simultaneously, directly speaking to customers, paying attention to local holidays and culture. This works for both revenue opportunities and customer satisfaction.

    You can and will identify target countries for distribution, locales and languages. You start with major regional languages and gradually add others. But you cannot tell in which country your app is going to become a hit with plenty of downloads and positive reviews streaming one by one. So what do you consider while aiming at many countries?

    • • Multilingual user-visible content is the tip of the iceberg that will engage your audience, be it the global sports fanbase, enthusiastic travelers or keepers of productivity. You can present your app differently to target users from different cultures: text, graphics, icons, audio and video. It involves minimum changes in source code, and all you have to do is provide the app with translations of high quality: either involve outside translators, or there may be skilled people in your software company to do the job.
    • • Translation of user interface elements. Actually, it's nothing your development team cannot handle: alert messages, functional buttons, app name if necessary – that's all pretty standard.
    • • Support for typographic features, fonts and special characters, and specific input methods(the simplest being the difference between right-to-left and left-to-right). Your app must accept input text in any language and in several languages at once, regardless of the UI language.
    • • Currency conversion and international payments. What's more, App Store and Google Play are divided into stores for different countries with different available apps, different rankings and reviews. The country-specific stores also concern post-release support of users in different time zones around the world – you'll have stats and user feedback from each store.
    • • Autocorrection dictionaries and keyboards for every covered language; locale-related issues (differences in formats for dates, times, lengths, weights, numbers and separators that vary, and other entities).
    • • Metadata at App Store / Google Play. Descriptions, keywords, screenshots: adjust your text for every country meticulously – no machine translation. People want to read descriptions in their native language without awkward feelings – and find out more about your app with ease and pleasure.
    • • When translating the content, always work with professional translators – machine translations harm the experience of your users. Even better if you can get a native speaker to review your texts – you don't have to meet one in person, it's easy to hire remotely. Beta testing in key regions can also help with it.
    • • Marketing for different regions is also essentially different, and promotional materials should be translated as well. You might try different approaches for different countries in both text and visual part.

    Most of these issues are handled by your software development team. Developer tools, even standard ones, allow to easily avoid hand-tweaking and automatically adjust your product to various countries. The come professional translations and apps separately promoted on every local market. If you want a consultation as for your particular project, please contact us and we'll be glad to discuss it in detail.
    techbat likes this.
  • A Guide For Startups: From Idea To Product Launch With Software Development Partner Dec 18, 2014


    A good software company is not just a contractor for a startup, but rather a partner. That's what MobiDev has always been. A great partner will provide the startup owner with all of its expertise and grow with the startup, lead it to success by developing a great product. This path is at best trodden together, with mutual efforts. On the contrary, it's bad when the software company has a diminished role or simply cannot fulfill all of these responsibilities. MobiDev set its goal as being a genuine partner for every Client.

    Here we'd like to describe the initial stages of creating a startup and developing its product. We'll discuss the most important moments, milestones, considering startups' expectations and the reality that awaits them, showing how exactly a Software Development Partner can help the startup owner at each stage of product development.

    Check your personal guide A Guide For Startups: From Idea To Product Launch With Software Development Partner
  • 10 Deadly Sins Of Mobile Apps Dec 16, 2014


    Remember how proudly the phrase ''Users love their apps'' was uttered at Apple keynotes by Steve Jobs and Tim Cook? It's absolutely true that users love good apps. It's only good apps that stay on smartphones and tablets after a first try. More patient users may give a second and a third try, but not much after. Some of the apps can be downright frustrating for users; and even the first try becomes a torture for some of the reasons stated below. So if you want to know the deadly sins that can drive users crazy, here we go.

    #1. Designed For Top Devices Only

    Everybody designs apps for the latest, top notch, most relevant devices. But it's really unfortunate that slightly dated or low-end devices often end up overboard. Mobile devices get dated very quickly, and new hardware gets new screen resolutions and bigger performance capabilities. But by neglecting previous generations and middle-class/low-end devices you lose lots of users. If they get experience full of lags and visual design shortcomings, they will abandon your app in favor of another one.

    #2. Oh So Slow

    Heavy and non-optimized apps, which haven't been properly tested, take quite a while to load. Visually more than 5 seconds of launch time is a real drag for users. It may not be the guilt of your developers – just don't cut costs on testing, and you won't know these problems. If a long launch can't be avoided for a reason, your designers will create a catchy launch animation that will keep users relaxed.

    #3. Huge Input Forms

    ''Log in with Facebook''? No problem! Creating an account with just an e-mail and a password? Great! But if your users have to enter e-mail, password, confirm password, full name, age, gender, a couple of other fields for good measure, they might as well get bored, exit the app and erase it. Don't scare off with huge forms – better show the goodies provided after registering. The full profile can be filled out after the signup. Just avoid asking for too much text input.

    #4. Demanding Personal Data Excessively

    When the user sees that your app will ''have access to the following user profile information'' from Facebook, make sure that the list is not overlong, which equals intrusive. The connection to the account must also be optional. Again, show the value user will get if the access is granted.

    #5. Too Much, Too Much, Too Much, Too Much, Too Much

    You don't want to cram too much of everything into your app. That's because your users don't want you to. They won't tolerate overuse of calls to action and heavy weight. They would choose an app with smooth UX that accomplishes a goal simply and quickly. More features mean complex interface, and a professional UX/UI designer will take a look at your project and easily tell you where the border you shouldn't cross is. Users accept an action accomplished in 2-3 taps, but if it takes 6-7 just to get where they want, it will be irritant.

    #6. You Shall Not Pass (Unless You Follow Us)

    If you ask users to follow you on social media, don't make it a repeated demand. Don't allow these requests be an obstacle preventing users from moving on with your application. That's a killing way of blackmailing users – they may follow your request, but a bad impression will remain. ''Follow us on Facebook'' can be easily rejected if given without a reason. Offers? Discounts? Be concise with the message. Same goes for asking for reviews and positive ratings on the stores. All of these messages are especially intrusive when they appear before the user has a chance to try things out.

    #7. Ad Is Bad

    Have you informed your users that your free app contains ads? Is it written in app description? It should be, otherwise they will get not what they've been expecting. Some people accept apps containing ads. Surely ads will not disappear since app owners have to monetize their efforts anyway – that's the truth of life. But unresponsive ad banners that mar the experience, or just come out of nowhere and occupy the whole screen, are deadly. Once the ads are hated, the app gets hated just as much.

    #8. Hungry Apps Eat Users' Patience

    Hungry apps don't last long. Examples include excessive usage of CPU power, device memory storage, and network overload. Let's crown it all with hunger for battery life. Understandably people won't be very satisfied with them. If they feel the app drains too much energy, they can easily check it – for example, iOS 8 introduced a native feature for this purpose.

    #9. Update Frenzy

    What a tempting thing it is to cut costs on testing and release the app faster. ''Let's roll it out ASAP; any problems will be fixed with the first updates.'' But put yourself in the user's place. Poor first experience may easily become the last one. Another bad side of hasty testing is forcing frequent updates on users. Even worse is when users cannot use the app without an update.

    #10. Poor Customization Capabilities

    Make sure that the app's settings will allow users to tailor it to their preferences. It's hidden in such little things as an option to change fonts, mute sounds and music, turning notifications on and off, etc. But it's always pleasant for users to discover that they can make the app even easier to use, and turn off the features they don't like and/or need.

    We did not include freezing, crashing, poor responsiveness, and other things that are not determined by the choice of the software owner, but rather handled by good developers (or not handled by bad ones). It must be sufficient for your users to accept and love the app. Is there anything else you'd include in this list?

    Get more
    11 Software Development Mistakes Not To Make As A Software Owner
    How To Reduce App Development Costs
    9 Steps To Gather Requirements For Your Software Project
  • How To Improve The Lifecycle Of A Mobile App Dec 12, 2014


    You could read in many articles that mobile presence is a huge sales channel, be it an app or a mobile website. Mobile usage is increasing, apps are getting more diverse, and businesses just can't afford losing numerous mobile customers and spending time catching up with more active mobile-oriented rivals further on. Therefore businesses and appreneurs need to roll out great products as fast as possible.

    But while the fact that you should start conquering the market with a high-quality product is mentioned everywhere, the fact that you mustn't falter afterwards is sometimes overlooked. There is no way to slow down the lifecycle of your app. At least it mustn't be slower than the pace of technology or lower than user expectations. How can you do it? There are several things to keep an eye on.

    #1. There's More To User Feedback Than App Store Reviews

    It's so if just for the fact that some users don't bother explaining in their reviews why they love or hate your app. Thus feedback from app store(s) is not the only thing to rely on. There are more sources (you may learn about themhere) and there are analytics tools that help you measure user interest, engagement and retention. If you don't lag at gathering and reacting to what users say, your app will be fit and healthy.

    #2. Up-To-Date Is The Key

    Excluding minor updates with tweaks as a reaction to some problem identified by users, it's practiced to update apps from about once per 2 months to once a month. It's not about the content, which can be updated by you with a CMS on the backend side, but rather developers' work: expanding the functionality, checking compatibility with emerging mobile devices with better performance, bigger screen resolutions, different screen ratios, and so on.

    The simplest solution is handing the job to the team that built the app for you. Do it on a regular basis – use the help of automated testing to identify problems earlier than users, and involve the people who know your mobile product on the inside. The importance of being up-to-date doesn't depend on the size of your business – it works for such giants as eBay and its mobile client app, and any local business that can offer value to mobile customers with its app.

    It's also vital to support each upcoming platform version before its release, so that your users wouldn't face any serious problems. Even major apps still have glitches on iOS 8; but while calendars or to-do lists still have time to fix them, for a banking app that involves transactions it could be fatal.

    #3. Whenever MVP Changes, It Still Must Be Solid MVP

    Apps can change their philosophy if there's a market opportunity in grasping a bigger user audience with minimal functional changes. You should always think in terms of MVP. When you identify it for the first time, you get a set of the most valuable features for users. Then you get validated feedback from actual users, and the wheel's in motion.

    Local dating apps may become popular with students who use it for its location-based features – just to find each other on campus and communicate via the messaging feature. Don't be afraid to change philosophy if it's promising, yet there has to be distinguishing value. And sure you can enlarge the audience with the help of the abovementioned feedback.

    #4. Maybe You Should Go Multiplatform?

    There are many reasons to do it. You might need corporate software to support your BYOD policy. You might want to embrace a bigger audience with enough budget to do so – by building native apps for all the mobile platforms you need to cover. If the estimations are out of budget – there is multiplatform development that takes less time and money, but it's not a perfect cure either.

    High-performance multiplatform apps can be created only by experienced hands. Thus you either find a software company with the multiplatform as the major field of activities, or abandon the idea since a badly constructed app will most likely not live up to users' expectations of speed and stability. Together with a software expert you'll be able to understand whether your features and other requirements can be implemented with native development only, or it's reasonable to build a web-based multiplatform app with very high code reuse (on average over 80%), then adjust it to each platform.

    As you can see, a healthy lifecycle depends on you who steers the wheel as much as on the team that takes care of your software. Its quality defines the way it will go from discovery and adoption to trial and long-term use. Always focus on your customers and their needs – they never tolerate poor UX. A professional development team will help make your mobile app a worthy representative of your company, your brand, your image.

    Get more:
    How To Get The Most Out Of App User Feedback
    MVP: How To Make A Profitable App With Limited Budget
    Support & Maintenance: What Comes After The App Is Deployed?
  • Swift: How We Code Your iOS Apps Twice Faster Dec 9, 2014


    Swift, Apple's new programming language, is going to define the future of iOS development, regardless of developers' opinions, be they good or bad. All the hype aside, the use of Swift can help a developer save approximately 20-50% of development time, while the number of lines of code can be reduced roughly by half. Swift is highly readable, way more than Objective-C. For developers it means convenience. For software owners it means receiving high-quality apps earlier than they could hope before.

    The quality itself surely depends on skills of developers. Our iOS specialists have been putting Swift to use since it became available; they learned about lots of opportunities that speed up the development process. The product can be created faster, which means with less budget. What's more, Swift has great prospects. It can be extremely handy for the future support of the software product, while it's getting gradually broader use.

    Here's a typical task that appears in almost all projects; it is solved via Swift and Objective-C and compared. There is an app that uses a number of fonts. We are going to create a component that selects a font and its size for a UI element.

    For visual components you have to set the font without using interface builder. Every font can be created using its name and size. For example, in our app 4 font types will be used:

    1. Italic (Helvetica Neue Italic)
    2. Bold (Helvetica Neue Bold)
    3. BoldItalic (Helvetica Neue Bold Italic)
    4. Regular (Helvetica Neue)

    We also must be able to change our font family name (Helvetica Neue) at any moment – to alter the font in case of need. And naturally we mustn't use hardcode for naming fonts. Let's see how this task is solved with Objective-C and the new Swift.

    #1. Implementation With Objective-C

    First we create enum, where we list all the font types we have:


    Since we can't add functions to enum in Objective-C, we have to create a separate function for returning a font of particular type and size. For that purpose we create a class ApplicationFont with static method that does the job:


    In implementation file we need to enter the name of font family and make it a constant:


    In order to get the full font name, we'll use two functions.

    1. Getting the full font name: familyName + fontName:


    2. Getting the font postfix (fontName) from the type:


    As a result, here's the function that returns the font:


    The final implementation is as follows:






    An example of applying a font to a UI element:


    As we can see, we have a chain of switch-case, which grows as we add font types. Two h-files (interface file) and m-files (implementation file) lengthen our code.

    #2. Implementation With Swift

    Swift has more advanced enum than Objective-C. In Swift enum can have string values. Besides, we can add functions to enum. As a result, we can deliver the final implementation:


    Applying a font to a UI element:


    As we can see, with Swift we get less code. Functions are short and concise. We have no switch-case chain. And the main thing – the function that returns the font is bound to enum.

    Many other tasks are handled by Swift just as fast.

    That's How We Create Apps Faster For You

    Swift assists by creating the architecture. It has lots of capabilities, which have certain limitations which make it safe. The main strength of Swift lies in the speed of coding apps. This allows to save the budget. While the language is raw, many developers still stick to Objective-C. But everyone has to look to the future, since Swift will take the lead in iOS/OS X development anyway. Apple is quite aggressive about spreading its new language. Now every second sample for iOS 8 is written on Swift – it was when Swift was in beta officially. In a nutshell, we already need to make a shift to Swift to take care of the projects' future.

    There are various programming languages. Many people think it's just a means of coding, and it doesn't matter much what you use. But it does. There are languages that literally help you. They help you develop the architecture, help you avoid mistakes, help better understand third-party code. Swift is a language that's created for developer's convenience, a real helper. And it's impossible to show you all advantages of this language in a short article. It can be felt only when you code with it yourself.

    See more
    RAD.js 2.0: Major Leap In Creating Multiplatform Software For You
    How To Optimize The Performance Of PhoneGap Apps
    Swift: Developer's First Impressions
  • Mobile Events As An Alternative Way To Find Software Developers Dec 4, 2014


    While the majority of business people and mobile startuppers look for software development companies online, visiting dedicated events, conferences, exhibitions, remains an alternative, a very effective at that.

    You don't know who actually may stand behind a good-looking website; at an event you can meet your potential software contractors in person. You need a respectable company for your software project – and you need more proof than statements on the software company's webpage. And if you are a result-oriented entrepreneur who requires cost-effective remote work, and at the same time values face-to-face communication, a mobile event can become the best solution for a number of reasons.

    What Are The Advantages Of Visiting Events?

    Visiting a specialized event is an endeavor that pays off with correct approach. You get rid of the obstacles that plague purely remote work, share all of its advantages and gain new ones.

    • The companies that exhibit and/or share reports at major IT events are considerable players. The very fact of participation is already a factor of reliability – they are real people, they have the budget to exhibit, they have talents to contribute reports to developer conferences. From now on it's easier to warm up trust.

    • You have the opportunity to interview many companies during one event. You have the choice, so use it.

    • You communicate face-to-face with your potential remote contractors. Perhaps the biggest advantage stated in favor of in-house teams is the possibility of meeting in person. Here it's shared partially. You meet in person with the key people behind a software company. If meeting in person is one of your priorities, an event is the solution for you.

    • Getting to the point takes much less time. If you contact a software company purely online, the first calls are dedicated to getting acquainted and gradually proceeding to your project. How fast and effectively it happens – depends on the experience of the consultant you've contacted. At the event there are no obstacles of distance or awkwardness. You can faster see whether you share work principles to get on well for further productive collaboration.

    • You can directly communicate with technical specialists from the company's side. It's much easier to establish a substantial discussion as for the technical side of your project. If there is a technical specialist from your side, it's even better.

    • For result-oriented entrepreneurs there's an opportunity to proceed to the project at once. You can come to positive conclusions and discuss the project there and then.

    • If the event is local in relation to the company, it makes sense for you to visit the chosen company's office. You may talk to the company's top people, including the CEO.

    What Events Are Worth Visiting?

    • First, product-related events. If you need a CRM, you go to a CRM-related exhibition. There you contact people who offer CRM solutions – it can be that you don't need to create it from scratch. Instead, they may have a reaymade option that can be customized for your business needs.

    • If you are an appreneur who needs a custom mobile product, you may either go to an event dedicated to the major technology that will be used to create your app, or to startup events – software companies often attend startup-related events to look for promising collaborations. As for developer conferences – if you have a technical specialist from your side, such an event can make sense for you.

    • There are also outsourcing-related events: there you will find everything you need to know about outsourcing, how it works, how it correlates with your work principles. And a plenty of candidates.

    • At last, the world's biggest IT events, such as Mobile World Congress, are divided into departments where you'll be able to quickly find what you are looking for.

    How To Be A Winner At The Event?

    You are finally there, ready for productive interviews. What should you pay attention to? What questions should you ask? Here's the checklist.

    • First take a general look at the company's representatives. Any event is quite stressful for participants, so you can assess how well these people handle stress, how good their language skills are. Good consultants and managers don't advertise themselves. They must do their best to help you find the best solution to your business problem.

    • Software companies at IT exhibitions are mostly represented by management staff; yet the presence of a leading technical specialist is invaluable. Managers can tell you more about the company and the industries they worked with, showing product examples in the process. A developer will be able to take a look at your documentation, if you have any.

    • Even if you have a full technical specification of your future product, there will be no time for all the candidates to study it. Prepare a simplified, accessible set of documentation with sketches/mockups. The company's technical specialist must be able to take a brief look at this documentation, assess it, envisage the business logic, find possible problematic moments, and voice the opinion that'll be valuable for you. Ten minutes should be enough to study it; full spec can be sent later if you agree on everything else. This is not the place and time to demand precise, well-reasoned estimates.

    • Pay attention to the specialization of the company: whether they are leading specialists in cross-platform development, or they have a strong iOS department with high-quality products on App Store. Pay attention to their certifications. This depends on the kind of the product you want to create.

    • You can do the usual research you'd do while looking for a contractor online: check the website, take a look at the portfolio, read and watch testimonials, check the company's profiles on freelance marketplaces, wherever they are present: Elance, oDesk, Guru, etc. You can either do it yourself or ask them to provide you with this information.

    • Checking the company's portfolio on the web is essential. Yet if the company specializes in mobile development, ask them to show examples of their work on mobile devices, so that you are able to try them out yourself. If there is a product in some way similar to what you need, ask them to tell you more about it.

    • Take notice whether they are active participants of other IT events: do they have regular experience? What conferences did they attend? Were they just guests or did they contribute reports? This showcases their expertise.

    • Don't stop at the first exhibitor. Since an IT event gives you choice, use it to the full. Form a circle of candidates to choose from. If the event lasts several days, you may form it on the first day. Then narrow it on the second one, have a more extensive talk with the candidates you found the most preferable.

    • Don't limit yourself with regions and rates – yet learn as much as you can about various outsourcing destinations. And if you are determined to find a company with an hourly rate of not more than $25, for example, don't neglect those whose rate is, say, $30. The five-dollar difference might mean a serious improvement in quality and reliability – you won't run the risks of building the product twice. If you have a limited budget, they will help you optimize the development and come out a winner. They will consult you and suggest alternatives so that you are able to fit in the budget.

    All combined, you receive a one-time expense that pays off. All in all, Skype calls and Google Hangouts messaging don't substitute face-to-face conversations, especially if it's your priority. You'll be able to reach mutual understanding and move closer and faster to the successful accomplishment of your software project. Our company has rich experience of participation in mobile events of various caliber, and we will be glad to answer any questions you might have – or, if you wish, meet you at a mobile event.

    Get more
    How To Recognize A Good Software Company By First Contact
    How Much Your Mobile App Costs
    7 Steps To Accomplish A Software Project