mvp feature 3

Building a Minimum Viable Product | Prioritize features to fully achieve your vision.

In this article I am going to draw from our experience as Rebels and talk to you about a healthy practice that supported many of our clients in achieving product-market fit fast and with a demonstrated demand for it.

Specifically, I will try to demystify a myth about the MVP and its vital stage of feature prioritization, by showing you that, although this process entails starting off granularly, it does not require detaching emotionally from your initial idea, or diverting from the scenario that made you so excited in the first place.

On the contrary, by the end of this article you will learn that developing an MVP does not have to be a buzz-killer due to its overly simplistic nature. In fact, you will understand that the higher your ambitions, the more important it is to start with building a Minimum Viable Product.

Building a Minimum Viable Product idea

Start with building a Minimum Viable Product or struggle to deliver value with no strings attached!

No matter if you are a serial entrepreneur, or an emerging  founder, there is no doubt that you will always invest yourself in each one of your ideas. Besides time and resources, you will be investing passion which, as opposed to the first two, might be particularly difficult to limit.

Eventually, you will become emotionally attached to your brilliant idea, relentlessly envisioning how that small eureka moment, be it at the desk, at your favorite pub, or in a ridiculously random moment or place, will, one day, unfold in a big wave that will take over the world.

And we cannot blame you for that.


Because we know that this emotional attachment will be fueling your drive towards materializing that idea, allowing other people to experience what once was only a what if.

Building a Minimum Viable Product launch

Can a small MVP iteration contain your immeasurable hype?

To paraphrase from our previous article, where we have explained How to build an MVP, having a framework to formulate the essential features of your product is paramount. Beyond reducing the time to market, by periodically testing assumptions, you will also minimize the risk of wasting resources on functionalities that the users don’t need.

On top of that, working with incremental releases that will generate constant feedback will mean that instead of heavily investing in a stand-alone R&D stage, you will now have extra budget to support other crucial parts of the business, such as business development and even advertising.

Although we’ve seen founders preaching the Agile Product Development methodology, many of them are reluctant to begin their journey with a rather of their digital product  and optimize along the way.

In such scenarios, these founders do not engage in a process of feature prioritization, while pushing technology partners towards releasing a feature-crowded  product on the market. As a consequence, most early adopters become overwhelmed, choosing to go for something that is more  and comply to their needs, rather than their wants.

On the other hand, deciding to hit the market with a simpler version of the product would yield immediate value for both yourself, as a founder, as well as your target market. Not only that users will experience a shallow learning curve, but, by giving them time to adjust and learn your platform, you will ultimately set the context for building the product that you have dreamed of early in the process. Even better, you will build a product that your clients truly want!

"Simply put, building a Minimum Viable Product will have you shift focus from delivering what you feel would work, to creating what the clients will certainly enjoy."

Building a Minimum Viable Product feature prioritization

Prioritize to build what the users need.

Having collaborated with founders activating in a variety of industries, developing geo-location & navigation, property technology, networking, green tech and many other web and mobile applications, we came to a realization that we subsequently embedded within our ethos.

It became clear to us that, just as important as the actual development of their product, another crucial aspect of fostering a successful partnership relies in preserving the clients’ thrill throughout the entire process.

How do we do that?

Essentially, by getting our clients on board with the idea of feature prioritization and its impact on user behavior and ultimately revenue.

As you probably already know, there are a bunch of matrixes and methodologies that are often being used to map out the key features of a digital product.

If you are curious about that, we suggest that you look into the applicability of The Feature Buckets and The Feature Priority Matrix.

However, as we are collaborating with founders coming from various industries, we cannot really pinpoint just one method, since different products require approaching different perspectives.

Even so, while there is not a golden formula that we use for every client, when it comes to our feature prioritization process, we strive to establish it following a UX-first approach. Specifically, we start off by conducting extensive user research, iterating on user personas, aiming to map out their needs, motivations, frustrations and goals and then carry on with of them interacting with the digital product.

Listing the actions that the users will have to undertake to reach their goals will support our team in the next stage of the process. In this phase, together with our client’s input, we design the user-flows and create the actual interactions to ensure that achieving user goals will lead to fulfilling business goals. By doing so, we make sure, early in the process, to validate that the direction where the product is going is right and that it can flourish gradually.

Building a Minimum Viable Product UX first

Want a lovable MVP? Just go UX first!

It is no secret that, lately, the internet has been cluttered with plenty of nuances to concepts that should be rather straightforward. You have probably already noticed that, when searching for the term MVP, a few other variations to this term will pop up in the very first pages of the search engines, such as Minimum Marketable Product, or Minimum Lovable Product, just to name a few.

While it is not a bad idea to be constantly in tune with the current language, we propose that you don’t fall into a void of useless jargon and, just like you are doing with your product, focus on what is communicating the most value to the target users.

Building a Minimum Viable Product that users will enjoy experiencing, a lovable MVP, should not be that complicated. All that you have to do is allow yourself to Prototype first and Fail fast, while approaching an UX-first mentality. This is what we have been doing in every project so far and what has provided satisfactory results for us and our clients. Developing products through an iterative user-centered design process and validating hypotheses with minimum effort.

"Now sit back, relax and watch the early adopters enjoying your MVP like it’s the 2.0."

No, building a Minimum Viable Product won’t dampen your enthusiasm.

Starting off with a minimal version of your digital product idea doesn’t have to kill your enthusiasm. Indeed, you will have to nurture some sense of objectivity in order to map out the essential features, but, in the long run, this approach will only ensure that you are well on your way towards delivering on your users’ needs and ultimately add those extra features.

Sort of like first bake the cake and then put the cherry on top. 😊  

🚀Ready to start working on your own MVP? Get in touch and let’s explore your product idea together!

Agile Methodology for startups

Agile Methodology for startups and enterprise companies.

In this article, we are going to talk about Agile Development and its advantages and disadvantages in comparison to a Waterfall approach. We will give you enough insight to help you decide on the best plan for your next big digital product.

Before getting started, we feel it is important to give you a quick overview of our history and expertise as a company.

