What we do

We design and develop software for Android, iOS and mobile web applications. We are happy to offer concrete solutions for the following tasks:
  • App development
  • Development of mobile frontends
  • Project management and prototyping for web, backend and API
  • Mobile app concepts
  • Technical consultation for apps and software
  • Business concept consultation

Our first job: to fully understand what you want

Whether you’re looking for a completely new concept or you’d like to further develop an existing app – or if you need help with a last-minute fix before a release:

We see the product from the customer’s point of view. We want to know what your work process looks like. How will the app make the user happy and take your business a step further?
That’s why first we just listen.


We use a workshop to zero in on your vision for the product

Through sketches, mock-ups, initial design drafts and a list of the most important functions, we develop a basic app. This also enables us to define the minimum viable product with which the app can go to market.

Alongside this will often be an extensive feature list containing extensions of the core functions as well as nice-to-have features. These can then be sorted according to priorities and content-specific requirements, and can be planned as updates for future versions.

We’re happy to get on board with existing projects

You’re in the middle of a development process but something isn’t right? We’re here to support you with an app development process that has already begun. After a situation report, we offer detailed advice on the next steps to take. We can also completely take over a project that’s in progress and bring it to a successful conclusion.

Whether you’re taking your first steps or crossing the finish line, we’ll ensure a regular and open line of communication. We’ll show you where the project stands, and give you feedback on our interim steps and decisions.

App success means continuous work

The launch of an app is the beginning of a process. Apps need constant maintenance in order to adjust to recent developments or new versions of operating systems. As a rule of thumb we anticipate that the first year of technical maintenance will equate to around 20% of the original scope of the project.

Naturally, a client’s needs can also change, for example in reaction to user feedback. This is why we offer you a contingency of work days in the maintenance phase for the purpose of adjusting the app. With the Kanban method you’re flexible when individual features or bug fixes need to be taken care of and passed on to the user.


An app needs time and money

We’ll talk to you openly about the length and the costs of a project. Because we provide realistic time management and first-class quality, we always establish all of the project’s requirements at the very beginning. One thing is for certain: every project comes with its own surprises. For that reason, communication and transparency aren’t empty words for us: we never leave our clients in the dark.

The question, “So how much does it cost?” is one that we can answer only after conducting a detailed assessment. As a point of orientation we can say that a project that costs less than 30,000 Euros is the exception rather than the rule. If a four-person team works on an app and the relevant backend over several months, then you can expect a monthly cost of around 60,000 Euros. With our agile fixed pricing policy, we combine financial planning security with the best methods of delivering good software. Ask us!

Usability check vs. going in blind

We work with prototypes, test product elements, an existing product or general usability and user experience at the beginning. In the development phases we use a range of methods: wireframe and prototype tests, user tests, heuristic evaluations, interviews and surveys.

In this way, we identify strengths and weaknesses and make sure the app fits perfectly to the user.

How we work

We don’t work for our clients, we work with them. We listen and understand as well as advise. We’ll share our knowledge and develop concepts that work for you and for your users too.

For us it’s not about trying to charge you for as many work hours as possible: We want to be part of the project, part of your development, and to produce apps and applications that we stand behind one hundred per cent. We’ll find the work processes that suit your project. We prefer an agile approach, we can use Scrum and Kanban – but we also know that those things don’t always fit. Just quickly throwing together an app for as little money as possible – that’s not how we operate. Our apps have solidity; they are built to last.

How does an app project actually happen?

As so often in life, the answer is: It depends.

Let’s look at a new project.

This is where we begin from scratch, a true greenfield project. But instead of long grass and meadow flowers, think coffee and mind maps. We establish the steps we need to take, we analyse the existing infrastructure, get to know your users and together develop a clear goal.

We work with the Scrum method using an agile approach. That means that we’ll present you with the pre-defined milestones in snack size—or as “sprints”—and then work forwards with clearly defined steps.

We’ll come up with a software architecture concept and blueprint for you. And if necessary we’ll develop prototypes, or proof of concept: So that it’s passed the reality test well before we get started on development. This is important in cases where, for example, new hardware needs to be added into the mix. Even if your concept is ahead of its time an extra level of insurance can’t hurt.
Every two weeks (at the very least) we’ll hold sprint meetings and discuss the next phase of the project.

If your app already exists

When we take over already existing code, we first need to acclimatise ourselves to the concept and architecture. The other questions are generally the same as for new apps: What will the users use the app for? What are its strengths and what are its weaknesses? We analyse the status quo and give you feedback before going forwards. After that, the project environment will define our next steps. If there are only individual changes to make or error corrections, then we suggest using the Kanban method of project management. Apart from this, the process is pretty much the same as the development of a new app.

Whether it’s a new app or an already existing project, we hold to the same standards: continuous integration, automated builds, distribution through test distributors and stores or automated tests. That doesn’t say a lot to you? We’re more than happy to explain everything in person.

What does a long-term project look like?

We love to accompany projects from the beginning until… well, until when? We love to have clients with whom we can work together over a number of years. The release plan is the tool of choice to achieve a long-term project.

We work with you to establish important milestones, nurturing the growth of the app with the use of sprint goals and transparency. This is where we profit from our agile management. But for us, the release doesn’t mean the end of our work. An app must continue to work over time and follow developing trends. For this reason maintenance budgets should always be included in the initial project calculation.

Assured quality tailored to you

Quality tests and a structured acceptance process are very important but don’t necessarily belong in every phase of development. And every project, product and app has its own unique requirements.
Sometimes it’s important to regularly check general quality; sometimes it’s better to focus on individual important changes. In another project it might be better to build a prototype and to make sure that it has heart and soul.
And some tasks require a line-by-line, seamless cover through unit tests and a comprehensive integration suite.
The following key questions make for a good starting point:

  • Does the app work on different devices?
  • With different operating systems?
  • In numerous versions and with individual settings (Keyword: Accessibility)?
  • Is the app stable?
  • What about storage space, battery time or poor network connection?

It’s important to keep an app stateof-the-art, since they are downloaded and installed, unlike websites which can be continually optimised. Even an update in the Store can take days to happen, so the version that’s delivered needs to be highly capable and not suffer from dropouts or interruptions.

Ten questions to make sure you ask for what you need

We only start working after we’ve understood your product (in whichever stage of development). What is the app’s objective: greater comfort? Increased efficiency? Improvement of work processes? Which hardware should the app work with? In what kind of situations will the future user want to 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 hybrid 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 hybrid 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.

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.