A common piece of advice circulating around the internet is that you should price an app like you’d price a car: $5000-$10,000 will get you something workable, $50,000 will get you something great, $150 will get you a lemon that’ll break if the road looks at it funny. Most reliable app developers will cite you $18,000-$40,000 for most standard projects, though something complicated like a ridesharing app could go much higher—you’re looking at $70,000 or more.
There are a lot of ultracheap app developers out there and you should avoid them at all costs. Pricing can vary wildly depending on geography (e.g. an Indian or Eastern European developer has a lower cost of living, so can charge less) but if they’re good they’ll still fall roughly within the prices listed above. If the pricing seems too good to be true, the pricing is too good to be true; $500 will not buy you a Spotify competitor and anybody telling you that can do it is scamming you.
Most developers will have a public portfolio they can show you. Often the specifics are protected, but if they can point at an app and say “I did the UI on that one!” then it gives you a good idea of how well they design a UI. It’s good to get as much data as you can, to build up a more complete picture of their work.
It’s not just about stuff that’s good and high-profile, it’s about stuff that’s similar to the app you want to release. How close is their portfolio to your vision? A lot of managers want to get the best developer when it’s often smarter, more economical and more effective to get the right developer.
It’s not important that you know the details of how version control works, but it’s the system that lets developers keep track of changes and revert to previous code if something goes wrong. It has been compared to “a surgeon washing his hands” in that anybody who doesn’t is dangerous and shouldn’t be trusted.
Even a short answer like “oh we just use Git” will let you know they’re fine—you’re just trying to catch out cowboys who don’t have a critical system in place.
There are three main types of mobile app: IOS, Android, and Hybrid. A Hybrid app isn’t just any app available on both devices: it’s the same code that works on both. You can have somebody write you IOS and Android versions of the same app, but that’s writing two apps and will cost twice as much. A Hybrid app tends to cost more on its own than an Android or IOS app, but it’s a single app and ends up being significantly cheaper if you intend to run on both Apple and Samsung.
Hybrid apps are great, but it’s good to do some market research first. If 99% of your userbase also use IOS, then you’re spending money on Android you’re never going to make back. It’s up to you to do your due diligence on this issue before you take it to the developers. They probably have some useful insight, but at the end of the day they make the app you tell them to make and you shouldn’t expect them to do this for you.
Developers and designers get into this business because it excites them. You shouldn’t be afraid to shoot down things that don’t match your vision or brand, but getting input from the team can really help you to refine and improve your product. You know your product and they know apps: in an ideal situation, you both bring your skillset to the table to make the best app for your product.
Even if it doesn’t end up in the finished product, finding out what excites them can give you critical insight into how they’ll work as a developer. What’s important to them? How do they conceptualise apps? In which areas are they passionate and strong?
We’ve all heard that communication is key, but doubly so in software development. Especially if you’re working with offshore teams, it’s important to establish how they plan to keep in touch with you. Timezones are hardly an impossible hurdle, but you want to know that your chosen developer has got a system for working around them.
Agile Development is the current big thing. It’s built around pair-groups, frequent testing, and flexibility. Agile development, despite the name, can sometimes be a little slower than other pipelines, but it’s much better at dealing with issues that arise. It’s a Four-Wheel-Drive, able to adapt well to any terrain and overcome any problem. It’s not the be-all-and-end all but it’s good to hear—it shows the developer has been thinking about their pipeline. It’s also irrelevant for a single developer, since it’s built around group dynamics.
Waterfall Development is now considered outdated but it’s still used in a lot of places. It’s not as good at catching issues during development, but it’s also very direct and simple and will sometimes just bulldoze through. It’s still very common in heavy industries like construction, but it is slowly disappearing from the world of software.
There’s also Spiral Development, which claims to get the best of both worlds by picking and choosing different elements from different development pipelines. Spiral is complicated and you don’t hear about it much outside of older developers, but those who use it seem to know their stuff.
Tech can often be pretty intimidating to approach if you’re coming from a management or finance background. It sometimes feels like they’re not even speaking English. It’s important to realise this: they don’t expect you to be an expert. They’re the app experts, and they don’t need another. What’s helpful is if you know enough tech to follow along with their conversations. It doesn’t take a lot: if you add Wired or the Verge to the list of things you read on your phone while waiting for an Uber, then you’ll already be head and shoulders above most. It’ll give you a better toolkit for communicating with your developers, and better-equip you to understand the actual work they’re doing.
A surprisingly common issue that arises in development is when the developers and management haven’t communicated about how the app is intended to make money. Are you freemium? Ad-supported? Are you taking a cut of each transaction, or just charging for the app upfront? Absolutely free, and hoping for the 1/1,000,000 saving grace of an angel investor? This sort of detail can change the whole architecture of the app, and it is critically important that everybody is on the same page. This is one of the first things you should figure out when you’re planning your app.
How are they charging? By the hour? By the month? Do they have tiers of support and development? Will they stick around to maintain the app after development is complete, or do you need to move it onto another team? Here at CodeClouds, we offer an affordable subscription service that sticks with you from day 1, for as long as you need. Not everybody works the same way—know how they expect to be paid from the outset and you’ll save yourself a lot of work later.