RebelDot started as a tech subsidiary of a large product company in Washington, the USA, in 2008. For a few solid years, we worked on building digital products for large & renowned insurance companies, as well as Fortune 500 companies. We spent four years perfecting and solidifying our approach to building digital products. Later in 2012, we decided that we wanted to use our product knowledge and experience in helping companies, startups and enterprise, accelerate their way towards digitalization and technology innovation. Fast forward today, our cross-functional teams have helped more than 50 companies bring digital products to the market.

Today, we are lucky enough to have experienced a lot of different scenarios and approaches when it comes to building products. Our interactions with various companies & business scenarios have once and for all showed us the importance of being Agile when it comes to both startups and enterprise companies.

What is Agile Methodology?

Before getting any further with Agile Development, let us take a look at the meaning of it.

AGILE = the ability to create and respond to change. A way of dealing and succeeding in a fairly turbulent environment; the ability to adapt.

It is our understanding that the authors of the Agile Manifesto went for Agile as a label for this idea because the word represents adaptiveness, which is so important to the entire approach.

Translating this entire concept of agility into the product development world, we see how being Agile means adopting an iterative approach to product management and software development, helping teams deliver value for customers at a fast pace.

So instead of big reveals and big bang launches, an agile team develops in small iterations. Product roadmaps, requirements & features are evaluated continuously, creating a natural mechanism for quick response to change. Pretty cool, huh?

Customer feedback is extremely important in building digital products following an Agile approach, and both testing and development are done based on customer feedback and response.

Agile Methodology & Waterfall — which one should you choose for your digital product?

While Waterfall is a linear model for software development, Agile is an incremental and iterative approach to building software. Although with more recent history, Agile development has gained a lot of popularity, especially in the technology startups scene, where openness to change and adaptability to market demands is vital.

Below are a few of the most important points you should take into consideration when having to choose between Agile and Waterfall for new product development.

Taking a quick look at the history of Agile Development, this new methodology came to solve some of the most evident problems and challenges product teams faced when following a Waterfall approach.

Customer feedback & being open to change.

Planning to launch new digital products in today’s ultra-competitive technology scene, needs to come with an extraordinary ability to adapt to change and customer feedback. If you have been following us for a while, you know we place great emphasis on customer feedback for an important reason: it helps stakeholders make sure that what they build responds to real customer needs. By encouraging incremental development, agile development provides a framework for avoiding big product reveals after immersing in months, maybe years of development.

Agile development helps stakeholders prioritize the features that they want to include in their product, by encouraging product teams to think about the challenges and the problems the digital product is solving for the market they are launching on.

While a Waterfall approach places great emphasis on extensive planning before immersing into development, being Agile might mean you are not 100% sure of how the digital product might end up looking. Still, you are sure that what you build is what your customers want

Does being Agile mean less financial predictability?

Short answer, yes. Still, you will be surprised to find out how less budget predictability might work to your advantage. Here’s why:

You have a great product idea, that is (we hope) based on a problem you have identified, and you wish to solve for your customers. For the sake of this story, let’s assume that you are planning on building a platform that aims to connect artists with art collectors with the scope of purchasing art pieces. The main and first to be developed features of your digital platform will be centred around solving this exact problem: creating a way for art collectors to connect with artists. Now, you might have an idea of other interesting features that might suit the purpose of your app, but you can’t know for sure if these features add value to the entire experience of your users. Following an Agile methodology, you will release the first version of your digital product or an MVP, collect feedback from the way users interact with the applications, and only then decide on which features will go into the second version of your digital product.

Since there is no full visibility over the entire product roadmap, development teams will find out it is almost impossible to accurately estimate the entire development effort of your app. Instead, they will create a ballpark estimation, highlight the minimum effort for developing your app as well as the maximum amount of effort, with the mention that if the scope of the application changes, the estimates will end up being changed as well.

Let’s think of the same business scenario, following a Waterfall methodology for product development. We would look at all features imagined for this specific digital platform and estimate everything with greater accuracy.

The risk? Since in the case of Waterfall product development, customer feedback is deferred until very late in the project, you might fall into the (very dangerous) trap of building a product that your customer base doesn’t need. It’s because you build on assumptions and not on real feedback, as in the case of Agile Development. So, you end up having a clear overview of the entire development effort that might end up being pointless once you realize your customer base needs something else. Getting into changing the whole system is like jumping into a pitfall.

Time to market.

If you wish to place a product on the market as soon as possible, then, without any doubts, Agile Development is the way to go. Encouraging feedback based iterations and incremental development, and Agile Development team will advise fast releases, followed by rapid improvements.

In the case of the Waterfall Methodology, you might have to wait for months and years to have your product on the market.

User Learning Curve.

Although there’s not that much discussion around this topic, our years of conducting development for companies have shown us another important, user-centric aspect when it comes to Agile product development: fast, and incremental releases help users adapt to the behaviour of your mobile or web application on the go. You want to first launch a product with fewer features, slowly upgrading the experience to ensure a short learning curve for your users. The more seamless and minimal the first version of your product is the higher the adoption and usage rate.

To better illustrate this, let’s take a look at Facebook and the eight main features of the first version of the app — released in 2004:

According to Adam D’Angelo & Business Insider, they are:

  1.  User accounts (with real names required), restricted to email addresses;
  2.  Friends, including friend requests;
  3.  Invitations (no contact importer; you had to enter each email address individually);
  4.  Profiles, with a single photo for each user;
  5. Ability to list user metadata like gender, birthday, dorm, phone number, favourite music, favourite books, “about me,” courses (structured);
  6.  Search by name, class year, courses, other metadata;
  7.  Some privacy restrictions to limit who could see your profile (friends only, only people in my class year);
  8.  A feature to visualize a user’s friend graph, which was later cut.

Today, Facebook is a sea of complex functionality that takes a lot of time and energy to learn, and reaching this level of complexity required a lot of user feedback and analyses that are still undergoing.

Placing an over-complex, feature-crowded product on the market with giving your users time to adjust to lear your platform will eventually kill your user base.

To build or not to build a Minimum Viable Product.

