You've got a great idea, and you have feedback that your users will love it! Now, it's time to build it. Here are some items that will affect the cost of that build. We will provide a spreadsheet at the end that can help you ballpark overall costs.
The first thing we need to determine here is how do we reach your customers. Do you want to build a web application that users can hit from their desktops or as mobile applications on tablets and phones? For either or both of those options, the first step is the UI Design.
Many customers come to us with a clickable demo or mocked-up design that has been built by their designers. That is a great (and economical) first step into getting customer feedback before starting the development process. Designs give the development team a good idea for the flow through the application and what screens and data points will need to be built. If you don't have this design complete, we have designers to help get that design built. Mobile or web designs can take a little as 2 weeks to complete and 4-6 if there are multiple platforms and complicated screen flows.
Web Applications are ones that run in your customers' browser of choice. We have industry-standard tools that help us build dynamic applications that match the UI designs above. Tools like React and VueJS are the norm with developers today and allow our team to build applications to your specifications. Those web applications are usually responsive as well. That means that the web applications will render well on all devices. If you want to do extensive testing on all the browsers and platforms, your testing costs could increase by as much as 10%.
Native mobile applications on IOS and Android are a great way to go if you already have a web application or if you want to give your customers a more customized experience. The development costs to build a mobile application vs. a web application are very similar. We usually use hybrid development tools like ReactNative or Flutter to build early-stage mobile applications because most of what is built works on both IOS and Android. If you want to develop the applications in the native tools by Google and Apple, that will double your cost without much benefit. We only recommend this is if there is a critical piece of functionality that works on the phones that hasn't been implemented yet in the hybrid toolkits. There isn't much that the hybrids can't do anymore, so this is a rare case.
Do you already have an API in place to handle the data storage and core business logic for your application? If not, that will need to be built and connected to the applications discussed above. The API stores data like the user profiles, security requirements, secret sauce features (see below), transaction processing, notifications, and most of the other core features your application will need to be successful. The development costs for the API are usually right in line with the costs for UI above. So if you build a mobile application that takes 15 weeks to complete, the API is generally within a few weeks of that number.
Basic identity and security is built into most applications nowadays. It's usually a 2-3 week build for secure passwords, authentication tokens that expire, and user profiles. You can decide to roll your own here using standard OAuth protocols or use identity providers like Auth0 or Okta to do the heavy lifting for you. If you use one of those tools, you'll pay a little extra for the service, but it will help you save and secure all of your users' information. You will also get features like password updating, multi-factor authentication, and the ability to use other identity providers for login (GSuite, Office365, Google, Facebook, etc.). You generally pay per the number of users you have on the system. If you have 20k+ users, it could get a little pricey, but nice to let the experts handle security for you. Integration with a provider like Auth0 will take approximately 2 weeks to build. If you roll your own, you'll spend a few weeks per feature above, like multi-factor authentication or support for other identity providers.
The secret sauce is the core of your idea and where your differentiating value will come. It can easily take 50% of the initial build costs and much more over time. I usually look at all of the functionality that will be needed here and estimate each piece individually. I'll then go over that list of items with my customer to determine what is required for v1 and what can be pushed to v1.1 or beyond. A ballpark number I usually start with is between 15 and 20 weeks of work. It's hard to estimate not knowing the idea, but generally, it's about half the first release, and our first releases usually go 30-40 weeks of work.
Payments are critical to most applications nowadays. There are great tools out there to help with payment processing, like Stripe and PayPal Braintree. They help keep costs down with easy integration, and they handle the PCI Compliance heavy lifting in most cases. Usual costs per transaction for those include 2.9% + .30per trans for credit cards and a little less for ACH bank transactions. If you need payment processing in your app right out of the gate, that usually takes 2 to 3 weeks to build the transaction data model and integrate with the payment processors above. If you want to support other processors, it could a few more weeks.
If you gather a lot of data and want to present it in specific ways to your users, reporting will be key. Generally, we use elegant graph and chart components that work both on web and mobile applications, so that isn't a high cost. As with anything, costs will increase as the configurability and number of reports you want to present increases. Most of our customers start small and time box reporting to 1 to 2 weeks. You can easily double that development time if your reporting requirements are complex.
There are many ways to communicate with your users outside of the application. Email is the standard for web or mobile applications. We normally build that into cost estimates. You have other options like text messages and web or mobile native notifications. Costs for each of those go up depending on the number of different messages and the platforms. It could add 1 to 2 weeks for each notification source you want to add and a day for each additional message you want to send. There are also costs incurred for sending messages through SMS or notification platforms.
Many platforms utilize 3rd party integrations to pull or process data more efficiently or to get at data they can't get otherwise. These could include tools to support tax rates, lookup addresses, track locations/show maps, post to social media, and enhance searching. There are also tools to help your marketing/sales teams like CRMs that you'll probably want to support. Each integration could add 1 to 2 weeks to your development. They usually use similar technologies, but the data model and transfers are different per source. Many integration partners also charge a per request cost, so you'll need to take those into account when making the integration decision.
You have a few different options: Amazon AWS, Google Cloud Platform, Microsoft Azure, and Heroku (built on AWS). Heroku is built so you don't need a separate DevOps person to handle platform builds and maintenance. Pricing for any platform is similar right out of the gate. We look at specific features and traffic scaling models to see if one fits the models more cost-effectively 2-5 years down the road. Generally, we go with Heroku or possibly AWS for MVP releases because of the faster release cycles and lower cost to start.
The internationalization of an application is critical if you want to go outside of the United States. It's not just a new language you'll have to support; many factors are involved, including different currencies, taxes, address types, number/date formats, and Cloud Platform locations. Each locale supported could add up to 5% to the overall cost.
The developers will do a level of unit testing on the code itself. It is critical to test each feature and to run a broader group of tests on the entire application at regular intervals. This feature and regression testing is done by folks other than the developers themselves because it's always best to have a second set of eyes on a project. We have the testers do some manual testing, and we also have the testers build automated tests that can run continuously. Testing can run 25% to 40% additional on top of the development costs. Some early-stage companies choose to have their stakeholders do most of the testing to help with costs. This isn't ideal but can be successful on a tight budget. The risks of buggy software are higher, so we always weigh the risks and rewards with decisions here.
Someone needs to be in charge of the process and requirements as they are added or changed. Product Managers run the regular status meetings, own the requirements, gather feedback from customers and stakeholders, ensure we are on track with the budget, and ensure that the developers deliver the exact requirements. We recommend budgeting 10-15% of overall development costs for project management. This is an area where some companies choose to use their internal stakeholders to help cut costs. That can lead to budget overruns or misses in requirements, so, like with testing above, we weigh the risks and rewards with the decision on having a PM on the team.
Probably the biggest driver of costs for the first release (MVP) of your application is your appetite for features. Are you in the 'lean and mean' camp and go for the very minimum number of features to start getting feedback from your customers, or are you in the 'kitchen sink' camp where you want every single feature and to have them look as perfect as possible? Most startups are either down the middle here and want a good balance, or lean towards the 'lean and mean' camp. We advise our clients to go with the 'lean and mean' release first and budget an MVPv2 to implement that first round of feedback from customers. This reduces the churn of code and features in the first version that customers may not want or use and lets the team focus on adding what the customers want in v2. The 'kitchen sink' camp can spend 33% more on the first release of the product. In my opinion, that's a high cost for a release that doesn't have customer feedback implemented yet.
We've created a quick calculator spreadsheet to help give you a ballpark size on the type of application that you want to build. You can contact us anytime if you have any questions, or to help go through the estimation process with you, no cost to you!
