How far a simple tech-stack can get you.
Every day you hear about new technologies:
New JavaScript Frameworks, new backend libraries, new frontend libraries or new cloud providers.
But which of these are really needed to make your app idea come true?
Maybe not many.
In today’s story, we will have a glance at how Rado, a Bulgarian software developer, built a software that grew to 9000 users within only two years, all of this on a very simple tech-stack.
You will discover about:
Business idea: Backstory of how it all started
Behind the curtain: The tech-stack and the team
What were the challenges?
What made it special?
What did we learn from it?
So, grab some popcorn and get ready to learn practical insights about a pragmatic yet powerful approach to developing a software.
1 – Business idea: Backstory of how it all started
In 2021, Rado was a CTO of Engineering at Product Hunt.
One day, his friend called him with a new app idea.
The conversation revolved around an app idea that aimed to address a common yet frustrating problem in apartment buildings – lack** of transparency**.
Many inhabitants are not happy about how things are being run. Some major problems are
Unclear communication:
Unclear status of broken facilities:
Unclear of how money is spent:
The friend wanted to help inhabitants to fill the knowledge gap by building an app that displays all information and with the help of Rado his idea could come true.
Rado thought to himself that he has not been coding for a while at Product Hunt, and he could start coding again a little during the weekends.
He agreed to join the project for a time frame of six months to get the project to a certain level where they can then continue without him.
So…this is where the story begins.
A fully self-funded app called Angry Building was about to be born.
2 – Behind the curtain: The tech-stack and the team
We will discuss the two ingredients for any successful project:
The tech-stack and the team.
2.1 - The Tech-Stack
Rado calls the used tech-stack fairly simple. Here is a list of technologies he used:
Database: PostgreSQL
BackendRuby on Rails
Web Frontend: Vanilla JavaScript and Rails UJS
Mobile App: React Native
Monitoring: New Relic
Hosting: Heroku
2.2 – The Team
In the first six months of the project, Rado worked on the app alone. However, as Angry Building gained traction and attracted more subscribers in 2022, Rado realized he needed assistance.
He turned to his friend Alexander Antonov and his agency, Raketa, to join the project to speed up the process of implementation.
As the project was gaining momentum and growing, Rado also decided to make a big decision: He left Product Hunt where he was working for 8 years to join Angry Building full-time as both a developer and a product owner.
3 - What were the challenges?
Challenge 1: Naming Conventions
In the example of Angry Building, Rado had the problem with choosing the right naming conventions.
Later on during the project, this caused confusion at times when talking to other developers or stakeholders.
What he learned through this challenge, you can read below in lesson 1.
Challenge 2: Database Structure
Rado needed different tax types for each bill.
It was challenging on how to store this information in the database.
On the one hand, he could have introduced more tables to make it more structured.
On the other hand, this would mean an overhead in complexity and later on maybe also performance.
Also, introducing more tables generally is more time-consuming in terms of programming, which in the early age of a startup can be crucial as time-to-market (the time it takes to launch a product) is very important.
How he managed this issue, you will learn in lesson 2 down below.
Challenge 3: Choosing the right tech stack
Most people take a very fancy tech-stack.
On the one hand, Rado wanted that all features could be handled by the tech stack.
On the other hand, he didn’t want to overcomplicate the tech stack if it did not add more benefits.
This is one of the aspects that actually made this project special. You can read more in section 4 to find out why that is.
What he learned and how he managed the challenge before even starting the project, you can read in lesson 3 down below.
4 – What made it special?
Contrary to common belief, Rado managed to develop the frontend of Angry Building using pure JavaScript without relying heavily on multiple frameworks and libraries.
He did use one library UGS (a Ruby library) which is very old itself, but it does its work.
And the UI still looks amazing, like any other webapps these days.
**One could say: **Rado’s practical approach to problems made complicated matters very easy, which can be crucial for the startup phase.
5 – What did we learn from it?
For every lesson, we will discuss the following series of questions:
What does the lesson mean in detail?
Can I have an example?
What are the disadvantages if I do not follow the lesson?
Is there a way to guarantee that this lesson is implemented in my next project?
Lessons for developers
Lesson 1: Introducing naming conventions for the team
What does it mean in detail?
**Naming Conventions become more important the bigger the project becomes **
Naming conventions can start as simple as naming functions, variables, and classes with certain patterns, but can go much further with having naming patterns for database columns, tables, API endpoint names and their descriptions.
Agreeing on which naming convention to choose is (mostly) a matter of taste:
There is no right or wrong here. There may be some rule of thumbs, but that will be part of another story.
Can I have an example?
A naming convention for a database could look as follows:
All table names should always be in singular form.
This means a table should be named
mouse instead of mice or
user instead of users
What are the disadvantages if I do not follow the lesson?
If you do not follow the lesson, it may have the following consequences:
More friction: Developers have to think more to come up with naming for variables. This time and energy invested in a small detail that could have been used for more important issues (design patterns, security etc.)
Harder to understand code: Looking over the code of another developer will be harder as naming change. As our brain does not know what to expect, it will have a harder time following through.
Harder to onboard new developers: Without naming conventions (in written form) onboarding new hires will be more time-consuming as the lead developer needs more time to comment on the code (via pull-request, pair programming etc.).
Is there a way to guarantee that this lesson is implemented in my next project?
Short answer: Yes.
Long answer:
So here are some tips how to make sure naming conventions are installed:
Document naming conventions:
Set the frame for the (new) team members:
Validate naming conventions:
If you need assistance to find processes to guarantee that conventions are followed through, feel free to get in touch with [email protected].
Lesson 2: Balance between pragmatism and perfectionism in architecture
What does it mean in detail?
Choosing the right tradeoff between a very holistic approach and a 100% perfect one for coming up with an architecture design that will never break in the future can be daunting.
Can I have an example?
Instead of introducing multiple tables with type, fee and other details, he replicated that tax structure by storing those data points in a JSON in a column.
That reduced the number of tables and the complexity, which was sufficient for the start of the project and made the team progress fast.
Later on, when the project gains more momentum and also money, he could still migrate to a more complicated database structure.
What are the disadvantages if I do not follow the lesson?
The consequences of being on either side of the extremes (too holistic or too perfect) can be as followed:
**Hard to scale technically with business needs: **Being too holistic on the technical architecture may not let the software scale on par with the business and bring the developer team to their knees.
Never the perfect time to start: If trying to gather all business needs to come up with a perfect solution, it may never be the right time to start, and the project may get delayed a lot.
Is there a way to guarantee that this lesson is implemented in my next project?
Short answer: No, not exactly.
Long answer:
This is a matter of many factors:
Having experience with software
Knowing the business domain
Knowing your client’s needs and his psychological behaviors
But as a little rule of thumb, here is a little tip:
Work with the Pareto-Principle (the 20-80-rule)
With 20% of the right questions, you will get 80% of the correct architecture design for the project. The other 80% of questions will only add to 20% rest of the architecture design.
Focus on the questions to get the big picture of the business domain and translate these into the IT architecture.
If you like to see other examples of how to use the 80-20-rules in IT projects, take a look at this LinkedIn poston how to only implement the most crucial tests for a software.
Lesson 3: A simple tech-stack can also bring your project to life
What does it mean in detail?
This means that not every project needs a very complicated tech-stack in order for it to become successful. The success is a business matter and the technical solution can be as simple (in particular in the early stage) without influencing the success of the business.
Can I have an example?
Rado only used JavaScript for the Frontend, without many or almost no frameworks or libraries.
What are the disadvantages if I do not follow the lesson?
You may end up using very complicated and an overhead of a tech-stack with following consequences:
Harder to find developers:
Increased implementation time:
Dependencies:
Is there a way to guarantee that this lesson is implemented in my next project?
Short answer: No, not exactly.
Long answer:
This depends highly on factors such as
business domain and
the requirements of the stakeholders.
Of course, anything can be implemented without frameworks, but the question is how the tradeoff is by spending the time yourself versus using someone else’s code.
In the example of Angry Building, Rado had both business domain knowledge and technical knowledge.
These two factors paired together made him like a Swiss knife to turn the project to a success.
He assumed that there would not be many fancy designs needed for the frontend.
He anticipated that most screens will simply have a table.
This assumption turned out to be true, and using pure JavaScript helped him tremendously.
Lessons for product owners
Lesson 4: Take user feedback with a pin of salt.
What does it mean in detail?
Users may not know the whole business domain and their feature request may not always make sense, so think and reflect about each of the feedback that comes in.
Can I have an example?
Rado as the product owner also had the responsibility to choose which features should be implemented next to best serve the users of the app.
His sales team always handed him the users’ feedback, but Rado always iterates through each one of those in great detail.
What are the disadvantages if I do not follow the lesson?
The disadvantages may be as follows:
Feature has not the right market-fit: Money will be invested in features that do not have much impact on the app and thus, it will neither help the company nor its users.
Project is delayed: Not choosing the right features may delay other more important features.
Is there a way to guarantee that this lesson is implemented in my next project?
Short answer: No, not exactly.
Long answer:
This is a matter of several factors, such as:
Business domains
Understanding the users’ needs
Prioritizing the needs
Looking at Rado, we can extract some tips from his approach:
Value customer feedback, but reflect upon it
Rethink and reflect each feature
Be open to other people’s feedback on the feature (like Rado with his sales team)