As an Agile Development team, we encourage startups as well as enterprise companies to first build a minimum viable product (MVP). 

Being Agile will help you identify the problems you wish to solve for your customers, before identifying the features. 

We know how tempting it is to talk about the killer features and functionalities of your new product but make sure not to hurry into this. We’ve seen a lot of entrepreneurs who just want to go out and build a bunch of things without a clear objective, and that’s just money thrown out on the window.

Nonetheless, an MVP is a huge part of being Agile. We covered everything you should know about building an MVP in this article about  how to innovate with minimum viable products and rapid customer feedback

We hope this article gave you a good overview of what it means to build digital products — the Agile way. If you feel like there are some aspects we did not cover,  reach out and we’ll be happy to spend time in conversation with you. 

minimum viable product

Minimum Viable Product | How to innovate with rapid customer feedback.

In this article, we are going to shed light over what an MVP is, how to innovate with Minimum Viable Products, why you should start with an MVP, and we’ll help in finding out how much your first version of the product might actually cost you.

Having been in the world of digital products for more than a decade, we had the opportunity of interacting with an impressive number of entrepreneurs looking to bring innovation to their sector. We’ve seen established businesses looking to digitalize their processes with the help of technology, enthusiast startup founders at the beginning of their career investing all their time and money into building something successful and, last but not least, serial entrepreneurs already accustomed to the startup scene, trying to make their way through the competitive world of technology startups. 

The clients we interacted with differed not only in their entrepreneurial journey, but technology understanding and business scenario. Hence, it became pretty clear that when it comes to helping business owners bring new products to the market, a one size fits all approach fails unquestionably. Processes are good, but we’ve learned it is just as important to know when to put them aside for the sake of immersing into the particular business story and scenario.

In a world of adaptability, flexibility, and particularities, one thing remains true. For a startup to have any chance of launching a successful product, research, and MVP (Minimum Viable Product) creation is mandatory. Aaaand, we couldn’t stress this enough. 

In this article, we are going to shed light on what an MVP is, why you should start with an MVP, and we’ll help in finding out how much your first version of the product might cost you.

What is a Minimum Viable Product?

A minimum viable product is the first version of a product that contains enough functionality to satisfy the early adopters of your digital product, while collecting valuable feedback from the market.

minimum viable product

An MVP comes to help you validate your idea early in the process of product development. In the case of Agile Development, it should help your product team validate and iterate your product based on input. 

Taking a straightforward look at the entire Minimum Viable Product concept, you want to test the market with a first, minimal version of the product, to make sure that before investing a lot of money into more design and functionality, your idea is validated and approved by the market. 

Why build a Minimum Viable Product?

Although we already touched down on one of the most important reasons for building an MVP, which is, validating your product idea, we are going to shed some light on other important aspects of why you should start by building an MVP. 

We’ll start by reminding you that Rome wasn’t built in a day. The legend says that builders were there laying brick-by-brink, every day. Just the same, we advise owners to look at the MVP as being a process and not a product. Building an MVP is a journey that allows you to test, optimize, and grow your web or mobile applications in sync with market demands. Listening to what your customer’s desires and wishes are is probably the most important step of the process. Translating all this valuable input into features and functionalities is where the fun part begins. 

A Minimum Viable Product gives you the framework to essentialise on the features that have the most priority in alignment with the problem your product aims to solve. Let’s say you are planning to build a product that gives dog owners access to online dog trainers. Although you might have tons of ideas on how your product should look like, it is important to identify the core functionalities of it. A live chat might be a correct answer for this specific use case. It is important to remember that an MVP is a first release that is stripped right back to the core of the digital product, and you should keep it like this.

An MVP saves great amounts of money that could go into the prelaunch advertising of your product. Because building in small iterations is all that an MVP is about, releasing a small version of the product, testing, and improving on feedback helps you not fall in the trap of investing money into functionalities users don’t need.

minimum viable product

How to build a Minimum Viable Product

Now that we have touched base on the theory behind building MVPs let’s take a look into how to build an MVP

  1. Start with identifying the problem you are solving for your customers.

If you’ve been in touch with the product & startup world, this might already sound like a cliche. Still, it is the most important item to tick off your list before getting into building anything. 

Looking at some of the hottest startups, they all started with identifying a real problem, and engineered their solutions around that. 

  1. Research, research, and research!

It is important that you take the time to conduct extensive research on your buyer persona, competition, and the advantages their products bring on the market.

Find answers to some of the most important questions in product development: Why are you building the digital product? What is the problem that your product solves for the market? Who is your targeted market? Who are your competitors? 

  1. Identify the core functionalities of your product.

As you already know, as many interesting ideas you might have, the entire point of building an MVP is releasing a minimal version of the digital product, without adding too much functionality to it. Ask yourself, what is the single-most-important action that I want my users to accomplish? Then, categorize all features into nice-haves, must-haves and don’t care.

  1. Start working on user flows, user stories, and the user experience of your MVP.

With research as a strong foundation, it is now time to think about the user flows within your web or mobile application. You know what the core functionalities of your product are, so it is a good moment to think of the experience of the users within the app.

  1. Prototype!

The user experience of your mobile or web application is extremely important in the way your first users will interact with the digital product—imagine real-life scenarios of users interacting with your application and start designing with their expectations in mind.

Last but not least, add the branding elements of your company and think of ways in which to enhance your user’s experience with the help of colors, animated transitions, and interactions. Remember that to attract users; an MVP should not only be functional but delighting as well. 

Once you have it all done and ready, we advise you to gather all application screens and build an interactive prototype using InVision – this way, you will get a feeling of what the app feels and looks like. 

  1. Build measure learn – repeat. 

Once you have the entire app design in place, start coding your MVP. We recommend startups to make sure that the application screens that go into development are what they want, eliminating the risk of making major changes while in the development phase of the product development phase. 

Launching the first version of an application is just the beginning of the process. Placing it into the hands of your users will give you the feedback needed to improve the experience, making it even more existing and engaging for your users. 

minimum viable product

How much does it cost to build a Minimum Viable Product?

