Before we begin, I want to note that this text will be lengthy and will cover the entire process from idea to market launch. I aim to provide a comprehensive understanding of the vast difference between the world of software coding, which is undertaken by thousands of software companies, and software product development, which is only done by few of them.
I will describe the process of our thinking, the problems we encountered, and the solutions we came up with, as well as the steps we took from idea to market. However, this blog will not include any frameworks, techniques, or theoretical parts, such as how to do product discovery or design sprint. Instead, we will provide links to other blogs where you can find more information on these topics.
Product Discovery
The client’s requirements were to create the first social network for events. The idea was based on the assumption that people needed a way to connect before, during, and after business events, and to provide a tool for sales and marketing professionals to increase and measure results at events.
We all know that live business events are crucial for companies to sell their products, raise brand awareness, make connections, find employees, and learn new information. Imagine something like LinkedIn for events.
This concept seemed like a great idea, with the obvious target being companies and businesspeople attending events. To ensure we were on the right track, we conducted a product discovery process with our target companies. Through surveys, we discovered that they were thrilled with the idea of having a sales and marketing tool at business events and the ability to measure results at these events.
During our product discovery process, we also found that only a small percentage of business events are organized by companies, with most events being organized by communities and micro-companies known as event organizers. This posed a challenge before we even started the project – how to solve this issue. Our original idea gives value to companies and participants, but not to event organizers. In order to provide value to them, we needed to figure out how to approach event organizers and encourage them to host their events within our app. After all, without event organizers, there would be no Companies to offer value to!
On that topic, we discovered that event organizers are extremely price-sensitive, and the main issues they face are how to effectively sell their events, register attendees, check them in, sell additional services to sponsors, and make the event enjoyable for all attendees.
It became clear that in order to provide value to companies, which was our initial idea, we needed to first provide value to event organizers.
In collaboration with the client, we conducted research on how event organizers function and analyzed the competition in this field. We didn’t want to create yet another event app that would compete with the hundreds of others that already exist, each with their own agenda, registration, venue information, and white labeling features.
After thorough research, we realized that marketing and sales functions were not the way to go for event organizers, as they were already using EventBrite for that purpose.
Instead, we focused on the fact that event organizers are essentially communities. We decided to offer them the opportunity to run their communities on our app. Moreover, we discovered that event organizers had a significant problem with checking attendees in on time. Every system that they had until then was too slow, requiring them to register people with printers, QR codes, lists, and so on.
We proposed a solution with a self-check-in process that utilized geo-location. This was an idea that we were particularly proud of, and it later proved to be effective when we successfully checked in 500 people in only 15 minutes, which is equivalent to 1.8 seconds per person. We also discovered that event organizers would like to have digital signage which would show the real time content on the big screens on event directly from sponsors and participants. They can sell the feature to Sponsors.
What product discovery discovered
The conclusion drawn from the product discovery process is that the equation for successful events is not a simple one. There are multiple stakeholders involved, all of whom need to be satisfied in order for the product to be successful. It has been decided that the system should have features that satisfy event organizers and are also valuable to companies at the same time.
We quickly realized that this presents a trap that many companies fall into. The creators of a startup are often emotionally attached to their product, and as a result, they may pursue their goals at all costs, without considering the needs of all stakeholders. Therefore, we proposed that we not rush into software development without first understanding the value for all stakeholders.
To define the MVP (Minimal Viable Product) and reduce software development expenses, we suggested using the Design Sprint technique.
MVP (minimal viable product) and Design Sprint
Before beginning our design sprint, we held several brainstorming sessions where we discussed our assumptions and surveys from product discovery to arrive at the idea for our minimum viable product (MVP). To ensure that everyone from the business team was prepared for the session and that we stayed on track, we time-boxed the discussions. While these sessions were fun, it was important to maintain structure and ensure that everyone was well-informed about the topic; otherwise, it would have been chaos instead of brainstorming.
With a list of desired functionalities in hand, we began our design sprint using Figma for prototyping. We created an app that could be run on a phone, allowing us to click on each functionality. These functionalities were not yet connected to any logic or database; instead, they were mocked and returned some dummy data.
On the last day of our design sprint, we interviewed around 15 members of our target group (companies and event organizers), showing them the parts of the app that were tailored to their needs. While both groups were generally satisfied with some of the functionalities, others were less valuable to them. We recognized that for the MVP, we needed to give up on some of these functionalities in order to save money for our client.
At the end of design sprint, we had clear vision about what is valuable to the users, how they like first idea of the app design and what are the good and the bad things in first version of UX. These were only guidelines but valuable guidelines for us.
What about Business model?
Ultimately, every product is designed to generate revenue for its owner. The management of MatchAbout knew this from the start, and created a business model centered around marketing and sales tools for companies participating in events. The idea is simple: by providing companies data about other companies attending the event, MatchAbout enables them to prepare beforehand, conduct business during the event, and follow up afterwards.
What about event organizers themselves? The majority of them are micro companies or communities, who are often price sensitive. To accommodate this, MatchAbout has decided to use a freemium pricing model, offering some basic functionalities for free, and more valuable ones for a fee.
You may be wondering why they doesn’t offer everything for free to event organizers. The answer is simple: human nature is like that, if something is free, it is perceived as having no value. If something is solving a problem, it is essential to attach a price tag to it. Remember the feature that someone is able to check-in 500 people in 15 mins? It is a big deal.
And what was the result? MatchAbout has ended up with a business model that has one primary revenue stream coming from companies, and one secondary revenue stream coming from event organizers.
Business people are very creative when the money is in the game. We came up with numerous revenue streams such as ticket sales, ads, digital signage, video streaming… It is crucial that in beginning everything is simple and strait forward. We do not want to make complications for users in MVP.
Architecture and infrastructure
People who create new products often dream that their invention will change the world. This is an excellent motivator that drives the entire team forward with energy. The Matcahbout team, for instance, dreamed of creating a new LinkedIn for events. However, building such a significant product absolutely require the best hardware, latest software architecture, or the latest technologies. Is that right?
Absolutely no.
This section is crucial, and I want to explain it thoroughly. In my 22 years of software product development, I have witnessed many companies fall into this trap, costing them a significant amount of money to rectify.
There are two paths that often lead companies into the trap.
First approach: When a team, particularly a small startup, decides to save money, they may opt to develop a minimum viable product (MVP) for testing the product and the market. To achieve this, they may choose to use cheap shared hosting or servers that host multiple products on the same hardware. Although this approach may be suitable for development, it can be catastrophic for any production release. Sharing resources with many other projects can lead to inconsistent product response times, with periods of good response time followed by periods of extreme slowness.
If you reach out to the hosting provider about these issues, they will likely claim that they are great and suggest that you need to optimize your software. However, this is not true, as they are typically of very poor quality. In reality, they are only suitable for hosting static sites with a few web pages.
On the other hand, when you require from development team to build an MVP to test the product and market, they may create the prototype very quickly. However, they may not consider scalability when designing the architecture and writing the code because this is only prototype.
If you release a product with minimal expenses, using cheap hardware and fast development, and the market indicates that your product is not wanted by users, that can be a great outcome. However, if your product gains traction and users start adopting it, with the user base growing, management happy, and requests for more functionalities, you could be in trouble.
In such a situation, you may find yourself with hardware that cannot support more than a few thousand users, and an architecture and codebase that are not scalable on platforms like AWS or Azure. The only option left is to keep adding more hardware until you reach a limit, and eventually, you will have to rewrite the codebase. This can cause a lot of stress for management, who are anxious about keeping their users satisfied, and for developers, who must cope with the technical complexities of scaling up. I have seen many companies pay a high price to resolve these problems once they occur.
There is one saying: Be careful what you wish, it may happen.
Second approach: This is a common scenario in medium to large companies. They already have a lot of money and want to do everything according to the latest standards. They have the best DevOps experts, software architects, and everything is top-notch. These experts will immediately choose Azure or AWS, create a development environment, staging environment, production environment, and implement the best security measures and products. In other words, they purchase everything money can buy. The software developers will suggest using microservices, the latest technologies, the newest frameworks, building the web app in one tech stack and the admin part in another, and of course, developing native IOS and Native Android apps, as hybrids are not providing a satisfying user experience.
These actions can result in a project that requires 8-12 people instead of 3-5 people, leading to slower development, synchronization issues, and significantly higher costs. While this sets the project up for success, if the market rejects the product, a large amount of money has been spent without success. At least the employees are happy, as they have worked with top-notch technology and learned something new.
What is the solution?
There is no silver bullet, but I will explain what we did in the case of MatchAbout.
Infrastructure: We took two dedicated servers with reasonable price and put on them dev environment, prod environment and databases. How, it is a deep tech story which we will explain in some other blog. Is that good solution? Yes and no. Yes, for dev and market test phase, no for product that needs fast scaling. We are now in development phase and we do not have hundred thousand of users and we will not have them in one-year period, so for one year we will save lots of money.
Architecture: This is a critical aspect of the project. We need to design the system in a way that is easy to maintain, allows for fast development, is highly scalable, and can effortlessly transition to AWS or Azure in the future. I won’t delve into the technical details, but we opted for a monolith instead of microservices, which we prepared with loose coupling and multiple projects, allowing for easy migration to microservices with minimal effort. We employed various caching mechanisms to optimize performance at all levels and maintain low development costs during the early stages while enabling quick scaling to larger systems if required in the future.
We decided to use the Ionic framework, which eliminates the need for dedicated IOS, Android, and Angular developers. Instead, we only need one Angular developer to work on all three platforms – IOS, Android, and web. We also selected frameworks and languages that can operate on both Linux and Windows operating systems, providing our client with flexibility and choice in the future.
The conclusion is that we have chose infrastructure with minimum expenses, kept the team as lean as possible in order to have fast communication, but we set the software architecture on such way that the team needs very short time to change dedicated servers to full scalable environments like AWS or Azure. Software will allow that.
We’ll be posting more blogs in the future that will provide in-depth explanations on topics such as AWS, Azure, Native vs. hybrid, and security.
For now, I’ll give a brief overview to avoid being grilled by the tech guys.
Are AWS and Azure good options? The answer is both yes and no. They are excellent for scaling products when you have income that far exceeds expenses. In other words, when your product is on the market and growing rapidly. However, during the initial stages, you may find dedicated server providers that are 8 times faster for less money than AWS and Azure. The downside is that they cannot be scaled as quickly as AWS and Azure. But during this phase, scaling isn’t a major concern.
Microservices are great, but they come with a price: slower development and cumbersome maintenance. You don’t need this for your MVP, but you should be aware that they will be necessary if your product has millions of users in the future. That’s why it’s essential to set up your software architecture in such a way that you can switch relatively easily when the time comes.
Native mobile apps are great, but you don’t need them in this phase. The Ionic framework is built on Angular, so you can write your app in Angular with minimal additions, and you’ll get native apps for both platforms. When we generate enough revenue, we’ll hire IOS and Android developers to do the job properly.
Now the project is set to go really Agile.
During the development process, we used the Scrum framework, as it is well-suited for product development. However, on other projects, we have used different frameworks such as Scrumban, Kanban, Safe, and Less. Additionally, we teach Agile to other companies, so we applied the same approach to this project.
Contrary to common belief, the Agile approach does not require developing an MVP and then testing it on the market. Instead, we can test different parts of the product, including functionalities, UX, and performance, with the help of Innovators. You probably heard that technology adoption lifecycle consists of five groups of people: Innovators, early adopters, early majority, late majority, and laggards. Innovators, in particular, are extremely valuable for products as they can provide us with valuable insights before the MVP is completed.
We create a valuable micro product for Innovators, test it with them, gather feedback, and then iterate again. When we test something, it doesn’t mean that our users have to report bugs. Instead, we provide a complete and beautiful micro product without bugs and kindly ask users to help us build a better product by providing their opinions. By respecting our users and providing them with something useful, we can gather valuable feedback and improve our product accordingly.
The philosophy is simple: we develop, test with Innovators, gather results, do our homework, and iterate again.
Tech that we used: Angular, ngnix, Ionic, java, posgresql
Later on, one of our developers expressed interest in trying out .net for a specific functionality that was completely independent. Our management team allowed him to experiment and learn, and he was able to successfully create a microservice on the monolith architecture without any issues. This was proof to us that we were moving in the right direction. After 6 months of development, gathering results, adjusting the UX to users we finally got to the market release, but that is a story of sweat and tears and fight with totally different beast.