Rapid Development In Practice

The goal of Rapid Development is to build a product prototype that can be presented to a given target group and then confronted with market expectations with the lowest possible effort and as quickly as possible.

In the philosophy of Rapid Development itself, we can find many references to the Lean Startup Method known from Eric Ries’ book of the same title, because they are based on similar foundations and are intended to prevent, colloquially speaking, from drowning the budget for a product that no one wants.

Rapid Development in practice

Rapid Development, as mentioned in the introduction, aims to build a prototype at the lowest possible cost and in the shortest possible time.

Therefore, it is advisable to use ready-made technological solutions and plan work in such a way as not to waste time on unnecessary things.

Prioritization also plays a large role here, i.e. determining which things are the most important and focusing on them.

Here it can be useful to collect feedback on an idea, e.g. by creating a simple landing page with information. According to one of the main principles of UX / UI design, the user, after spending a few seconds on the website (or looking at the flyer), should have an immediate “WOW” effect – which leads to “I need it in my company” decision.

The sooner he is convinced of an idea, the sooner he will buy it – and if the feedback from potential customers is positive, then you can move on to real application development.

We build software

Rapid Development, despite similar assumptions, differs significantly from SCRUM when it comes to building an application in practice.

Scrum focuses on sprints, planning, retro and is a continuous process, you could say that it is a philosophy according to which a good, tested product is built.

Rapid Development, on the other hand, focuses on building something that can be presented to clients and investors as quickly as possible.

We forget about automation, technological debt – we focus only on what the client wants and what the investor wants to see.

It is advisable to use ready-made solutions (provided that it is legal), all libraries and tools to improve work – the goal is to quickly build an application to check whether the solution has a market future.

If it has, then after achieving the intended goal, which is usually receiving financing, we go to the standard, SCRUM application development and our prototype can be thrown into the trash – the lessons learned from its construction will significantly speed up the process and thanks to customer feedback we will know what to focus on and how to prioritize app features.

This is also the main difference between SCRUM and Rapid Development – SCRUM focuses on providing a tested product, allows for the constant, flexible and long-term development of the application, while RD delivers it quickly, with a low budget and for a specific purpose.

Rapid Development in practice

Now, after presenting the main idea of ​​RD, we can move on to the most important – how it looks in practice.

In the first stage, we start with the so-called Proof of Concept, i.e. presenting the idea of ​​the application literally on paper, along with its operation and potential use by the target group.

At this stage, nothing is programmed at all, but only the individual “use cases” that can be discussed with the client are written on a piece of paper – for example, what he thinks about such and such a solution and what value it would yield for him, and most importantly – if he would buy it if available. If so – for how much, if not – why.

The next stage is the prototype, i.e. a version of the product that already has some basic functions implemented but is not yet ready for sale.

The prototype allows for further tests and checking whether the product is developing in the right direction. As in the case of Proof of Concept, thanks to the prototype, we can collect feedback from potential customers and use it for presentations for investors.

The next stage is the construction of the MVP, i.e. Minimum Viable Product. It is a version that has only basic functions, but it already offers some kind of a solution for customers and is suitable for sale.

rapid development

Jumpilot - a textbook example of Rapid Development

One of the best examples of Rapid Development is Jumpilot, a startup from Sweden that deals with the so-called gamification of trampoline parks. The idea was to create small sensors that count the number of jumps and the flight time of park users, displaying the results live on the board.

The creator of Jumpilot, Wojciech Wdowiak, applied this technique in practice, in a simple and brilliant way – a group of children using the trampoline park at the moment received armbands imitating movement meters; the children were convinced that they were active devices, not dummy devices.

At the moment, of course, nothing was working yet, but the joy and involvement of children in competing with each other confirmed Wojtek’s thoughts that such a gamification system will increase the attractiveness of the park and thus make people come to it more often.

He then commissioned Oakfusion to build software, along with programming ready-made activity sensors. Using the Rapid Development methodology, a production prototype was ready after a few weeks, and after 2 months – a working version of the product – MVP, which was successfully implemented in several trampoline parks.

It all happened in a dozen or so weeks and for a fraction that software built from scratch could cost, and now the startup is where it intended to be – on the way to obtaining financing that will open the door to markets around the world.

See this case on our Clutch profile

Find the answer to the customer's need – no more and no less.

Rapid Development could be summed up in two basic terms – quickly and efficiently.

You can’t get carried away by a fancy fantasy, spending weeks working on UX / UI and even more time on unnecessary functions – no, with a limited time and budget, we focus on what the client actually needs (which we will learn by talking to him and watching his reactions to given situations).

In the product development itself, after passing the Proof of Concept step and colliding it with the expectations and needs of customers, we use ready-made solutions (and there are many of them on the market, often available for free) and available tools.

If you would like to learn how to build your product with a low budget and in a short time, please contact our specialist Adam Matusiak, known in the IT world as Rapid Development Evangelist, who has built dozens of startup products and willingly shares his knowledge (via the contact form or LinkedIn) and experience with young companies and startups building their products that change the world for the better.

Comments are closed.