Before jumping to asking this question, make sure that you have done your research so that you know the main problem your product solves, your competitors, and, last but not least, your potential user base. 

Estimating the development effort for building an MVP gets even more accurate if you already know what some of the core functionalities of your application will be, as well as the complexity of the UI. 

At RebelDot, we make sure that before delivering any estimates, we have a very clear idea of what we are going to build and that we have immersed ourselves in the vision, goals, and challenges of the business we are dealing with. We do this because we want to be able to offer good financial predictability for our clients, especially startups that are, in many cases, seeking investment. 

The tricky part of building MVPs and digital products in general, is that the amount of money that they will end up costing you is highly dependent on the hourly rate of the company you are in conversation with.

The scope of work and the innovation level within the application are two very important factors in the overall cost of your web or mobile Minimum Viable Product. Web and mobile apps involving blockchain, machine learning, and any AI or VR components cost more that applications with standard functionality. 

As you might assume, it’s hard, nearly impossible to place a number on a digital product we know nothing about – pretty much like guessing in the dark. If you want to know how much a Minimum Viable Product will cost you, our advice is that you seek the help of a development team. 

You made it this far!

We hope this article helped you in finding some of the most important aspects of why you should build a Minimum Viable Product for your startup, and offered important insights on how to build an MVP. If you have any other questions on how to bring your digital product idea to life, reach out –  we’re here to give a helping hand.

Before you go, we recently launched our own startup, Visidot, and wrote an article about the entire process of building the digital product, from idea to launch and … pivoting? We’re leaving the story of how we built Visidot, the contact tracing and visitors management application, here for you to read it.  


Building a contact tracing and visitors management system. The story of Visidot, a product of RebelDot.

Hi there,

We are starting this article series to share the story behind Visidot, our own startup, with you.

As you might already know, this is the first article of the series. We are going to take you through the journey of building Visidot from the very first moment we identified the need for a digital visitor log, the decision to build it and everything in between. Ready?

A look into Visidot, the visitors’ management system

If you have been following us for a while now, you might already know that we are a bunch of creative, solution-oriented Rebels. We blame it on our twelve years of experience in building various digital products, as it nurtured our entrepreneurial thinking and spirit*.

*always looking for the next problem to understand and a solution to develop kind of mindset

Just in the right moment, this spirit was the fuel needed when the opportunity to develop Visidot (back then named ‘’we have to find a solution for replacing the paper log”) arrived.

Identifying the problem

We’ve all paid a visit to another company or business centre. Most probably, we’ve all been asked to write our name, purpose of the visit, and signature to a notebook or some random A4 format pages left out there in the plain display.

Of course, this wasn’t considered to be something extremely sensitive until the GDPR kicked in. That was the moment when displaying our data on means that were available for all the other visitors and everybody from the company, we were paying visits to became prohibited.

Everybody could see that you were coming to an interview, at exactly 12 a.m when you were supposed to be on your lunch break. *Busted*

As 99% of the companies in Romania, we at RebelDot had the same pen & paper log that was not compliant with the new regulations. So, we had to come up with an idea to make it both digital and compliant.

“We started with a clear vision in mind: to transform our visitor’s experience in a smooth, hustle-free and GDPR compliant one.’’

The challenges

Building a startup, and especially a new product comes up with multiple challenges. No matter how much experience you have, bumps in the road will always come to teach you some valuable lessons.

  1. What should go into the MVP — One of our challenges was prioritizing what set of functionalities will go into the MVP — trying to balance the features so we can create enough value and get the feedback we needed from the market.

In order to make the decision, we conducted user interviews, with the aim to understand their needs and behaviour better. The data was translated into several prototypes that helped us decide the set of functionalities that will deliver the main value for the targeted pain-point. When building the MVP, we also had to take two different perspectives into consideration: one of the building administrator and one of the visitors.

2. Designing for business centres — We initially designed Visidot for our internal use. Once we started to dig deeper into the need on the market, we had an epiphany — business centres.

Business centres have thousands and thousands of daily visitors, and keeping track is essential for safety reasons. Once we realized the opportunity, we started to think about how we can adjust the app’s flow to satisfy the business centre’s needs.

The solution

Our solution is pretty simple and straightforward: A digital visitor log to help you track, measure, and improve your visitor’s experience — all in a 100% compliant environment.

Apart from the visitor’s flow, we also developed an administrative interface where users can customize the application, gather statistics, and manage multiple locations.

The process of building Visidot

As you might already know, at RebelDot we have a well-defined software development process in place, and our product was no exception to the rule.

01. Creating the user personas

First things first, we had to understand our users and what are their main problems to solve. After having a couple of users interviews, we managed to come up with three types of users:

  • The receptionist, responsible for welcoming visitors and smoothing the registration process;
  • The delivery guy that is recurrently coming to the company;
  • The admin supervising everything that is happening;
  • The visitor.

02. User Flows

After we understood more about our user personas: their needs, behaviours associated with the actions, and how they envision the app, we started to sketch the user flows.

We’ve covered different scenarios: check-in, check-out, recurrent visitors, group check-in and check-out.

03. Wireframes

User personas — checked.

User flows — checked.

What’s next? Wireframes. Right.

Wireframes Visidot


Early-stage wireframing sessions of Visidot.

Our team took the sketches and translated them into black and white wireframes.

We must admit that we love colours. However, at RebelDot, we have a different approach. We first bring black and white wireframes to the table so you can ‘’judge’’ the prototype by the functionality and not by the shade of the blue on the bottom left corner. This is the common approach for teams that have UX methodology in place.

04. User interface

Once we agreed on the user flows and wireframes, the next step was to select the colours, iconography, and typography.

Following our vision, we decided to keep it simple and as minimal as possible.

– light shades of colours on the corners of the screens;

– clear icons for the admin interface;

– intuitive input fields.

Visidot - tablet
Visidot Tablet 2

05. Prototype

Once we had the elements in place we built a functional prototype and run some tests to gather feedback and adjust the functionalities and flows.

06. Coding

Once we have completed the UI/UX phase, and we agreed on the plan moving forward, we’ve started coding.

