How to Build an App in 6 Weeks and Speed Up Your Time-To-Market

In case you didn't know, it usually takes about 4-6 months to build a mobile app (roughly). And this is only the first version of it. Six months to build an app is pretty long and expensive which is especially painful for product owners who are trying to achieve product/market fit.

Over 10 years in the business of app development we've accomplished many applications. Some of them took less than six months to develop, and some of them took even longer. The scope of an app can vary greatly, and there are many factors that influence the timeline.

But from what we've seen, the less time you spend on working on an app, the fewer risks you have down the road. When an app takes 4-6 months or longer to develop, a competing application can gain a significant momentum, your customer needs may change, and you may miss marketing opportunities. Spending that much time and money on a product that nobody wants is a nightmare. But it doesn't have to be so.

Recently at Madappgang, we managed to deliver an application in only six weeks! The app is the Creator Connect marketplace where artists can sell their works for those interested in buying them. The application is composed of 163 screens and has a real-time messaging functionality. Donnavan Kirk, our client and the founder of Creator Connect was going to promote the app at the art gallery opening event, therefore we had such tough deadlines.

Building an app in six weeks was a real challenge, but we believe impossible is nothing. And now we'll tell you how to speed up your app development process so you could also benefit from fast time-to-market.

Velocity is a key Scrum metric which measures the amount of work a team can accomplish during a single sprint. Without velocity, it's impossible to plan sprints and set release dates. By measuring velocity you can forecast how many tasks a team can complete within one sprint. If it turns out that your developers run behind schedules, you can cut the scope, add more people to complete the project on time or even move deadlines. Measuring velocity lets you foresee the real timeframes of the project and set realistic deadlines.

To measure velocity you need to follow the Scrum process with regular sprint planning, feature estimation, and retrospectives. After the first couple of sprints, you will get a clear understanding of your team's pace and velocity and will be able to predict release milestones.

If you follow Scrum, you don't have to start a project with long upfront planning and writing documentation. The way the projects start in Scrum is with your team thinking over the initial feature list and breaking it down into tasks that fill up the backlog. This list of tasks is by no means final. It will change as you learn more about the app from your early adopters.

A backlog which is difficult to review and organize is a sign of a poor product roadmap. Without a well-thought-over roadmap, it's impossible to successfully drive the project forward.

According to the Scrum Guide, the product backlog is an ‘ordered list’ of everything that is known to be needed in the product. It is important to note that a backlog should be ordered, not prioritized. Ordering the backlog helps the team understand what should be done first and when.

To order the backlog you first need to define the most strategically important epics for your team to work on and put items related to these epics on top of your backlog. The team then moves these items from the product backlog to the sprint backlog. And now they have a clear understanding of what they need to do in the next sprint. As soon as you get your first user feedback, you can reorder your backlog items to address that feedback immediately.

A very useful tip is to list less-urgent tasks and put them in a separate backlog. This will help you keep the product backlog limited to the most important items.

Try to evaluate your backlog order regularly. Because the main idea of Agile is to have a living document that reflects the real situation here and now.

As a product owner, you most likely believe that every feature in your app is essential. After all, you want to make a great solution.

But to successfully implement the first app version you need to remember Pareto Principle or 80/20 rule: 80% of effects come from 20% of causes. You have to focus on those 20% and sacrifice 80% of other things.

When you start thinking like that you will find that you can strip so much out of your product!

Be honest with yourself, be honest about your customer real needs and listen to your team. Your first product version doesn't have to be perfect. It has to collect user feedback and get improved based on that feedback.

The faster you get your app out the door and learn from users, the better chances you will have to build something really valuable for them.

We included only the most needed features to our Creator Connect project, without which it would be impossible to deliver value to users. At the same time, we had to put off a list of other desired features until the next release to make it possible to deliver the app in six weeks. Our first version of the app didn't include payments, user following, push notifications, and had a simplified newsfeed, onboarding and image upload functionality. We've planned all these features for the following app releases.

When it comes to application development, you need to make use of technologies available on the market because they can help you speed up the process. Just keep in mind, some solutions can be hard to scale after the first release, and some technologies may not fit each other. You need to follow your team's recommendations as for the technology stack and not try to reinvent the wheel.

To build the marketplace for artists we used the following key technologies:

• AWS AppSync, GraphQL for serverless backend
• S3 with CloudFront for media storage with CDN included
• AWS lambdas (Golang and Nodejs) for serverless backend logic
• Identifo by MadAppGang for user identity services (login/registration/authentication)
• Invision for collaboration between development and design teams

Miscommunication is the main reason for failed projects. To build a product you want, you need to communicate properly during the course of project development. What does it mean to communicate properly?

First of all, the app's stakeholders who define a product vision need to be part of the team. We use Scrum methodology for app development and in Scrum being part of the team means participating in daily meetings, sprint planning, task estimation, retrospective meetings, and backlog prioritization. As you can see, being an active participant of the process goes far beyond moving tasks from left to right.

The role of the app founder in Scrum is a Product Owner. To perform this role well, you need to understand all the Scrum rules and procedures. If you're new to Scrum, we recommend this amazing book: Scrum: The Art of Doing Twice the Work in Half the Time.

In Japan, companies such as Honda, Toyota, and Nissan manufacture one luxury car every 17 hours on the average. Car manufacturers in Germany, such as Audi, BMW, and Mercedes spend about 57 hours to produce a similar luxury automobile. The average number of defects in 100 cars produced by German manufacturers is 78, whereas cars made by Japanese manufacturers have only 34 defects per every 100 vehicles. Why such a big difference?

The reason why Japanese car producers make fewer defects is in that they apply an iterative testing approach. When someone on a Toyota production line finds a defect, they will stop the whole production line and everyone will be focused on fixing that defect so it doesn’t occur again. At BMW plant, on the other hand, the defects in cars are fixed only after they come off the production line.

Unfortunately, in software development, testing is often done only after the app is fully implemented, just like at BMW car factory.

According to Jeff Sutherland, one of the inventors of the Scrum software development process, if a bug in software is fixed after six weeks from when it’s found, it will take 24 times longer to fix it than if it got fixed at the moment it was discovered.

This only means you need to start testing your software from day one. Your testing methods need to include both UI automated tests and manual tests for every build. A good way to automate testing pipeline is by using a continuous integration practice.

Working within limited timeframes requires you to be as efficient as possible. Every team member needs to be fully engaged in your project during the course of its development.

For example, you might already have the app design done before you hire app developers. If you outsourced design at another company or hired a freelance designer who is no longer available, you can run into many issues when you realize you are missing a screen, or need to simplify the user interface because you have stripped some functionality.

You can get blocked whilst you are waiting to hear back from your designer who might now be somewhere on vacation. To prevent this from happening, keep all teammates together, at least while you're working on the first version of the app.

People are not machines and anything can happen during your project. Your main engineer can get sick, or have some personal circumstances which won't allow her to finish the project on time. You need to always have a plan B.

At MadAppGang, we deliberately involve substitute developers to perform code and peer reviews at all our projects. This solves two problems:

1. An external review helps us improve our code.
2. If the main developer is not able to work for some reason, the substitute developer requires no onboarding time. She or he can quickly jump in and start to write code immediately.

This one sounds obvious. But when everybody on the team is keeping the same rhythm, you can truly archive outstanding results. To set a productive rhythm under such huge time pressure, you need your team to agree to work hard from the start. They need to feel comfortable that they may have downtime after pulling together and pushing hard.

I really appreciate our MadAppGang team who volunteered to sacrifice their weekends and free time, changed their schedules and pushed all their efforts to deliver the app in time.

Running a startup with an uncertain future is a stressful endeavor by default, so avoiding stress is not really possible. You need to find a way to deal with stress so it doesn't harm your mental health.

It's a good idea to find your own source of inspiration and keep it up each day. Exercise, take cold showers, eat well, meditate, try gratitude rituals – they’re all amazing for staying positive and dealing with stress.

An important thing is if you stop believing in what are you doing, don’t expect the rest of the team to remain motivated. You need to support everyone, be a good example for your team, and be a true leader. Leadership is challenging but it’s a great opportunity for you to be a better version of yourself. You've probably read or at least heard of How to Win Friends and Influence People. Some of the simple concepts of leadership mentioned in this book work really well for me.

Everything we are talking about here is really only possible with an exceptional team, one that has a well-tuned process and a real passion for their work.

Ultimately if you create a positive and trusting environment for your team, then good people will come, create together, build together and stay together!

Tell us about your experience in building applications. What’s your secret of building awesome teams?

09 January 2019