We’ve put together this list of 7 RED FLAGS to look out for when choosing a SOFTWARE DEVELOPER, based on our diverse and extensive experience in the industry. Choosing a custom software development partner is probably the most important decision you’ll make when creating your mobile app.
Choosing a custom software development partner is probably the most important decision you’ll make when creating your mobile app. Much like a contractor for your home remodel, your software developer should be someone you can trust to be honest, reliable, and accountable throughout the duration. Likewise, if you’ve ever worked with a contractor before, you know that choosing the right one to begin with saves you headaches and money down the road–it’s hard, and expensive, to switch contractors mid-project. The same is true for your mobile app developer.
We’ve put together this list of red flags to look out for when choosing a software developer, based on our diverse and extensive experience in the industry. At the heart of this list is our belief that solid, honest communication is the foundation of a strong relationship between clients and developers. The best development partners will cover the following bases and more, saving you time and money as the project moves forward.
In order to understand exactly what your goals are, your developer should ask you frequent–and probing–questions, helping to uncover hidden costs and expectations. A real-life example from one of our clients illustrates this well:Our client came to us with a specific requirement for their app–a notification for users alerting them when they were within the geo-fence of an airport. This could’ve easily been covered using a standard approach, but our team quickly realized that a standard approach would sacrifice the utility of the app by draining user batteries, as the app would have to be active constantly in order to sense the geo-fences. Our AppIt team recognized that what the client really wanted–not just their stated requirement–pushed the project into custom territory. While custom development is more expensive than standard development, recognizing this need early on allowed us to build a budget around custom development from the very beginning, avoiding costly late-stage adjustments. This simple example demonstrates how even standard features and basic expectations can be misunderstood if your developer doesn’t ask enough–or the right–questions.
It might seem like you’re asking for the moon when you ask for your developer to be well versed in both the business and the tech side of things, but going with a partner who can’t integrate both sides leaves you open to pitfalls as you move forward. If they aren’t asking you about your business requirements, they’re only taking into consideration half of your needs.
Blue means blue, right? Or does it mean turquoise, or navy, or robin’s egg? Lapses in shared understanding can crop up all over the place when designing your mobile app. Take notifications, for example. You might be envisioning SMS, or email, or in-app notifications, but your developer may only be thinking of in-app. Outlining assumptions like these is an invaluable component of good communication between you and your developer. A seasoned developer will know how to be on the lookout for assumptions, and how to tease out a shared understanding.
Many unknowns won’t pop up until later in the development process–both problems and possibilities–and the further into the development process you are, the more expensive these things are to resolve. Herein lies the value of a clickable prototype, where unforeseen issues become evident early enough in development to be accommodated without blowing your budget. So maybe you’d been planning on an email login feature, but when you start poking around with your clickable prototype you realize it would be more natural to have a Facebook login. Even a seemingly small change like this can have drastic impact on your budget if the decision comes too late in the game, so including a clickable prototype in your initial engagement allows your developer to give you a realistic opportunity to figure out the things you didn’t know you needed before you commit to developing with them.
This is a disclosure issue–being able to trust your development partner to be honest and upfront about costs and process. Let’s say you’ve decided to go with SMS/email notifications for your app. Has your developer informed you of any ongoing or additional charges associated with that route? This is the equivalent of your contractor advising you to go with solar roofing but failing to mention that future maintenance and repair is going to be a lot more expensive than traditional roofing.
As the saying goes, between good, cheap and fast, you can only have two. Developers are inclined to give low bids as a strategy to win deals, but once you’re in with a developer, it’s really hard to leave. Miscommunications can also pop up in this stage regarding your timeline, where your developer may overpromise how quickly something can be accomplished or mislead you about the process. Often times this is a result of poor communication about the scope of your project.
Strong partners will be upfront about their process, making sure you know what you’re getting into, and not just telling you what you want to hear. Has your developer taken the time to understand the risks and mitigate them where possible? A knowledgeable developer will be frank about potential risks, and have creative solutions on hand to address them. Essentially, they need to know enough to know where the potential pitfalls lie, and advise you of them at the outset. Think of your hypothetical contractor here, telling you it’s no problem popping out that wall in your kitchen, only to discover late in the game that there are permitting and infrastructural issues. A more experienced contractor would’ve foreseen those issues and pointed them out ahead of time, saving you the costly complications later.
1. Sales. Our salespeople are trained to identify subtleties in project descriptions and gather as much detail as possible to help determine fit on scope, timeline, and budget. You can trust them to have the technical understanding necessary to know which questions to ask in order to assess whether your expectations can be met. This way, you won’t find yourself talking to the developers later on only to find out that what the sales team has offered you is out of reach.
2. Initial engagement. Because we’re only interested in working with clients whose needs we can meet, we’ve separated our requirements gathering and wireframing from our development. This means we can gather all the information we need and produce wireframes (and those handy clickable prototypes that reveal so many unforeseen hiccups and possibilities) before you commit to developing with us–allowing both parties to make sure expectations are realistic and mutually agreed upon. We feel that offering these services separately gives us the opportunity to uncover your risks upfront, giving you full transparency before you commit–and should you choose to work with someone else, you can take the information we’ve gathered with you.
3. Development process. We engineer regular delivery of product snippets to keep you updated as product development continues, giving you the opportunity for regular insight and feedback into how your product is coming along. And since our development sprints are pre-planned with an eye toward timing, your feedback is solicited when it’s least disruptive (read: least expensive), helping to keep your project on-time and on-budget.
At the end of the day, AppIt believes mobile app development should be a rich and rewarding experience. We take the time to understand not just what you’re asking for, but what you ultimately want, and translate that into a solid business plan. By asking the right questions–and having the experience to know which questions to ask–we are able to create a plan that minimizes your risks for budget, scope, and timeline, and deliver you a superior mobile app, on-time and on-budget.