Costs to develop an app – part 2: Cost factors that matter

General phases of development

A complete app development process consists of more than just design and its implementation in code. An app project includes various phases and iterations, each of which influences the other. In this review, we focus on the development phase itself as an influencing factor on the overall budget (see blue phase in the image). A clear overview of this subsection will allow us to better allocate resources for each phase.

Our app cost examples from part I illustrate that even if hourly rates remain the same, the price can vary greatly from project to project. Especially in the first phase of the project development cycle, the working hours make up the main part of the total price. So development companies multiply the actual number of hours used by the developers by a pre-agreed hourly rate. Add maintenance costs and external services such as data storage, hosting, and maintenance, and you have a first rough calculation.

Calculating the price for IT services in general

Is the hourly rate of the involved vendors (e.g. project management, UX/UI design, and IT) the most decisive factor? Yes and no: you would certainly notice a significant price difference if you had one and the same app implemented under otherwise identical conditions – once by a company with headquarters in Silicon Valley, and once by a local medium-sized company in Southern Bavaria. But the hourly rate is not everything. The following variables also influence how agile and productive a development team will be when working together:

• Team composition and team dynamics (team size, setup of the in-house development team, freelancers, IT service providers...)
• The involved stakeholders', designers', and developers' experience
• Existing agile workflows in the team (familiarity with SCRUM methods, role allocation, reliant product owner, stakeholder integration)
• Existing development environment and state (e.g., does an existing (backend) infrastructure need to be integrated or adapted? How reliable is the existing testing environment? How much code needs to be refactored)?
• Existing UX/UI (how elaborate is the concept? Existing wireframes or finished UI design drafts? Should the design be custom or can we use UI templates and libraries?
• Planned feature set and scope
• Platform requirements (iOS, Android) and user interfaces (especially in IoT), agreed-upon requirements such as device, browser, and accessibility specifications.

These variables sometimes have an enormous influence on productivity. It, therefore, makes sense to take a close look at these factors in the first place, examine them critically, and optimize them again and again – both before and during the development phase.

How can development now be facilitated and accelerated? How do you build a user-centric product quickly? At this point, the agile triangle provides a good overview. It is a valuable planning tool and visualizes the objectives of software projects.

The Agile Triangle here's a video explanation

The model of the agile triangle shows the three parameters that determine a software project and its success. Span your project in a "triangle" between the three poles of budget, scheduling, and scope/solidity – three variables that are equally important in a software project. They are interrelated and influence each other through mutual trade-offs. In agile software development, the first two poles are usually specified in advance, while the more variable factor is the scope/solidity component. Here's an example: The cost framework for the development of a new prototype is capped and the go-live date is also fixed to a specific date. If budget and time frame are limited, only one corner of the magic triangle remains - the feature scope, which can be variably adapted. This adaptability is an important principle of agile work: If all prerequisites are met, development teams and stakeholders remain responsive, can adapt to changes, and create even greater added value for their users.

Features that might be a bit more costly during implementation

Earlier in this article, we determined dependency factors that affect productivity in general: Development resources, app complexity, platform constraints, etc. Now we will take a closer look at the feature scope. In every effort estimate, concrete features can be identified that are time-intensive from a development perspective and therefore tend to be more costly. These requirements often go hand in hand with higher effort:

• Multi-layered user systems and roles
• Browser compatibility (e.g. should older Safari versions still be supported?)
• Strongly individualized UI
• Native development for each platform
• Internationalization/localization requirements
• **Mandatory integration of unfinished/legacy APIs **(or those that are poorly documented)

Disclaimer: This list only serves as a first orientation. For each of the features mentioned, there is a wide range of implementation possibilities, depending on the specific requirements. You may also have noticed some factors here that were not listed: Is it more expensive to include device-specific features like GPS tracking? How elaborate are details like animations? What about performance optimizations? Does an app that runs on multiple platforms automatically cost more?

In many cases, specifications can also be implemented surprisingly quickly. For specialized IT service providers, this is where the real challenge begins. For them, the most important question should be: What is sustainable, well-scalable architecture which also delivers fast? If you would like to know what makes the most sense in your particular situation, please feel free to ask us for an assessment.

Workshops during the kick-off phase serve not only to clarify open questions. They can accelerate the implementation

Every project is unique. And every setup is different. We wouldn't do your project justice if we gave blanket advice at this point. Nevertheless, there are certain approaches that have proven to be profitable. In our projects, for example, MVP workshops (Minimum Viable Product) or Design Sprints have proven their worth during the kick-off phase. Both approaches serve to define the set of core features that create a maximum increase in value for users. For example, if you have an IT consulting firm as a partner, you will put the following aspects through their paces in the kick-off phase (among others):

• Targets and deliverables for the release: What should go in version 1.0? Will we have a Minimum Viable Product for testing purposes or rather extended market maturity?
• Team composition and workflows in the agile project: How will our collaboration look like in detail? How "hands-on" can the stakeholders be? Is there a need for clarification regarding our roles? Will we need other positions before we begin?
• Existing UX/UI: How concrete are user flows and wireframes? How solid are the user interface designs? Will we need customized design or can we use design libraries?
• Existing development environment and state: is there an existing (backend) infrastructure that needs to be integrated or adapted? How mature is the testing environment?
• Platform requirements and user interfaces (especially in IoT), constraints and side conditions: Device, browser, accessibility constraints, privacy, etc.
• Stacks, services and frameworks: How could a sustainable, well-scalable ecosystem look like?
• Savings opportunities: What really needs to be custom implemented, where can we take shortcuts without compromising quality?
• Running costs, hosting, services and licenses: What does the operation cost us per year?
• Schedule: What is a realistic development time? How many developers are needed?
• Perspective for after version 1.0: Who will continue to develop? How will in-house developers be involved and empowered from the beginning?

A solid kick-off with customized requirements workshops gets everyone involved on board. It also helps the team to explore shortcuts, set standards for good communication, and find a common focus.

In part II of our series about the costs of an app, we tried to clarify which factors have a decisive influence on the price of an app. Using the image of the magic triangle from the field of project management, our focus fell on the variable factor of the feature set. The highest goal for well-done software development is a consistent focus on those who sit on the other side of the screen. A good set of features that is coherent for stakeholders, the development team, and users is the top prerequisite for an app that offers real value. The right partners will not only quantify the individual costs. They also help you to find the best set of minimum specifications for your app. Once this hurdle is overcome, you have created the best prerequisite for rapid implementation.

Read on: in Part III of our series, we reveal the five most common cost drivers in app development and how to avoid them.