Lies App Developers Tell to Acquire Your BusinessFive scenarios to watch out for, to make sure you're getting what you pay for.
Opinions expressed by Entrepreneur contributors are their own.
Lies, white lies and damned lies. Developers are likely to tell them all to acquire customers -- even your entire business.
Related:Write an App Store Description That Excites With These 5 Tips
Of course, that's not to say that every developer lies or that every lie told is a blatant and conscious effort to jeopardize your business or product at the cost of your business's growth.
But I've worked with many development firms building products for my earlier ventures, and the tendency to lie is something I've found to be common practice. Even today, many of our existing customers come to us reporting that they've been burned by other agencies that didn't provide for their needs.
We've learned other things the hard way on our journey to buildArkenea LLC, and these are some of the issues we believe you should be aware of when talking to a development firm.
1. Cross-platform
Developers typically suggest building products using cross-platform technologies. This advice is presented in the interest of your winning your project should your budget not fit the scope of a native mobile app across platforms.
The truth is, however, that it's hard to point out a single app across app-store categories in the Top 100 apps that is made using cross-platform technologies. Of course, there are some very specific cases where you could use cross-platform tech, but it doesn't really work for most product strategies.
If you want to validate your product idea, then, built the app only on one platform. Then build for another once you have product/market fit -- rather than building using cross-platform technologies and compromising on the user experience.
The lesson: If your development company suggests using cross-platform tech, make sure you ask pertinent questions on the reason why.
Related:Test Drive These 4 Elements to Increase Mobile App Traction
2. Coding from the get go
One of the biggest mistakes in the product development lifecycle is to begin coding without a granular level of understanding of what you're building.
This is when most relationships go sour, as there isn't any detailing at the early stages of development. Developers typically tend to make more money either because you've detailed-out the app as development is proceeding or the time lines have been stretched by a failure to define the project's scope.
Ask your development company what its process is. Ideally, any good firm should start out by documenting your requirements, in a functional specifications document that details every single element and its flow in the app. This level of clarity should head off any stretching of the time lines, or additional costs during the development stage. Clarity will also enable the developer to build a far better app than would have been built had he or she simply jumped in with high-level requirements to follow.
For example, take a look at thissample functional specifications document from Arkenea LLCthat details just the sign-up screen of a mobile app over six to seven pages. This level of detail will help you avoid a lot of heartburn later due to unfulfilled expectations, lack of knowledge about how a feature works and coding that has been used based on inaccurate assumptions.
3. Build for the iOS or Android, not both.
In all fairness, many startups want the developer to build on both platforms and they may have their own reasons for this directive. However, when creating a minimum viable product or a Version One for the sake of validation, you should know that no app requires that one be built on both platforms at the same time.
It's better to validate using one platform. Then, once you know that there is a set of customers that want to use your app, you can always build for the other. For instance, Instagram launched on iOS first and for a long time didn't even have an Android app.
If your developer suggests building for both platforms at the same time, that suggestion is obviously in his or her best interest. But has this person asked the relevant questions on why such a move is warranted, in the first place? If not, this partner is probably not the right professional to help you meet your business objectives.
4. That's a great idea!
Are you looking for the perfect "yes man"? Or are you looking for a developer who will give you insights on user experience, user flows, the best way to meet your objectives through technical deliveries, etc?
I'm guessing you're looking for the latter, to help you build a better mobile app business. Product development is a collaborative effort between the idea generator and the technical team, with both bringing their relevant experiences to the table.
Obviously, what you must "see through" is whether the developer is pulling one over on you or is genuinely excited about the idea and can demonstrate an understanding of what you're trying to achieve.
5. It's done!
This makes for a frustrating experience for you as a startup entrepreneur. It's difficult to assess "doneness" upfront before you hire your development partner, and this difficulty can end up becoming a thorn in your side.
会有一个特定的之间的差距job or task you want and a developer's interpretation of what that task means. Most often, it means that the developer has finished writing the code for the feature. It doesn't account for whether the business objective for that feature is actually present in the application.
One accurate way of ensuring this will happen, however, is to check for whether your developer has the keen eye for detailing described above.
Overall, hiring a developer can be a daunting task. But if you look for one with the right spirit (and not just the ability to fit within your budget), the right partner will bring you far more returns in the long term than what you'd spend in the near term.
