As a developer with over 8 years of experience, I have never been a strong believer in low-code or no-code tools. Even now, I have my doubts about their effectiveness.
Throughout my career, I have tried a wide variety of technologies and frameworks, including various backend and frontend frameworks, different programming languages, native apps, and even blockchain. I have also worked with both monolithic and microservice-based architectures, and have experience with devops and deploying applications to the cloud.
One thing I have realized is that traditional development methods can be a barrier to startups, as it can take weeks just to set up the basic structure of a project using a framework like React, and even longer to implement even a few key features.*
This is why I am now open to exploring alternative approaches, such as low-code or no-code tools, that can help speed up the development process and make it easier for startups to get off the ground.
How I created my projects
Once I met some guys from my college who had ideas worth building.
I didn't think about my startup, but there was a lot of technical knowledge, a lot of free time, and a wild desire to take part in something interesting.
Looking back, I realize that we were spending too much time coding and never actually getting close to completing an MVP. Using no-code tools could have helped us move faster and validate our ideas more quickly.
However, I also recognize that no-code tools have their limitations, and that ultimately you need to make a choice between building something quickly to validate your ideas and then having to start over with a more robust and scalable solution later, or taking the time to build something robust from the start using traditional development methods. Each approach has its own pros and cons, and it ultimately depends on the specific needs of your project.
When it comes to creating an MVP for a blog, there are a few different options to consider. One approach is to use a no-code tool like Wix or Tilda, which can be quick and convenient to use, but can be difficult to scale and offer limited customization options.
Another option is to use a low-code platform like WordPress, which offers a wide range of ready-to-use templates and integrations, but lacks the flexibility and customization of a traditional development approach. Additionally, scaling and deploying a WordPress-based MVP can be more difficult than with a more customizable solution.
One more is to use a full-stack framework like Django, which offers a built-in admin panel and a range of ready-to-use components, but requires a significant amount of programming knowledge and can be difficult to deploy.
Finally, you could use separate templates for the frontend and backend of your MVP, which can be easy to scale and customize, but can be time-consuming and expensive, and may require a team with specific expertise.
Ultimately, the best approach will depend on the specific needs and goals of your project, as well as your own level of technical expertise and available resources.
That said, Firebase seems to be the most optimal way.
Why Firebase?
Firebase is a great choice for a developer because it offers a ready-made backend with a variety of authentication services, including Email and Google. This means that you don't have to start from scratch and can focus on building your app.
Ready-made backend with authentication services
Fast and convenient database
Subscription to updates for collections (useful for a chat app)
Hosting available
The only potential downside is that it can become expensive once you have a large number of users. However, this can be addressed by planning ahead and budgeting accordingly. Overall, Firebase is a powerful and convenient option for developers looking to build an app quickly and efficiently.
In general, when starting a new project, there is a tradeoff between building something quickly and then having to rebuild it later, or taking the time to build something more robust and scalable from the start.
Firebase can be a good option if you want to move quickly and validate your ideas, but be prepared to switch to a different solution later on.
Ultimately, the right one will depend on the specific needs and goals of your project.
My first experience with MarsX was at a company where we were looking for a way to simplify and streamline a large, complex project that had been built using Django, React, and Kubernetes. The project was expensive to develop and host, and was slow due to its reliance on microservices.
At first, I was skeptical about the idea of rewriting the entire project using a new and relatively unknown programming language like MarsX. However, I decided to give it a try, and was amazed at how quickly I was able to recreate the project using MarsX. Not only was the development process faster and more affordable, but it was also more enjoyable and less cumbersome.
Furthermore, MarsX didn't impose any limitations on us, and we were able to quickly implement and test new features, and iterate on our ideas.
The concept of microapps completely changed my perspective on development, and now I understand that if I ever start my own project, it will be built on MarsX.
I often think about all the great ideas that are discarded or abandoned, and I believe that MarsX has the potential to bring these ideas back to life and give them a second chance.