Using the Agile methodology, we gathered daily to discuss the progress and the bottlenecks that came on our way.

07. Usability tests

Once we released our first version, we showed it to the world. Making sure we gather insights and observing the user’s behaviour when using it.

08. Launching Visidot

The truth is that, as Buffer wrote in one of their articles until you get that one customer you are blind. You don’t know exactly if what you’ve built reached the problem-solution fit stage.

So we leapt faith and launched Visidot.

Our first client is Cluj Business Campus. One of the most well-known business centres in Romania with an excellent appetite for digitalization.

Visidot - Announcement


Announcing the launch of Visidot on social media.

We were so excited when we saw their first visitor using the app and getting fantastic feedback for the user experience.

We must admit that we got butterflies.


Visidot’s first day at Club Business Centre.

09. Improvements

Following the Lean Methodology, after we launched the first version and we gathered feedback from the users we’ve made improvements by adjusting some of the functionalities and wording within the app.

What’s next?

Immediately after launching Visidot, COVID-19 kicked in. Since our product is a solution designed for visitors and the restrictions applied meant ‘’no visitors allowed,’’ it shook us a little bit. We had so many plans, and we were talking with lots of potential clients for our solution.

However, like Rebels, we are adaptable and look every time for solutions. Plus, we built Visidot as an easy to pivot solution so we took advantage of the lockdowns to continually work on making the app better and think about other functionalities that would help companies adjust to the new normality.

As we speak, countries around the world are ‘’back in business’’ and implementing all sorts of solutions to prevent the spread of the new, COVID-19 virus.

Visidot is here for them and for you. We help you with contact tracing in COVID-19 times, making sure you have access to real-time information, across all your offices- all in a 100% compliant environment.

Looking for more information on Visidot? You can visit the Visidot website and get back to us if you have any other questions.

Visidot - extract


Building a mobile app in 2020? Here’s what to look at.

Looking back at the past year from a technology perspective, all we can say is that 2020 should be at least as ground-breaking as 2019. But with a lot of technology trends & buzz words being promoted around, which one will you actually trust to lead the strategic direction of your next mobile app?

If you ask us, you shouldn’t trust any of them. At least not until you are 100% sure that whatever the new concept or technology you are trying to adopt in your new mobile application, it is what your users really need. We know Blockchain, AI, Machine Learning and VR all sound cool and cutting edge, but don’t just use them to attract more eyes to whatever it is that you are building. It won’t last.

For the past decade, at RebelDot, we have built and worked with over 40 startups and companies around the world, and if there is one valuable learning we could share, is that the real success of your digital product is hidden in the PROBLEM you are solving for your users, or, in other words, the idea behind your web/mobile application. It has to be relevant to the market you wish to penetrate. Now, of course, we are not talking about the fantastic user interface you are imagining for your mobile app or that one unique feature you are planning to revolutionise the industry with. It’s more about the weight of the value you wish to place on the market by launching your new web or mobile app.

Do you have what it takes?

Before you start building your next mobile application, here’s what we recommend you ask yourself:

What is the problem I am solving with this web or mobile application?

Whom am I solving this problem for & who are my users?

Checking these two important questions will provide the right framework for starting to build a digital product that has great potential for healthy scaling. Now, of course, it is a good idea to make sure you check to pulse of the technology ecosystem from time to time. You want to make sure that if there is a new technology that might decrease the cost of your application, ease the experience of your users of simply help you get the most out of your new built, you know of it.

Also, you might want to pay a bit more attention to how you engage your users from the very first seconds of their digital experience. For that, we recommend you reading this comprehensive Splash Screen Guide

Now might be the best time to start building a mobile application. Here's why:

In Q3 of 2019, iOS lead consumer purchases growing 95% over Google Play.

Beginning of 2019, TechCrunch reported that the global app revenue continues to climb, thanks to the growth of the gaming industry and of the subscription economy. (TechCrunch)

In 2019, App Store users spent $14.2 billion, up 22.3% from the $11.6 billion they spent in Q3 2018. Google Play generated $7.7 billion in revenue, up 24% from the $6.2 billion spent in the year-ago quarter. (TechCrunch)

When it comes to app downloads, according to App Annie, Google Play and iOS downloads grew over 10% in Q3 of 2019.

While iOS downloads remained stable in 2019, Google Play grew its downloads by 10% to nearly 23 billion. Google Play leads iOS in downloads by 175%, with non-gaming apps accounted for over 60% of downloads across both stores.

In 2020, Global mobile application revenues are projected to generate a revenue of $188.9 billion via app stores and in-app advertising. (Statista)

Already visualizing your new application being downloaded by thousands of users? Let’s shed some light over the 2020 mobile and web application trends & new technologies that might help you get there.

Blockchain Technology

Being a pragmatic yet revolutionary technology, blockchain goes beyond cryptocurrencies and bitcoin. With its capabilities of creating more transparent and secure environments while saving fair amounts of money, it has reached the performance of impacting a variety of industries and sectors by changing how contracting works.

Some of the areas in which blockchain is seen to bring the most value are secure sharing of medical data, music royalties tracking, cross-border payments, real-time IoT operating systems, personal identity security, anti-money laundering tracking system, voting mechanisms, original content creation, crypto exchange and real estate processing platforms.

Blockchain + IoT = ❤

We already know that blockchain is a standalone disruptive concept for every tech aficionado out there. But have you thought of combining it with IoT? It might bring some considerable improvements to the way transactions are made, including some decreasing of risks.

There is a smarter way to do smart contracts: Ricardian Contracts.

What is a smart contract? According to Investopediaa smart contract is a self-executing contract with the terms of the agreement between buyer and seller being directly written into lines of code. The code and the agreements contained therein exist across a distributed, decentralized blockchain network. The code controls the execution, and transactions are trackable and irreversible. (Investopedia)

In simple words, they allow trusted transactions between anonymous parties without the presence of any central authority.

Smart contracts are great and all that, with one minor issue — they are not legally binding, so it is pretty hard to build a legal case against an existing fraud. And here is where Ricardian Contracts step into the scene.

