We want to know what it’s all about: questions and answers about app development
We will start when we have understood your product (in all situation). What is the goal of the app: increase convenience? Increase efficiency? Improve operations? What hardware does the app work with? In which situation will your future users open the app? What about speed, stability and data security?
1. What is the reason for your application?
More important than an extensive description of the ultimate aim is a short and to-the-point definition of the core use. If there is more than one, that’s no problem—apart from if that makes it more difficult to leave things out—see point 9*.
Should your application consist of different versions—for example a desktop version, a web version and a mobile client—then it’s important to know this as accurately as possible.
*The questions 2-8 are too important to hyperlink you to the bottom.
2. What do your non-functional requirements look like?
Tadaa. Question 2 and already things are getting “technical”. But it makes a big difference if your app should be able to deal with 10,000 users simultaneously, or if your user community will be about as big as a round of poker. The second possibility is much more likely than you’d think in B2B applications, and this doesn’t reduce the scope of use at all.
How quickly should the web service answer? How safe should the app be from dropout? Which backup strategies for data should there be?
They come under the “non-functional” category only because they describe the “how” of the app rather than the “what”. And they can have a big impact on how much work will go into the app.
3. Who are your users and what do they want to accomplish?
The question is essentially easy to answer – if you know what your app’s purpose is. The core usage of the app should fit perfectly to the inner circle of your target group. The future users of the app play an especially important role when the design and conception of the app are not yet finished.
We can determine if a particular feature is essential or just a nice add-on, according to the needs of the typical representative of your target group.
4. When should the app be on the market?
Are there deadlines? Or have these already been missed? It’s important to know when your product needs to be on the market. The milestones of the project will be oriented to this, as will the budgets. And it’s important for us to know if there are time constraints too: Is there a delivery promise you need to uphold? Or a trade fair, or a legally binding deadline for the project? Or does the boss of the project really want to finish it in time for their mother-in-law’s birthday?
If your project starts with a run-up phase and time buffers, then a completely different project plan is possible than if the project begins with time pressure. That moves the goalposts between nice-to-have and must-have.
5. Is there a fixed budget?
In an ideal world, there would always be all the resources we need for each project. Unfortunately however that’s seldom the reality—and of course we can work with that too. But when we know your budget beforehand, then we can usually answer the question as to whether an application is possible for a given price quite quickly. And if the answer is yes, then under what conditions? If the costs of an app are something that you’re in the dark about, then we’ll answer your budgeting questions beforehand.
6. Who will be working with us?
In brief: We need your support in order to transform an idea into a good product—a strong product manager or product owner, who makes sure of the expert background for a timely adjustment of priorities and who gives us feedback. Regular meetings—whether online or in person—help to keep everyone in the loop on exactly where the project stands at the moment, and to stop us running enthusiastically at full speed in the wrong direction.
7. What stage is your project at?
Do you have an idea that’s not yet completely a reality? Or are you already on the market with a successful app that simply needs to be adjusted to the current iOS or Android versions? Our range of service offers means that for every possible stage of a project, we can find the most intelligent point of entry. But with project stages, there are often subtle differences, somewhere between the concept arena and concrete implementation. When it comes to existing projects, we usually need to be able to have a look at the current source code.
8. Which platform is the right one? Which devices should be supported?
Android, iOS or mobile web? It’s often advisable to develop a new app to release on just one platform. Then the functionality, the design and the user acceptance can be improved before the app is ported onto the other platforms.
The feedback of the first real customers can oblige you to readjust your goals. Does the user accept certain limitations and do they use the built-in functions? Does the user understand the language that’s used? Are the international offerings sufficient? All of these iterations go much faster on just one platform.
9. Are you ready to kill your darlings?
Sometimes one gets hung up on certain ideas. We know that too, and we’ve also had to say “adieu” from time to time. It’s generally best not to get too attached to your favourite features in the app, but rather to know exactly what the most important thing for the app is. It’s better to go to market on time with an app that’s well tested, with the most important features fully developed, than to present an overloaded collection of features with quality and usage problems, because you couldn’t let go of your darlings.
You find that difficult? We understand, don’t worry, and that’s why we have experts in this: experienced relationship advisers who’ll happily help you to put these issues to bed.
10. Which technical basis should we use?
There are various applications that use different frameworks than the native platform tools of Google and Apple. Environments for a platform-independent application with native materials can be found for example on Xamarin, React.native or Flutter. Then there are the so-called cross-platform apps: a combination of native and web app.
All applications have advantages and disadvantages that need to be weighed up for your particular project. The choice between an alternative framework and a cross-platform app depends on numerous factors based on the requirements of your project, and all of this should be made clear at the start of the project. We’re also happy to advise you regarding a possible change of the technical basis. Our focus lies on native apps that are individually developed for Android and iOS and Flutter for cross-platform solutions.
Do you still have questions?
You’d like to know what a cooperation with Karlmax looks like in concrete terms, what a project with us feels like, how the process is – and of course also what it might cost? If you’d prefer to speak to someone in person, then please either give us a call or write a mail to office@karlmax-berlin.com. We’re already looking forward to an exciting project together.
