Effectively Minimizing Scope, Budget, and Timeline Risk
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.
Be wary if your developer…
1. Doesn’t ask probing questions.
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.
2. Fails to ask about your businesses concerns/Focuses only on technical concerns.
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.
3. Doesn’t outline assumptions.
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.
4. Hasn’t highlighted existing unknowns.
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.
5. Hasn’t shared potential ongoing costs.
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.
6. Offers a proposal with a significantly lower cost or shorter timeline than other shops.
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.
7. Has an ill-defined process.
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.
AppIt Ventures’ Process:
1. Discover: The purpose of the Discover phase is to determine if AppIt is a good fit for your business needs. During these initial meetings, you'll connect with a member of our sales organization to review your business goals, technical requirements, project timeline drivers, and any necessary budgetary restrictions.
2. Design: The purpose of the Design phase is to expand upon information gathered during the Discover phase to set the creative direction of the project and map out exactly what we'll be building during the Develop phase. Our team works alongside you to capture your ideal application user interface, user experience, and tone in the form of clickable, high-fidelity designs and written requirements that bring your vision to life.
3. Develop: Our team will develop your application to the exact specifications laid out in the clickable designs and written requirements we've agreed upon together. By this stage, the project scope, timeline and risks have been identified and reviewed. During this part of the process, our team will work according to the development schedule set in the previous stage and will provide regular updates on progress.
4. Deploy: With development complete, the final project phase is Deploy. This includes all launch-related tasks following code complete. AppIt will assist Client in deploying software to the live production environment, provide a 30-day warranty period and facilitate project knowledge transfer to Client team.
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.
.png)