While Ricardian Contracts have first been introduced in 1995, they somehow managed to penetrate today’s blockchain scene, by having this unique trait of being digital documents that can be both understood by humans and machines. This means you and your lawyers should be able to read it and perfectly understand it.

According to 101 Blockchains, a Ricardian contract is a human-readable legal agreement that once agreed upon and signed by both parties, gets converted into a machine-readable contract to define the intentions of both parties. (101 Blockchains)

A fundamental difference between Smart and Ricardian contracts is that while one (Smart) executes an agreement without being legally valid, the other one (Ricardian) records agreements between parties, having a legally binding character that is valid in court.

Artificial Intelligence is here to stay.

While AI has been the technology hit of the 2010s, it looks like it is here to stay.

AI in entertainment and media. Have you seen Robert De Niro in the Irishman?

If you kept an eye on the result of AI in creating music or any kind of art that is out there, you will probably agree with us when we say that AI has a long way to replace humans from creating any form of art that is actually enjoyable.

If like us, you spend some of your time binge-watching on Netflix, you might have seen Rober De Niro’s extreme de-ageing in The Irishman. Like it or not, de-ageing or ageing of human faces is now possible with the assistance of AI, and it’s safe to say it’s a tiny bit of all the transformation AI is bringing to the entertainment scene.

On the left, Robert De Niro’s original performance in The Irishman. On the right, his de-aged face as it appears in the film. Source: Wired & Netflix.

In 2020, we are already familiar with personalized recommendations powered by AI. Getting back to Netflix, they personalise the content stream you see on the go, and this is not even a secret anymore. Processors are now engineered in such way they are capable of generating real-time analytics, offering the content an technology that we consume on a daily bases an important and personal twist.

React Native and Flutter continue replacing Kotlin and Swift for Native Android & iOS development.

In one of our past articles, we covered a few important aspects of how React Native has already disrupted the mobile development scene.

Being supported by Google, Flutter, a fairly new name on the mobile development scene is seen to acquire more authority and trust from developers in eastern Europe and around the world. It promises the building of mobile apps in record time., Tencent, New York Time’s Ken Ken puzzle, Square and Google Assistant are just of few of the apps that are already using Flutter.


Internet of Things.

Today, internet-powered things are everywhere. It’s because we grew to love things powered by the power of the internet & connectivity and this is clearly reflected in the way investments are growing year by year as technology giants are developing more IoT apps.

Hint: If you are looking to get your hands dirty with some IoT this year, take a look at the impressive market size of smart home devices. Here is something we found while browsing around. It is from Strategy Analytics.

Final words.

Today, more apps are being released in the App Store and Google Play store than ever. While this could be both good and bad for your next mobile application, it is getting more clear that in order to craft a digital product that stands out on the market, you will need more than cutting edge technology or clinging to the hottest technology trend that is out there. Standalone, these two can’t do enough in order to ensure the success of your business on the market. Take a look at a software development process and before starting to tech around, make sure you spend a great deal of time in researching the scope of your digital application.

🚀Did reading this article made you start building your mobile app with RebelDotWe’d love a tech riddle! Reach out and let’s talk about building your awesome digital product, together. Make sure you, and we will get back to you in no time.

🤔Reading this made you want to be part of the RebelDot team? We’ve got great news! We are in search of creative engineers that can help us ship digital products. Check our openings, here.


Prototype first. Fail fast. How to ship products that delight.

You want to build and launch an awesome digital product, or thinking about redesigning? You’re in luck! — We’ll talk about our UX process at RebelDot and why putting emphasis on research, validation, and prototyping will make or break your web or mobile app.

According to this research, by the time you’re done reading this article, 40 new digital products & startups will have been created. That’s 1 startup every 10 seconds. Truth is, 90% of them will fail in their first months, while others will go around for years chasing their tail without actually doing something about the sinking ship.

The good news is that you don’t have to be one of them. We’ve built dozens of products and even though there is no one size fits all, following a well-structured UX process will guide and take you closer to launching a delightful digital product that people want to use. Think of it as a fitness program: if you stick to it, put in the work and avoid shortcuts, you’ll end up with the results you have always wanted.

Before getting into this, it’s safe to say that following a UX process will definitely work to your advantage. Still, as every product is different in its own way, understanding that a good design process adapts to certain product needs is vital, therefore the needs and goals should define the way of approach.

  • The core part of our approach here at RebelDot is going UX first and building products through an iterative user-centred design process. Through iterative loops, we design, build and validate ideas, flows, journeys, processes, and test disruptive ideas that might never see the light of day. However, none of this would be possible without prototyping.

The RebelDot UX process looks like this:

From the automotive industry to food, health and of course digital product development, prototyping serves as the keystone in releasing successful products. Simply put, think of prototyping as the most effective step to accomplishing and validating things with minimum effort.

The primary purpose of a prototype is to validate if a process or flow works and lives up to the requirements, hitting the target goals. Essentially, the sooner you realise you need to adjust, the better. Sure, if you want to take the alternative route, you’re welcome to go forward with getting engineers to develop your idea and after at least 50k spent in 6 months time realise you built a product that no one will use. Historically speaking, this is a moment when many companies reach out to UX designers to fix their product but unfortunately fixing it only means rebuilding everything.

The most important lesson you can learn when building a product is that you’re not building the product for yourself. The primary focus needs to be on your users, therefore you must address their needs, frustrations and objectives, enabling them to excel through the product and reach their goals.

The tools of the trade

There isn’t one do it all prototyping tool. The tool used should facilitate building a prototype to fit the desired scope in the fastest time. Overextending will result in delays in delivery and validation time, therefore the versatility of the tool should match the requirements, and keep the effort to the lowest. You can’t call it rapid prototyping if it takes an eternity.

Prototyping models 

Depending on the stage of the product, there are a few prototyping models we opt for to make sure the journey suites needs and hits the goals.

01. Exploratory prototypes

We build exploratory prototypes when the product team, stakeholders or clients have an idea and want to visualise it in a real, tangible form. We start off the ideation process, reflect the objectives on our target user’s needs and define the goals and actions needed to get there. The idea can be a standalone idea, an extension of the current product which could become a candidate in the roadmap or a new way of approaching existing actions in the current system.

02. Validation prototypes

Validation prototypes are the result of thorough research, need mapping and are built based on the whole set of knowledge gathered throughout the research and iterative phase. The prototype is based on well-defined flows, user needs, goals and motivations and sets out to solve problems and reach key objectives. Its purpose is creating a realistic enough experience that can be put in front of users to be validated through user testing, so it can set the route for the next round of iteration.

03. Visionary prototypes

These are the coolest, most challenging, uber-cool prototypes that will, most likely, never see the light of day. The purpose of a visionary prototype is to test truly disruptive ideas that are so crazy they might never get built into an actual product. However, by forcing ourselves to think so far outside the box, we innovate and create solutions that may be applied further down the line. Think of F1 cars: — their purpose is to push the boundaries of motorsport through innovation, which will later become part of our future.


Designing a product without the prototyping phase is like wanting to build a car from scratch based only on your imagination. You will most likely end up missing the steering wheel. Start with listening to your users, launching assumptions and hypotheses. Reflect on needs and objectives, do the research and concentrate all these efforts in prototypes which can be validated with real people.
Prototype first, validate often and fail fast. Drive the product experience through your users to build and launch a product that delights.

🚀Did reading this really make you want to work with Tom? Reach out and let’s talk about building your awesome digital product. Make sure you, and we will get back to you in no time.

🤓Want to read more? Check out this article on How going UX first is a necessity for your digital product’s future.

🤔Reading this made you want to be part of the RebelDot team? We’ve got great news! We are in search of creative engineers that can help us ship digital products. Check our openings, here.

DSC_1581__1564482943_82.78.92.63-2000x1125 (1)

React Native or Native Development-iOS & Android: What should you choose for your next mobile app?

The dream of having one single framework to cover all platforms has been amongst us for years, and for a lot of us, getting here seemed nearly impossible.

A few years later, React Native has massively grown since it was open-sourced by Facebook back in 2015. Today, huge players like Facebook, Bloomberg, Uber Eats and Walmart have chosen React Native to build their mobile apps.

So, what’s better for your next great mobile app, React Native, or Native App Development?

A few months ago we had this very same discussion in house, with one of our partners. We were looking at two different apps, that could both be developed native or cross-platform. One involved sole iOS development and the other one was supposed to function on both platforms, Android and iOS. Now, most of our clients expect that in this kind of situations we deliver a straight, upfront answer with solid information to sustain our position. The truth the answer to this question depends on the project you are planning to build.

Taking the case of a mobile application that we would want to work on both platforms both iOS and Android, React Native comes in handy as a streamlined, cross-platform framework that allows you to develop two different apps, with the same codebase without compromising on your user’s experience. This simply means you don’t have to create an iOS and Android app separately and instead, one single codebase will have the output of two different apps. It also means that when there’s a bug, we’d only need to fix it once, which makes this whole React Native game loved by teams of developers around the world.

To cut to the chase and get a few things clear from the start, if you are only looking to build an iOS mobile application, building it in React Native makes zero sense.

So, yes, React Native is not an all size fits all framework, and there are cases in which we do not recommend cross-platform development as the best option. Switching the angle, if you are looking to build an iOS mobile application and later on add an Android one to it, the approach isn’t the same.

From our perspective, React Native comes with a huge advantage of cutting down on development costs. Our experience tells us that in most cases, the development cost is reduced by 30% per platform.

Besides this great competitive advantage React Native brings to the table, there are a few essential things we would want you to consider before making any decision regarding the tech stack of your mobile app. These are also some of the most frequently asked questions we get regarding React Native. Grab a cup of your favourite coffee and read this through with us.

Does React Native influence the look & feel of my mobile app?

The right answer is that it depends on the overall complexity of the user experience.

One considerable advantage that native mobile apps bring to the table is access to all mainly native functionalities, as well as some other animation tools. There is no middle ground, and you can take advantage of everything the platform has to offer. For some apps, which are a little bit more sophisticated in their UX, this might improve the overall user experience the app has to offer. Although React Native has the Animated API, which is a pretty good solution, some say it is still far behind the native capabilities.

In a nutshell, React Native simply does not provide all the power for complex animations and UX like a native app would. Still, for simple-looking apps, unless the quality of the code is poor, the user should not be able to tell the difference.

Does React Native influence the future scalability of my mobile app?

We recommend getting into scalability as a point of discussion long before actually starting to build an app. It not only gives your digital product a good start, but it helps in making sure you won’t have to support the financial costs of possibly rewriting your app later in time, as the product gets more traction.

By now, React Native should have all the capabilities of scaling with about 80% of the apps on the market. Having said this, there is no reason React Native should stand in the way of your app’s scalability, and there are a few good examples out there on the market to prove it.

Why are some people disappointed by React Native?

Because for apps that are resource-intensive and require a lot of interaction, Java, Swift and Objective-C might be better options. Messaging apps like Facebook Messenger can be a good example here, as in most cases, they allow a high degree of customisation and have a lot of background processing.

Also, there are apps like battery monitors and media players or various antivirus software that are more suitable for native languages.

Airbnb ditched React Native. Should I too?

The short answer is — no — but it gets more complicated than this.

If we take a look at the case of Airbnb, they ditched React Native after trying to introduce it in a reasonably big app, already written in native code.

Around 2009, Airbnb was just a web-based platform, with increasing traffic on mobile devices.

In 2012, the Airbnb development team realised that in order to keep pace with the increasing traffic they were having on mobile devices, they would eventually have to start investing in a team of iOS and Android developers. For almost four years, their team built iOS and Android apps using dedicated mobile development resources.

Four years later, in 2016 the landscape has shifted in such a way that they had to come with a faster solution to the increasingly mobile need on the market. Already having a fairly big team of experienced React resources from their web development teams, switching to React Native instead of hiring iOS and Android developers, seemed like a good idea. They started introducing React Native into their already existing code base and up to this day, 15–20% of their apps were written in React Native.

