The Stages of App Development in Koala42
At the onset of each project, our clients ask questions of Life, the Universe, and Everything: How does app development work? How will we communicate? What kind of budget should we set aside? This article focuses on the first two questions, and the last will be tackled in a separate piece.
It’s not a strict rule for us to only accept projects where we can build an application from the ground up. Sometimes a company approaches us with an app that is already underway, asking us to finish it. We’re not terribly opposed to the idea – we understand that the client needs to carry on with the tech stack the app was designed in and cannot afford to throw the money they’ve already invested out the window. So we often meet the client halfway and take over for the missing part of the process. But for the purposes of this article, we’re going to take a look at app development from start to finish, and we’ll go through the following topics:
- The problem with waterfall methodology
- Why agile development works better
- Koala’s approach to app design
- The road to the MVP and beyond
- How we maintain collective know-how
- Communication with the client
- Testing deserves proper attention
- Releasing the app is not the end
The problem with the waterfall methodology
Some clients (most, in fact) still like to approach a software company with a project, announce a budget and ask for the date of delivery. They are usually very keen to put a definite ceiling on the final price.
What we like to explain to them, however, is that if we go with the software development process called the “waterfall model”, it will take months before they can lay their hands on a functional version of the product. In the waterfall methodology, an app is developed very meticulously stage after stage (analysis, design, development, testing), and each new stage is approached only when the previous one is considered complete. Also, the ambition of the design phase is to plan perfectly and account for all possible use cases, problems and pitfalls in advance.
App development is sometimes compared to building a car – and in the waterfall methodology, the developer is designing a Ferrari right from the get-go. For months, the client only looks at the app’s blueprints, and an actual test drive becomes possible towards the end of the project.
Why agile development works better
Agile development, on the other hand, is an iterative approach that moves forward in shorter leaps – sprints. Each sprint is a development cycle in itself, from analysis to testing, and it sets specific tasks and goals which are revised at the end (in 14 days). In an agile model, it’s impossible to say whether an app will be finished in three months or six. The client, however, gets a report at the end of every sprint, sees how development has progressed exactly, and if necessary, can adjust priorities or requirements.
Going back to the car metaphor, we don’t deliver separate parts one by one – the steering wheel, chassis, tires and car body. We give the client a scooter that can get them from point A to point B, i.e. a functional version of the product they can test with customers, and then develop it into more advanced vehicles.
The agile model accepts that project change is inevitable, so when we discuss money matters with the client, we generally agree that a flexible budget is good for both sides. The developer can then respond to change requests without hands tied, and even incorporate evolving new technology trends in their work.
Koala’s approach to app design
At the beginning of a project, the first order of business is to confirm the application’s concept and get as much information as we can about the functions it needs. The goal of the analysis stage is to understand how the client’s product works (or their processes, if the app is meant for internal use), what needs to be the core functionality and how the app can support the client’s “edge” over competitors.
As far as design goes, we pay extra attention to function already in the “scooter” stage. It’s our UX designer’s job to look at the logic of the app from the user’s perspective and build the experience with the interface in a way that results in a seamless journey.
When we settle on app design with the client, we transform it into a 1:1 visual representation – a UX prototype – which the client can click through, check all details and give feedback. It’s better to work out most features and intricacies at this stage, before we jump into programming. Large adjustments made later are tricky – not impossible, just more expensive and time-consuming.
The road to the MVP and beyond
Once the app is designed and confirmed, development starts leaping forward in sprints. At the beginning of each 14-day cycle we agree on tasks we are able to deliver within the timeframe, and at the end the client gets a functional demo on our testing server.
As mentioned above, our aim is to deliver the first functional version of the app – the MVP (minimal viable product) – as soon as possible. This “scooter” is then replaced by a bicycle with more functions and capabilities, after that a motorbike and finally the Ferrari, which may have been planned from the start, but it might as well be the product of dynamic collaboration.
Sometimes instead of a car we end up with a boat, because the client realizes during development that they in fact need the app to be something slightly different. But that’s okay. This is exactly what agile development allows for.
How we maintain collective know-how
Depending on the complexity of the project, we dedicate 1–3 programmers from our current team of thirteen. All of our people combined have extensive experience with technologies and programming languages, but we also keep robust collective know-how project by project, so that developers can step in for one another and sprint results are not threatened by illness or days off. We write our documentation in a way that allows for anyone to pick up where a colleague left off.
Communication with the client
Koala normally keeps in touch with clients on a daily basis or a couple of times a week. We can be reached on the phone, via messaging apps or by email. All requests are recorded in a detailed backlog that reflects the current status of the project. This helps us keep a track of all things agreed between us and the client.
Naturally, as the project grows and its functionality expands, implementing new features gets more complicated. Every change is made to a larger whole. Even seemingly simple things like moving a button to another place on the screen can take several hours, because it’s not a matter of cut-and-paste. The developer first needs to determine what parts of the back-end code will be affected by this change, then he needs to plan, execute and test. Sometimes the modification will cause wonky problems in a completely unrelated part of the app.
No matter what happens, we are always transparent about time spent on tasks, and we adjust task priorities according to the client’s preference.
Testing deserves proper attention
If the budget is limited when it comes to testing, we are unable to write scripts for thorough, automated tests. Manual tests unfortunately cannot scratch much more than the surface of the app and simulate any possible combination of actions that a user could make in the app.
It can then happen (and it does – Murphy’s law) that the app crashes in the precise moment the CEO is looking at it. Performing automated tests is always a plus. It’s important also with respect to regression testing, i.e. testing that detects problems in previously developed and tested parts of the software, after changes. Automation saves programmers and testers precious time and we definitely consider it a vital part of being able to deliver a top-quality product.
Releasing the app is not the end
After the app has been successfully tested and approved by the client, it is released – deployed to our production server and published as a web application or on mobile stores – App Store (iOS) and/or Google Play (Android). Whether it’s a scooter, bike or car, we’re not done with it the moment it’s released. We keep monitoring, fixing bugs, and optimizing in the wake of operation system updates.
After all, it’s a tool we brought to life, and it’s our responsibility to keep it running.
Apart from fixes that go without saying, we’re also happy to bring it to the client’s attention when technology progress presents a fresh opportunity or holds potential added value. Cooperation with clients can go on for years. Building long-lasting relationships is important to us, and quality always wins over quantity. That’s probably why the number of our projects keeps growing.
If you’d like to read more about what we do, take a look at our BLOG, where we post interviews with our clients or handy tips and tricks from the area of business and technology.