SaaS vs build: how to reduce the time and the cost to develop an app?
Mobile Marketing

SaaS vs build: how to reduce the time and the cost to develop an app?

SaaS vs build: how to reduce the time and the cost to develop an app?
Denis Bondarev
Head of Content at InAppStory

A business that develops digital products often faces a dilemma when adding new functionality: is it worth integrating a third-party solution or creating it yourself from the very beginning? In this case, many questions come from "what is cheaper?" to "which choice is more efficient?" We have evaluated this dilemma from different angles based on an example of embedding Stories format to a mobile application.


Pros & Cons When Calculating Cost to Develop an App


Like everywhere both options have their own benefits and weaknesses. Developing a solution in house – by creating a product feature, integrating it into the app, and customizing every pixel up to your needs - you can make everything as native as possible and fully identical to your core product. This is especially the case when it provides a company with a unique competitive advantage.


Moreover, it gives full control over the process, and helps to get all things done by your own team of engineers and designers. If there is a gap here, then the process will be much more costly – in terms of cash, team efforts and time to market. 


Buying a third-party solution appears as a much simpler, faster and less expensive option. All you need is to find a SaaS solution that is compatible with your infrastructure and negotiate the best possible commercial terms. However, there is often a misconception and a lack of transparency for decision-makers inside the company to partner with a SaaS provider.


We’ve heard these doubts from our partners a million times and came to the conclusion that the proper choice should be always based on fact checking, planning and the optimal use of resources. If the process turns out to be too long or too expensive, then most likely the whole performance of the product would be questionable, especially in the highly competitive and dynamic environment.


What choice to make


Based on our experience, we have identified four elements that should be evaluated first prior to making a decision. These are: the cost of launch, the cost of maintenance, the time cost and the team motivation. All of these should be definitely considered by any company with the intention to add the Stories format for a mobile app.

Launch and Product Management Cost


Building a product on our own assumes investment in the team as the main cost. If we evaluate the Stories development cost separately for an MVP and a full stack solution - then we end up with $60K and $380K+ respectively. We have calculated this based on the real technical requirements from our product development, the minimum resources needed to engineer and average market salary rates.


MVP and full stack service development costs
Source: Inappstory


Cost calculation of Stories custom development


On top of this you should consider the cost of the customer development, beta testing, product management, as well as interim discussion of multiple hypotheses and development plans, which would involve many participants. Here is a red flag for many teams. But there is more to one-time building a proper solution: once integrated you need to invest constantly to maintain it up to the permanently changing customer and market environments.  

In contrast, if we talk about the embedding Stories with the InAppStory platform, then the monthly fee for using a full stack solution will be hundreds (and maybe thousands) of times cheaper than your custom development, and you will get all the benefits much earlier. At the same time, your own team will be completely focused on developing the core product which is essential to the long term success.


Maintenance Cost

While making a decision, you need to keep in mind that the team efforts would not stop after the launch. Most likely, a need to customize, invent or change something comes soon after you start using the product and collecting real feedback from your customers. In our case it could be a need to add such features as animation in preview, personalization settings, polls widget or audio player. Great things require constant improvement and ‘try and go’ approach. Otherwise, the product will quickly become outdated and you will end up with customer churn and a sunk cost. 


On the other hand the constant development requires to update the backlog with new tasks related to the specific solution, and allocate dedicated team members to support the project on a long run. Last but not least, your engineers should always track and monitor the “Stories” project in the task manager.

Based on the average salary rates and our real product plan, the monthly costs on adequate support of the Stories format will be approximately $30K per month. And this figure does not account for hosting and DevOps costs that should be considered separately.


While choosing a SaaS solution, all maintenance and support costs are usually a part of the retainer. You have no need to invest extra, diverse focus from the core product and at the same time you have all the benefits from the regular product updates.


InAppStory revision plan for 6 months
Source: Inappstory


InAppStory 6-months product milestones


Time Cost

It’s obvious to say that time to market is crucial to the success of any product or marketing initiatives.  

If the management has already decided to add Stories to a mobile app, then nobody wants to wait 3-6 months before the first campaign in the Stories goes on air. This is the approximate period of the MVP custom development – from the first kick-off team meetings to the numerous approvals  of proper interface customization in the application. It will take much longer to go to the market with a full stack solution. Just consider the value of time here. 

As many other SaaS, embedding SDKs of InAppStory usually comes very fast and takes no more than three days. Imagine and compare the progress of your own development team for the same period. It’s unlikely that they could evolve further than general understanding of necessary resources and allocation of product management.

Time is the most valuable factor of success today. By launching the Stories earlier than others you could start capitalizing on better customer engagement and app usage not losing a second.


Team Motivation


Most likely, the team of engineers that need to support the Stories functionality are busy enough building out your core product. In our experience, nobody is excited to collaborate on the projects of secondary importance and with conflicts to main tasks.


In the case of buying a SaaS there is no conflict of interest. You have the all-in-one solution with regular updates. If something is missing and needed all you need to do is to give proper feedback, prioritize and describe your requirements. Most often such feedbacks form a basis for the SaaS product pipeline. This makes life easier for everyone involved. And your team could spend their time on core product development and quick testing of marketing campaigns. 


The Choice is Yours


Product development decisions are most often based on pure pragmatism, and in business this is the only adequate approach. Ask yourself – do you need to develop another difficult solution if you can buy a ready-made one for a fair price? 


Perhaps you will be likely to believe that the right choice for your company will be custom development, that the above arguments do not work against you, and the cost to develop an app in your case will be different. Of course, many app blocks should be engineered by companies on their own, especially related to core product functionality. But this is hardly the case when you are considering embedding Stories. Be smarter, not harder. Join S7, WWF-Russia, Dodo Brands, and others with us.


The choice is yours. We only recommend evaluating all factors, being sensitive to the math and rationalizing relevant arguments before you make a decision.


Want to write for us? Check this