In 2019, Airbnb realised it takes more time and resource to introduce React Native into an already existing codebase, as often times they were bumping into functionality gaps that needed to be filled with native code.

Taking the case of Airbnb, transitioning from 0 to 1 was far costly than expected. The point here?

If you are trying to introduce React Native into an already existing codebase, expect to invest such amount of energy and time, it might not even be sustainable anymore.

Summing this up, React Native should, by now, have all the capabilities of covering functionalities for at least 80% on the market. To this day, it has been widely used by a lot of big brands that are out there and in some cases, it might be the smartest option for developing a mobile app for both Android and iOS.

If your team does not have any experience working with React Native whatsoever, maybe an alternative would be to hire a React Native developer

Did we miss anything?

Make sure you drop a line or

Curious to know what it’s like being a rebel? Come grab a coffee.

We are looking for rebel people to join our offices in Copenhagen, Cluj and Oradea.


Challenges of adopting blockchain.

Blockchain is the new kid on the block (pun intended). There’s a lot of buzz around it, about how disruptive it is, that it will change a series of industries and will start a wave of innovation.  You might have considered using it in your next product or project, but not sure what your approach should be? Let’s see what you can expect down the road!

Disruption always comes at a price, because you are bringing something radically new to the table. Adopting something new takes time. It implies getting out of the comfort zone – for you, for your team, for your users, for the industry. Therefore, disruption can happen at a tipping point: when the need to innovate and the benefits of disruption will outweigh the inconveniences of the process. This is also how blockchain itself was born: to solve a problem.

So far so good. It sounds exciting. Except, it comes at a price. Blockchain solves a series of problems in an innovative way, thus using it implies a paradigm shift. This paradigm shift, although very promising, comes with its challenges. Some of these are not obvious from the start, because disruption questions the very same things that we’ve got accustomed to and take for granted. Let’s dive in!

You operate in a decentralized environment.

Blockchain is successful in delivering its promise to create trust in a trustless environment by making sure that no central party is controlling the information on the blockchain. Not even you! This transfer of control and ownership comes with a series of considerations:

  1. How do I achieve compliance with various regulations (e.g. GDPR)?
  2. What happens if I do an honest mistake when adding data to the blockchain?
  3. What if I have new requirements and I must adjust existing data?

Obviously, there are already a few techniques to cope with these challenges, just keep in mind that these usually imply a change in the way you do things as opposed to centralized systems.

Your users need to communicate with the blockchain.

In a purely decentralized environment, users should not need to communicate with any central authority, but with the blockchain itself. This is not a trivial task and currently needs quite some effort from your users’ part. To consume decentralized applications, you need specialized software. Your users need to be aware of that and they will need to go through a learning curve themselves.

On the other end of the spectrum, users are already accustomed to certain ways of interacting with software. Depending on your use-case, the real value that you can bring is finding a way to combine centralized technologies with blockchain in such a way that you can offer your users all the good stuff that they are accustomed to, while also leveraging the blockchain promise. And walking that fine line takes some fiddling with the technology

Developers need to adjust to the new paradigm too.

Because of the nature of the technology, developing blockchain applications resembles developing firmware: once you release it, it’s out there on thousands of devices. Devices over which you have very limited (if any) control. Thus, the price of updates is very high. As with firmware, get it right the first time, or you will pay the price later. This also implies that a series of best practices that developers are usually familiar with might not fit well: continuous integration, incremental builds, Agile itself. You’re more than welcome to use these internally, but your first release should be as complete and stable as possible.

Blockchain is immutable.

This also means that you need to deliver quality software from the start. And the implication is that you need to budget way more design and testing time than in centralized projects. They say that software testing cannot prove that a piece of code has no bugs, it can only prove that known bugs have been fixed. Thus, quality starts with software design. You should budget enough time to consider all the corner cases, limitations, long term consequences and security implications. You should have strong quality metrics.

Having a dedicated testing team is also important. Your developers will start with a great design and their code might be of excellent quality, yet bugs will slip through the process. This is because it is hard to accurately test your own code. People tend to build a mental model for solving a problem, and developers will use the same mental model for testing their code. In other words, they will look for bugs using the same mental model with which they’ve created them in the first place. This is human nature. A dedicated testing team can make sure that software is verified using a different mental model. Budgeting plenty of testing time is also important. The rule of thumb (that might shock you at first) is ‘5 to 10x’: for every week of development consider 5 to 10 weeks of testing. Software testing for blockchain is not just an aspect of quality assurance, but a way of risk mitigation.

Security is paramount.

Your code is accessible in some shape or form to everyone running a blockchain node (and in case of public blockchains to literally anyone). Thus, security plays a crucial role in your development lifecycle. Even more, once out there you cannot really modify it. If there is a security bug, bad actors can exploit it and there is not much you can do about it, since you cannot just patch your code, like you would in a centralized environment.

The technology and tool set are not yet mature.

The ecosystem is still in its early stages and while new implementations and tools appear quite frequently, these are not as stable as the offering on conventional technologies. Often, developers need to face the reality that something that is trivial to achieve using other technologies will turn out to be quite complex with blockchain.

Blockchain is not particularly fast.

The main characteristic of blockchain is immutability and security. By design, blockchain solutions will favor these over performances. Of course, the technology is rapidly evolving, and new solutions are proposed to boost blockchain performance, but today’s reality is that blockchain is not as performant as other centralized technologies.


At this point, you might incline towards giving up on blockchain, but the truth is that there are solutions and practices in place to help you deal with the challenges that you might face. The key takeaway is that blockchain not only disrupts the fields it is used in, but it has similar effects on the way you build your product as well.

So, is it worth it?

As with every technology, the answer is: it depends. Blockchain can indeed bring innovation to a whole series of industries and it has a lot of potential. In some cases, it really is unparalleled and offers advantages that simply cannot be matched by any other technology on the market. But we should use the right tool for the job. This technology is particularly good at making sure that information cannot be tampered with and there is a complete and immutable history of events, a permanent record of sorts. If that is something that you are after and you can build value on it then blockchain will prove to be a great fit for you.