Have you been burned by app developers who couldn’t see your vision? Don’t get burned by outsourcing to a developer or development team who are only OK. Find superior service capabilities using these 5 Easy Steps for how NOT to get burned by outsourcing app development in 2019:
Step 1: Validate with Scope and Clarity in Mind
Step 2: Interpret Estimates and Pricing
Step 3: Choose the Right Partner
Step 4: Cut Your Search Time in Half
Step 5: Conduct An Interpersonal Interview
Step 2: Interpret Estimates and Pricing
First, a Note: The Tech Must Make Sense For YOU
As much as I wish we could say “You have a non-technical role, so you don’t need to care about the technology,” not knowing what’s under the hood can have very dire consequences. Think about when you’re buying a car:
Do you need your car to shave off 0-60 time by 0.5 seconds, be capable of operating in snowy weather conditions, or last for 10 years under normal driving conditions?
No matter your level of car savvy, every car buyer is expected to know the advantages and disadvantages of a car before buying it. If you’re buying a car, being an informed car consumer will lead you to become a happier car owner. The same goes for doing your research on technology when buying app development services.
Caveat alert: There is a lot of pizzazz these days being spouted about the latest greatest technologies. You may have friends in tech circles that will tell you have to use Docker, Aurora, VueJS, Flutter or whatever else the Valley is enthused about that day. But don’t get distracted: your focus should be on the reasons for the technology, not the names. Here are the questions you must ask your candidates:
- How will your chosen technology scale to what the product need 6 months from now?
- How will your chosen technology mesh with your in-house talent (if any?)
Let’s say you don’t have any techies on your team. If you’re hiring overseas for a developer to handle the whole build, you may (as many have) end up with a developer who recommends Java (especially in India). They may build a fine MVP, but is your plan to continue onward with those foreign developers 6 months from now, or will you be moving development stateside? I can tell you now that Java developers are becoming a rarity in the U.S. making the hiring of stateside talent for take over purposes both difficult and expensive. Similarly, you may have a developer that’s trying to get your MVP done on a lower budget and thus recommends WordPress to reduce development hours. That may be fine initially, but WordPress can be notoriously unscalable for certain dynamic applications, such as a budding social network.
Now let’s assume you crossed off task #1 and made sure your technologies make sense for the long run (let’s say you decided on a custom PHP + MySQL stack). But on the flipside, let’s say you have an in-house backend developer, and they specialize in one type of database development (NoSQL). This isn’t going to make sense, because you have to pick one, and you won’t be maximizing the skillset of your in-house team by going with the external recommendation. Similarly, if you have an in-house Swift or Java expert, you probably won’t want to hire a React Native developer, as there will be skill redundancy, leading to one very unhappy, underutilized in-house developer.*
*There is a caveat to this: I personally would rather hire someone that is honest about what makes sense for you and also admits they’re not as comfortable in that language, but has demonstrated an ability to pick up a similar language. Yes there will be more upfront costs for learning curve, but investing in character can be a high-ROI investment (more on this later in “Conduct An Interpersonal Interview”.)
Understand Software Estimates
As a business person, I need to know the cost to establish ROI. This is absolutely true. The problem is, even for the best app developers, estimates can be part science and part art. Having been on both sides of app development, I’ve learned that building something that hasn’t been built before comes with a level of risk for even the best developers.
Let’s think about a custom home: when you’re building a custom home that hasn’t been built before, it’s basically still a redesign. Under the novel-looking surface, a custom home has the same components underneath as any other home. Sorry to bash your million dollar home, but it’s barely more than a rearrangement.
Now compare that with app development. Real tech innovation, as the name suggests, can come from building something that hasn’t been done before, or putting together existing parts in innovative ways. The field is always evolving, and the mark of a talented developer is not the ability to know everything, but to be able to pick it up quickly and add new technologies to the toolset.
In cases where an app developer has already built an app that you enjoy, and you find yourself wanting something extremely similar to it, then the estimate can be (and should be) rock solid. For example, after we built https://topflightapps.com/portfolio/smarter-symptom-tracker/, there were multiple prospects that wanted a similar version of that, and we always delivered on time and on budget.
But in cases where there were more unknowns, like adding new machine learning algorithms, working with new APIs, or working with a piece of firmware that wasn’t built by us, we readily admit that we don’t always meet our mark the first time.
Based on my experience, here is what you can do to get the most realistic estimates possible:
- Best case: they already have something very similar in their portfolio. Second best case: they haven’t built exactly what you’re looking for, but they’re experts in your niche (for us it would be healthcare and fintech), and have built multiple projects that overlap with your scope.
- If it turns out there are unknowns, be open to a paid, exploratory discovery phase to turn the unknowns into knowns first–it’s a foolproof way to come up with solid estimates. This ask will oftentimes turn entrepreneurs off, as they think it’s considered “financing a developer’s learning” when in truth, this mitigates risk for both parties. It invites better developers through the door, while tightening up overall estimates. (And developers do not profit from a few hours of discovery – they only ask for this to land and increase the chances of success on the larger project).
- Dig up their track record from references or reviews to see if they didn’t disappoint on schedule and budget. In other words, if a developer has a 4-to-5 star rating on schedule and budget across multiple types of apps, that’s a great sign that they adapt quickly to new frontiers.
- Request an agreement to proactively communicate as soon as signs appear that initial estimates may be off. Accountability and proactive communication are more effective than you might think at reducing costs, because it allows you to make informed decisions together to resolve the “numbers creep” before any material damage is done.
Understand The Trade-off of Hourly versus Fixed Price
From an untrained eye, it would seem like there are basically 2 opposing forces: fixed price being better for you, and hourly as being better for the developer. But if you have multiple apps under your belt, you probably already know it’s not nearly that simple.
To understand why, you first have to acknowledge the complexity and risk of app development estimates (see “Understand Software Estimates”). Because of this risk, fixed price projects are oftentimes portfolio-builders for new app developers willing to eat that risk to gain some traction. In a competitive market for app developers, there will always be app developers that operate on fixed price to get your business, and there will be talented and established developers with a track record who will prefer to work with clients that pay for their time. And that’s because they can, and not because it feels totally fair.
But is it fair? In reality, it may very well be. Just because you’re paying hourly absolutely does not mean you’ll be paying more. By attracting better talent with hourly contracts, you may lower the overall cost with efficiency and quality of work. One other benefit of paying hourly, is that fixed price also means fixed scope. Fixed scope is nice in theory (making sure what you specify upfront is a 100% match with what you develop 6 months from now), but it contradicts what clients usually end up wanting. Hourly contracts allow room for re-interpretation and further clarification on requirements as we see the product come to life, thus keeping everyone principally motivated toward building the best product possible. In a fixed-price setting, this time would instead be directed toward negotiations on new scope versus old scope, and how to reconcile payment–not the best possible outcome for either party.
Now, if you absolutely can’t risk exceeding your budget (you simply don’t have the funds) then by all means your best play is to get a fixed price, with the understanding that timelines and quality will probably take a hit. That’s the tradeoff.
Remember, hourly does not equal a free pass for a developer to work without oversight. It is your right and your responsibility as a business owner to ask the developer for estimates and to expect accountability and proactive communication if they’re likely to be exceeded!
Related Articles on Application Cost Management
- Maximize Your ROI by Understanding the True Costs of Developing an App.
- Get close to your budget and know your numbers when it comes to design and development.
- Learn how to get the most out of your fixed price or hourly contracts.
Feeling confident about your budget? Read on: