Today we are going to talk about a way to know if your startup project is viable from a technological point of view.
Before anything, I want to talk about the book that I based a little bit for this post. It’s called “The Fundamental Laws of Software Project”. If you want to buy it, check the link https://amzn.to/3eYTWFm
It’s a short book, about 100 pages, but it shows very good conceptual content. It doesn’t teach you how to code, but how to become a better coder. It’s worth reading.
So, let’s go.
Technology is often the factor that defines if a startup will survive or not.
I’ve seen some projects that have died simply because they didn’t apply the right technology and in a timely manner.
So something as important as technology should have a special treatment by the founders or those responsible for the project. And the technology I am referring to is the application itself, its development, the programming language used, the code implementation and its performance, both in delivery and maintenance.
These days, its importance has become even more accentuated. Many companies have had to rediscover or even reinvent themselves technologically.
The whole world has gone remote work, and that’s one of the reasons for the digitization of services to be so high. The forecast is that this scenario will remain for a good time and the demand for professionals will increase more and more.
Technology is essential, as we already know, and it will be present more and more in people’s lives. So today we’re going to discuss how to find out if a startup project is viable from a technology perspective.
It all comes down to this formula:
Don’t be scared, it’s a simple formula to understand.
What it means is that the desirability (or feasibility) of the project, represented by the letter D, is calculated as the values it will deliver – represented by Va and Vf – added together and divided by the effort required – represented by Ei and Em – to implement it.
A simple example for you to understand: Imagine we’re going to develop an algorithm to predict with 99% certainty the closing value of a cryptocurrency the next day.
The value that this algorithm would deliver would be huge. Whoever has this algorithm would quickly become a millionaire.
But how do we create this algorithm? Creating this algorithm would be practically impossible.
Cryptocurrencies are valued based on various factors, including human emotion such as fear, motivation, and enthusiasm, which are currently unpredictable. Therefore, the effort to create this algorithm is currently unattainable. Some of the analyses we have today are based on speculation about long-term scenarios and are not guaranteed.
In this example, desirability goes to zero because it delivers a lot of value but has a very high cost or effort. Sometimes the effort is inconceivable because we don’t have enough technology to deliver the product to the market. Therefore, it becomes a project with high value but with an prohibitive cost. It’s that simple.
Project Value
About the values in the numerator (top part) of the equation, they can be divided into two:
- Short-term value (Va), which is the one delivered immediately;
- And the long-term value (Vf), which it aims to deliver in the future.
But we will not focus on them, as they belong to the startup. And therefore they are the responsibility of the idea itself.
And today’s focus is on the denominator of the equation.
Project Effort
The efforts, which are under the division, also divide into two. They are implementation and maintenance.
But why do we need to separate these two values? You will understand why…
The implementation effort is the one necessary to create your project from scratch. To take it off the paper. And the maintenance effort is how much it costs to keep that project online.
Here at Operar, we work on these two factors, implementation and maintenance.
So how do we increase the desirability of a project? By reducing the two efforts to the lowest possible!
And for that, we have two key concepts, MVP and continuous delivery.
Back to the equation. If you decrease the efforts, automatically the feasibility of the project increases. That’s mathematics. And to decrease the efforts, there are two different strategies. The implementation effort, we decrease by adopting an MVP instead of a complete project.
MVP stands for “minimum viable product”.
In summary, it’s reducing your idea to the minimum it needs to solve the problem. It has to do with the Pareto Principle, or also known as the 20/80 rule.
Pareto was a sociologist and economist who created this principle by stating that 80% of wealth is concentrated in 20% of the population, and this proportion extends to many other things. The same for MVP.
We seek the 20% of the project that represents 80% of the expected result. These 20-80 are only symbolic, they do not need to be measured strictly, especially when your project deals with intangible things (which are difficult to measure).
So, for MVP, we take the most important functionality of your application and invest all the effort in it. That’s an MVP.
It’s important to mention also that even though you want a complete and robust project, by the formula we can see that the implementation is less relevant to the feasibility than maintenance. If the project tends to be long-term, the implementation effort tends to be less relevant over time.
Let’s say you have the implementation effort (or cost) of $10,000.00 and your maintenance effort is $1,000.00 per month. After 10 months, the maintenance cost equals the implementation cost.
As time goes by, this cost (of implementation) becomes a distant memory, and most, if not all, projects have an indeterminate deadline.
This is because when you come up with a solution, you want it to be long-lasting, to work for a very, very long time. The longer it stays in the market, the better for society, and for you, and the maintenance effort has a greater long-term impact.
Have you ever heard someone say that for a company, it is more important to ‘react’ than to ‘act’? It is true. Every project changes over time. It changes, or it dies. Therefore, maintenance is more important because within it are the changes of the application.
Oh, and to be clear, when I refer to ‘maintenance’ itself, I don’t mean just the act of ‘fixing’ something that is broken.
Maintenance comes from the idea of maintaining the project. And this includes any changes, additions and/or deletions of functionalities. Since we have concluded that the maintenance effort is the most important, how can we reduce it?
First of all, it doesn’t make sense to have a project that is cheap to create, but expensive to maintain. Would you buy a car for $10,000.00, knowing that you would have to spend $3,000.00 a month just to keep it running?
No, nobody would buy it…or I hope so.
With software, it’s the same thing. It doesn’t make sense to have a low implementation, if to keep the application running, you have to spend a fortune.
There are 4 essential points in software that reduce the maintenance effort, and they are:
- Documentation;
- Versioning;
- Code architecture;
- Testing.
Documentation
Documentation is the instruction manual for your application. It serves both for those who will use it (operation or end user) and for those who will work on the project. Integrating a new person into the team, no matter how experienced and expert they are, will take time.
To understand the entire application, the code behind it, you need to know the whole operation, the rules and the structure adopted, and to reduce this time, well-done documentation helps a lot.
Even for those who created all or most of the code. When returning to the project months later, they may have forgotten what they did and how they did it. And certainly, documentation saves precious time.
Versioning
As mentioned before, every software project changes over time. That’s a fact.
Instead of storing all changes to the application code in a folder, with names like “application_final_version”, “final_version2”, “final_version_now_it_will_work”
As a better option, and if we keep all these versions in a repository, automatically, historically linked and accessible to as many computers as we need?
This exists, and the most famous type of versioning is called Git., but I won’t go into its functionality. There are hundreds of commands and this is a topic for another time.
But in summary, with it you store all changes made to the code, have the entire historical evolution recorded, can keep the code integrated on all machines and best of all, you can separate development from production.
Without a versioning service, the difficulty in evolving with the code increases at least twice.
Coding Pattern or Coding Architecture
About software architecture, there are different ways to develop an application. DDD, Clean Architecture, Microservices Architecture, among many others that can be applied together.
I don’t say that there is one that is the best. But it’s important that the code be consistent.
What does that mean? That it follows the same pattern throughout the code.
Why does this matter? For those who will read and understand your code, if it is following a unique way, it becomes much easier to read and understand.
As a result, it subsequently reduces the time of getting used to it and the maintenance effort.
Testing
Well, we have reached testing. Last but not least. I also don’t want to go into too much detail, as it is a very broad topic and we would take all day.
Testing is essential. That’s it. And tests can be done in two ways: manual and automatic.
Automated tests provide much greater protection against failures (not exemption, let it be clear) and at a much lower cost. And tests are also strong allies to the three items I mentioned earlier.
Creating controlled scenarios, with expected results for the code are efficient ways to ensure that your application is being done as expected. There are many types of tests.
For those who want to know more, look for the term TDD, or “Test-Driven Development”.
It’s a paradigm shift from the common developer path.
Example of MVP application and maintenance
Well, to illustrate, I’m going to talk about a scenario. It has nothing to do with software, but it fits very well with what we talked about. I want to set up a cafe, and in this cafe, there are two things that I want to implement to make it stand out in the market. One of them is to have at least 15 different types of coffee. Another highlight is bilingual service. In addition to our language, those who work in the cafe can serve in two languages. Cool right? Oh, and to explain the current scenario of the hypothetical cafe better. I already have a supplier who can sell me the 15 types I need. This defines the context of my project. Now let’s think about the MVP. So, to extract it, we need to think about two things. What features of the cafe can I implement and what is the cost?
- Point 1. I already have a supplier, so I don’t have any cost to look for or research who will provide me the raw materials;
- Point 2. I should invest in a language course for the people who work with me or hire someone who already speaks English (or any other language).
If I pay for a course, it would have a huge cost immediately.
If I hire someone, it will be cheaper. So, simply. My first MVP looks like this:
- A bilingual person in service;
- The most diverse types of coffee.
That’s it. This is my implementation.
After a period to validate, we will analyze the following:
- Was there demand for service in another language?
- Which types of coffee were more sought after? Did any have irrelevant sales?
Notice that these are information that I can measure, and I can make maintenance of my product, or in this case, my cafe. And with software, it is quite similar. With an additional advantage that is to be able to automate many of these measures.
Taking advantage of the moment, a sentence from Peter Drucker: “If you can’t measure, you can’t manage”.
I hope you liked it. If you liked the content, like, share and stay alert for new content that I will post to teach more about development.
If you need a solution for the development of your startup, you’ve come to the right place. Contact us!
