How not to get screwed by mobile app developers

By – Alex Zaltsman

In an era of political correctness sometimes it’s best to just come right out and express thoughts in a perhaps controversial way to get the point across. We’ve been in business for over 10 years now and I have to say that we have seen and heard “it” all – from people who have ideas about products to helping new customers recover from disastrous projects (financially and operationally). We may as well change our name to InnoviMobile App Project Hospital!

I came up with just a few very essential points that companies, startup teams, and individuals should consider before embarking on a mobile app product, let alone hiring a developer:

  • If you’re thinking of hiring a freelancer to create a mobile app that requires UI design, app development on multiple platforms, backend development, QA, and support – don’t. You’re just setting up yourself for failure. Either the developer is lying to you or he/she is lying to him/herself. We have never, ever seen a quality product that requires so many different skill sets create a commercial-quality product from one individual. You will likely end up with an inferior product, and when that freelancer lands a full time job there will be no one to support what was built. Instead, connect and learn about our app developers.

    ­
  • If you’re getting quotes on exactly the same specifications from a variety of sources and you are choosing based on price you are likely to be disappointed. Don’t choose on price and NEVER choose on hourly rates. The best way to choose is only on two factors: relationship and proof of past success.
    .
    ­

    • Relationship factor: You’re more likely than not considering to work with a team you don’t know personally – I’d say it’s probably close to 100%. However, you can still make logical decision and make assumptions based on your experience during the sales cycle. Factors such as response times to emails, being on time for conference calls, follow-up to questions, the roles of the people on calls or meeting, and willingness to be helpful and make unprompted suggestions. All these matter. It’s like dating – you subconsciously see a pattern – and you’re likely to conclude that the pattern will continue. Do you want the experience of that pattern for the entirety of the relationship?

      ­
    • Proof of past success factor: It’s extremely important to seek proof of past success. This isn’t about a reference check. This is about a deep dive about projects of a similar nature. Don’t look for identical projects because in the custom software business there are no two projects that are exactly alike. Use sites like Clutch and Goodfirms to do your research and read about specific projects. Having a casual conversation with individuals won’t give you the whole story. Your really want to understand at deep level not only the capabilities of the team but their likelihood of succeeding and finishing your project – on time and on budget.

      ­
  • Successful products are built from successful plans. You can’t build a successful product by creating a laundry list of 100 feature bullet points. That’s a feature list – it’s not a plan to develop a mobile app. It doesn’t take into account the workflow of the mobile app product, the user’s journey in the app, the problem being solved, connectivity to third-party systems, backend systems integration, and a slew of other factors. If you ask for price quotes based on a task list you are leading yourself on a path to disappointment and frustration. One task item can be extremely expensive to implement, another task item could be simple and inexpensive, etc. You need to whole picture of the product. You need a plan. Whoever you use needs to be able to have the resources to help you with a project plan.
  • If you can’t afford to do it right – don’t do it all.  Save your money and time for a day when you can afford to build your mobile app properly. There are no shortcuts and there are no second chances. A poorly thought out and designed product will be poorly received. People will know ..in milliseconds.. if your product is usable and has merit. They just …”know”. They may not be willing to tell you the truth so as not to disappoint you – but they will know. Unless you’re working with a very small focus group of people you will likely damage your chances of getting a second shot, if at all.
    .
    I want to clarify how this applies to “MVPs” – minimum viable products. This term has become almost ubiquitous in the mobile app development world – just build an MVP – simple and cheap. Guess what – no one ever said an MVP is simple or cheap. It should be exactly what the term says it is – minimally viable. Really the intent here is to not overdevelop and spend time and money on features that people may not use. And simple is WAY harder to develop than complex… it’s super easy to develop a convoluted, full-featured product.. that no one will ever use.
  • Startup ventures: Get a technical co-founder before spending $1.  You’re not technical but you have an idea on how to do something better through a mobile app. Your chances of success are significantly greater if you just find a technical co-founder that can guide your ambitions and understand the technical hurdles your idea will face. We’ve heard ideas that on the surface sound great ..but are technically infeasible. And I don’t mean in a “people told Thomas Edison his lamps will never work” kind-of-way. I mean really they are impossible due to the laws of physics. People without a technical background just don’t have the benefit of understanding how certain technologies work.  A technical co-founder will also help you vet the proper development company because, presumably, that person has experience in software development and will understand the level of effort, and consequently, the cost of developing products.

We’re glad to be a sounding board for your initiative. Feel free to reach out.