Here’s the gist of it. Everything depends on your own risk appetite, your budget and the kind of control you want on the project. Price ranges (hourly) can be from $20 – $250. Project budget ranges can be from $10K – $1MM+.
It depends on how you approach working with the development partner, who you choose to work with (this depends on your risk profile), what your budget is and what outcome you are looking for.
We all have had experiences with contractors in our lifetime – no matter what the initially quoted budget is, by the end of the project, we have ended up spending more (fancy term being budget overruns).
McKinsey & Company found that “half of all large IT projects—defined as those with initial price tags exceeding $15 million—massively blow their budgets. On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Software projects run the highest risk of cost and schedule overruns”
The underlying question is “how much should I budget for this?”.
Our answer (it might sound flippant) has been that whatever you have budgeted for, budget for some more. Another way to look at it, whatever budget you have available, cut it in half and set it aside as your initial development budget. You are going to use up a large part of the remaining budget – trust me on this.
While McKinsey’s study speaks to larger projects, the underlying issues remain the same. The longer a project is planned for, the higher the risks and higher the chances of budget / cost overruns. In my experience, as time goes on and as soon as business users start seeing some development progress, new requirements come out of the woodworks, existing requirements are modified etc — in other words, scope creep occurs.
If you are looking to prepare for a larger project/undertaking, it is always easier to get budget approvals for a much shorter pilot project than it is to grab a larger chunk of the budget. It is always easier to plan for and succeed in a smaller pilot project and thereafter grab a bigger chunk of a budget. More on this later.
We don’t embark on a custom software development project unless I know what the ROI of this project is going to be. We typically go through a business justification process before such expenditures. More on this later.
The reality is that there are too many variables to determine how much custom software development should cost. Among other factors, it depends on which stage your business idea is in, what you intend to achieve with said custom software – in other words what business outcomes you are looking for, from embarking on this journey.
OK, fair question. Usually technical people have a good handle on this. For the non technical or business folks here’s a way that you could try to understand this.
Imagine that you work for a health plan / payer. You want a custom mobile app that helps your members see their claims, benefit cards, prescriptions, eligibility summaries, account data, find providers, see their coverages, health costs etc.
We are not addressing the question of “why do you want to do that” yet. So, let’s dive into what would determine the overall costs of creating this software.
Do you know how many members will be using the app today? This might be an easy question for you to answer because you know how many members your plan supports today. This helps your development team plan for that capacity.
Do you know how many members will using the app 3-5 years from today? This gets harder for you to answer as you don’t know what your company’s sales are going to be. So, you kinda sorta do a projection based on the last 5 years. Well, guess what? Software designed for use by 10 people is not the same as one designed for use by 10,000.
Do you know how many members would login to the app or would be using the app at the same time (concurrently)? Hard to answer isn’t it? Well, the same goes for your development team. A server that can handle only 10 users concurrently is not going to handle 10,000 at the same time.
Do you know how your members would find your app? You could say that your members would find you in the app store. Or you could say that you will send out an email announcing your app’s availability. Or you could say that your app will be suggested by your contact center .. etc. You see, your development team would have to plan for those cases.
Do you have any plans of improving the app? How would you make those decisions of improvement? Are your members going to report bugs or would you be analyzing your app’s usage and making those decisions? Your development team would have to prepare for those scenarios.
What platforms would your app run on? iOS? Android? Windows? Web? Each platform adds costs and has its own idiosyncrasies. Are you looking for a single code base (hybrid) or do you want native mobile apps?
Are you going to develop this in-house or use an external agency / software development company? More on this later.
Are your systems on premise, on the cloud or a mix of both? Are you expecting data to be shown in the app that handles all these cases?
How many screens is this app going to have? <5? 5-15? 15+?
How are you going to handle users? Are they going to simply login via username/password? Where is this data coming from? Are they going to have to create a username password again? Do you expect multi factor authentication? Do you want the app to remember user’s devices? Is there any social component to user login/authentication?
What kind of data are you going to store? What data are your members going to store using the app? Are there going to be any media files? Any images? Docs? Pdfs? Or is this just going to be structured data?
Considering that these are existing members, is their data coming from a single data source? Is it coming from multiple data sources that the app has to connect to? Would any part of member data come from 3rd party APIs?
Would member data updates need to be shared with one system or would that need to sync with multiple backend systems, CRMs etc? Does this have to be in real time or near real time?
Are you or your marketing department going to be engaging members? Are there push notifications for this? Considering that a large part of your data is PHI related and has to be HIPAA compliant, what kind of messages would you be sending via push notifications?
Is this app going to use or store any location data? Does it have to store or show any data when the phone is offline?
What level of security are you going to need? What are you offering your users?
Does the app have to connect with any outside devices (e.g. bluetooth, NFC based, beacons, FitBits etc)
You see, this is just barely scratching the surface.. And these are all questions that your development team (again, that can be in-house or outsourced) needs answers for. And I haven’t even gone into what each button, icon, screen of the app would/should/could do.
That’s what goes into custom software development.. Those are things that affect pricing of custom software development immensely.
Whether you should develop this custom software / custom mobile app with your own development team or not deserves another post by itself.
Obviously there are many benefits of having your own staff develop this custom software, notably, no additional budget approvals, no vendor selection processes, no vendor management overheads, external vendor risk factors, less project management overhead, less confusion, more collaboration, retaining tighter control of the development process etc.. More on this later.
Now, let’s say, for various reasons, you have decided to have this custom software developed by an external agency / software development company. There are several pros and cons to this decision as well. More on this later.
In general, a mobile app development project involves business analysis, competitor research, user experience design, user interface designs, application architecture and design, backend architecture design and development, testing, on premise or cloud deployment, marketing and analytics integration, production support (depends on what SLAs you provide your customers) etc.
Over years, we have found that there are a few kinds of software development companies / agencies. The same model follows whether these companies are on shore, near shore, offshore.
While evaluating who we choose to work with, we have, generally looked at and for a few parameters that include company’s client focus, what kind of projects they focus on, business domain expertise, development and quality assurance processes, their experience with cloud native development, the development methodologies they prefer to work with, their team experience levels, how they mix senior with junior developers, their project management and project organization methodologies, their communication style, continued/future support, their pricing and pricing model etc.
Who you finally engage with, of course, depends on your budget and risk tolerance levels. In general, if you cannot spend more than $100/hr, don’t expect the work to be done 100% in USA. The more senior a resource is, expect to spend higher.
We have found the hourly costs ranging from $10-$250/hr offshore through near shore through onshore. In general, the more onshore presence you need, the higher the blended rate is going to be.
Of course, you always have a variety of freelancers to choose from and work with. We have known some really, rock solid, amazing consultants over time.
Over years, we have noticed many online posts / forums discredit freelancers and the possibility of working with them. There certainly are pros and cons of working with freelancers and as my advice has been before, it is really up to your budget & risk tolerance levels.
You can certainly achieve success with independent contractors. The more mature and experienced a contractor is, the more your chances are of success. I have noticed that less experienced contractors need a lot more hand holding / overhead that I personally had time for (maybe you have more time and resources than I do).
Working with individual contractors that specialize in niche areas / products etc can be quite successful but you cannot expect them to know all the aspects of the entire project. Even if an individual contractor does know everything, it would take them longer to execute everything than it would take a team.
We have found that contractors that are freelancing as their side gig come with the maximum risks and almost 100% of the time, we have found projects to be stuck midway. They cannot take on larger development projects.
Of course, the risk profile with them is the highest.
Your mileage may vary. How to succeed with freelancers? More on that later.
Our observation is that these are firms that have been in business for a few years, their founders generally being principal consultants, have senior talent on their team with a very small mix of junior talent, have their share of war stories to recite, cannot generally take on too much work and each client represents a significant chunk of revenues for them.
The talent pool being of senior resources, they typically don’t need a whole lot of project management overhead, don’t have as many communication issues, do tend to be very opinionated, have processes inbuilt into their workflow, take the time to do proper quality control and can produce robust code.
Since they are focused on a niche, they tend to know that domain very well, have the right contacts to offload the tasks they cannot do e.g. a strong team of developers would offload their design tasks to a designer they are comfortable working with.
We have found that their ability to execute larger development projects really depends on the experience of their architects. Sometimes these firms do have strong, experienced architects and sometimes all the development staff have similar levels of experience.
With a strong lead architect/principal kind of talent, these firms do good work. They don’t have a deep bench so if a person leaves the firm or is unavailable, it usually has a major impact on the project. They also don’t tend to have a wide array of skills, but know enough people in their network to get the job done.
Of course, the risk profile with them is better than it is with individual contractors.
In our experience, these firms do an array of things including web, mobile, custom software development, marketing etc. These firms take a horizontal approach and tend to serve a larger industry segment.
Their principals are also leads but their team mix does seem to have a bit more junior resources (nothing wrong with that as that’s also why they are cheaper). They don’t necessarily have deep industry vertical or business domain expertise and when they do, the total number of talent with similar skill set are limited.
We found that they do have a bit of project management, communications overhead, don’t quite have as many deep processes to leverage, sometimes tend to have quality control issues.
It seems that they don’t have the business domain expertise so you would have to spend some time explaining the business details to them. The fact that they take a generalist approach does give them a broader skill set, but we have found that they don’t have the deeper experience needed for larger development projects.
They are a very good fit for taking on a broader initiative where you’d need the team to execute everything – design, development, marketing etc.
The risk profile with them is better than it is with individual contractors but not as good as it is with focused / niched software development firms.
These are firms that have been in business for decades, serve medium to large enterprises with most of their client base being medium sized businesses. If you don’t have a sizeable budget, you won’t get any face-time with these firms.
It’s understandable, as they have a larger spend on R&D, processes, certifications they maintain (organization and individual), marketing, thought leadership, business domain experts etc.
While their experience doesn’t necessarily guarantee your success it does guarantee you robust processes, methodologies, ability to leverage a deeper bench, wider array of skill set, brand names you can trust, viability and sustainability etc.
The risk profile is better than it is with smaller development firms.
These folks pretty much serve the largest enterprises and care about larger deals. These are firms that have been in business for decades, have a good mix of extremely senior and also very junior talent. They understand the value of robust project management, have various processes & methodologies in place, invest a lot in marketing and thought leadership, can produce structure, robust code etc.
Again, just because they are mature and have a stronger brand, it doesn’t guarantee you success. However, it does guarantee you that they have the requisite experience to get the job done.
The risk profile is much better here, but another kind of risk comes into the picture at this point. Is your project big enough to matter? Arguably with a budget in > $500K you will get some attention but can you blame a $5B company not to care much for a $100K project?
Sure thing – below is a table that gives you some options. Again, your mileage may vary 🙂
This really depends on what you are trying to accomplish. You could very well have designs done by a team (yours or outsourced), development done with another team, project management via your team or an outsourced one and could even have yet another team do the quality assurance parts.
We found that If you are looking for a soup to nuts execution of your project, a team structure like below does lend to success.
– Business analyst – 1 FTE
– Project manager – at least 0.5 FTE
– Tech lead – at least 0.5 FTE
– Developers – at least 2 FTE (what happens if 1 developer is out of commission?)
– UX designer – 1 FTE at the beginning, then partial involvement moving forward
– UI developer – 1 FTE at the beginning, then partial involvement moving forward
– Quality assurance – at least 1 FTE
Way too many times businesses skimp on various roles mentioned above. The expectations are that a developer should be able to project manage themselves, should be able to do the business analysis themselves, should be able to do testing themselves and should be able to “just design the thing”.
That *never ever* succeeds. Why? We can go into details of this, but More on that later.
This is probably the most debated aspect and I have my own opinions on this.
We have always felt that hourly billing doesn’t make sense for us. It simply doesn’t as that puts the risk entirely on us. We don’t know exactly how much time some task should take, could take, why it didn’t happen in that due time, whether we need to monitor every hour’s work etc. There’s a long list of things that we find wrong in an hourly billing model. More on that later.
This tends to be problematic as well as it shifts the risks entirely to the development team. While business users would like them to take on all the risks, there are severe repercussions of this approach. This is where people cut corners.
While preparing the fixed price estimate, a team would go through excruciating details of every aspect of the product before being able to produce a fair fixed price estimate. And to be fair to the teams, they typically do put in a buffer in their estimates (typically 20-30%) to hedge their estimates. Of course, this increases the overall budget.
Fixed price project estimates, in turn, leads to *finalizing* all aspects of the product being developed, up front. That’s precisely the opposite of what business users (or product managers) want to have in a new product development.
They want the flexibility of being able to make changes to the product as they see it coming “alive”, as new requirements are discovered, as they publicize the product within their organization, get feedback etc.
Some teams do provide the flexibility of exchanging new or changed requirements with existing ones but that also leads to more time and money spent on *analysis* of such change requests.
In the end, we have found that fixed cost projects always have a losing party.
Monthly Flat rate
We have found the most success in this model. This functions almost the same way as having full time employees on the team.
The development team works on a retainer for the month and puts in a minimum of 8 hours per day. Just like with your full time employees, we agree on functionality that we are going to aim to develop in any given week or month and track progress accordingly.
Typically, we would have 3-6 month agreements up front and pay up front to get appropriate discounts.
The costs are higher than having full time employees, but that’s understandable as you don’t have the overheads (typically 30%) or burdened costs associated with having full time employees either. Nor do you have to invest in their career planning, training etc.
How does one execute this? We have seen success if this starts with a fixed cost engagement first. In our experience, the best way to work together is to have a small fixed cost engagement with the development team first. This allows the business to see the quality of the development team’s work, the speed at which the development team works and it also gives the business team a taste of what it is like to work with the development team.
This fixed cost engagement lasts about a month and will comprise of the same team that’s going to be working on the project longer term. During this fixed cost engagement, the development team can also validate the working relationship with the client/business users and it lets them decide if they want to continue working with the business (not all working relationships work out and the best development teams usually care a lot about the working relationship than the run-of-the-mill development teams).
The above steps are how we handled budgeting for custom software development. As mentioned, before creating any custom software, we always go through an analysis of whether we need to create custom software or whether we can customize some “off the shelf” software.
Whether you customize off the shelf software or plunge down the custom software development path, your next analysis should be whether to use your own development team or whether you should use an outsourced team.
If you end up choosing an outsourced development team, analyze your risk appetite for that particular project, the overheads you can tolerate and the ROI you want from that investment before choosing an outsourced development team / partner. A lot of this governs and is governed by your budget as well.
Unless you are a software company (i.e. selling software is your business), more times than none, where feasible, we will point you to commercially available SaaS options that you could consider customizing (or at least consider modifying your business processes to map with the software’s out of the box features).
Our advice? If you want custom software development to solve your business problem, the total cost of ownership is always higher than what it would be if you were to customize an “off the shelf” software.