Surviving guide for a tech startup aka How to properly bootstrap your startup - Part 2
We highly recommend that you read the first part of this article: Stop building sandcastles aka How to properly bootstrap your startup - Part 1
Introduction
Your startup has a name, and a good base, now it's time to jump in. You want to start developing your product. But how should you proceed? What are the risks? How can you avoid traps?
The Great Idea (again)
As a serial entrepreneur, I want to launch a company with the purpose to offer an advanced and easy-to-use platform to purchase high-quality eye wear at affordable prices, creating a unique, efficient, and memorable shopping experience to all.
Focus on your core values
Our target is to create a platform to support the sales of our high-quality eye wear. But as a traditional e-commerce website, we need to have some support, maybe a chat. You have 2 possibilities at that point, which could be answer by a simple question: is a customer chat support on your website the core of your business?
That's how you decide what you need to develop, and what you should not.
For example, I need:
You can find a lot of alternatives on https://opensource.builders/
Why do I recommend this? Because every line of code is a liability: you need to maintain it. So do you want to put your money on rewriting an entire system of invoicing, or re-use existing battle tested solutions ?
To mobile or not to mobile
Should you launch your product on iOS and/or Android? Only a website which is compatible with mobile? Both?
The answer is simple: $$$.
Like I said, every line of code is a liability. If you increase your lines of code, you increase your liability.
Ask yourself, why ClubHouse started only with iOS
Furthermore, don't forget the rules associated with the stores: Apple has a lot of rules around user to user communications: you should be able to block a user, report a user, and so on...
Our opinion is that you should not go for mobile apps first, except if you have an explicit need.
To SPA or not to SPA
One big subject is should I use a SPA?
But Loïc, What is a SPA?
According to Wikipedia:
A single-page application (SPA) is a web application or website that interacts with the user by dynamically rewriting the current web page with new data from the web server, instead of the default method of a web browser loading entire new pages. The goal is faster transitions that make the website feel more like a nativeapp.
What people are not telling you, is that there is a drawback, and a big one: the SEO value.
But Loïc, what is SEO?
And again, according the Wikipedia:
Search engine optimization (SEO) is the process of improving the quality and quantity of website traffic to a website or a web page from search engines.[1] SEO targets unpaid traffic (known as "natural" or "organic" results) rather than direct traffic or paid traffic. Unpaid traffic may originate from different kinds of searches, including image search, video search, academic search,[2] news search, and industry-specific vertical search engines.
AKA can people find your website on Google.
So, do you need SEO (like an ecommerce platform)? If yes, don't do a SPA.
Some ways exists to give some SEO values to your SPA, such as SSR, but we do not recommend it as it increases drastically the complexity
Furthermore some technologies can have the good parts of an SPA, without the bad sides (Phoenix LiveView)
SPA, here we come!
We recommend Angular. Why? Because it's strict: you should do everything like Angular says or it will not work. Also, it uses TypeScript, which is a super set of Javascript making your code much more readable and maintainable. You should also use SCSS and Material instead of raw CSS in order to have clean style sheets.
Backend/API
The backend/API is what is going to do the interface between the database and your customer.
Here is a list of languages we recommend for the backend:
- Python with Django
- Elixir with Phoenix
- NodeJS (typescript) with Express
- Crystal with Kemal
We tend to favor open source products over proprietary/expensive ones, which is why we usually avoid things like .NET, but if you really like C#, you have .NET core, which is open source and available on Linux.
Database
As a sysadmin, I'm tired of seeing people saying that SQL databases are not scalable, especially when the person on the other side does not know the technology. So do me a favor, and follow our recommendation: Postgresql. Why? Because:
- it's well maintained
- it's open source
- it's very performant (we have a cluster that can take 200K insert/seconds Average, and another one which has 78TB of data raw)
- Every cloud provider has it as a DBaaS.
- Very easy to set it up locally
Another acceptable choice is MySQL/MariaDB.
Whatever you choose, please don't use an auto-increment for your primary key, use an uuid.
Bad Database
Let's be clear, you are a startup, your target is to launch and operate easily. So except if you have a very specific requirement, it will not be necessary to use anything else.
There is one database that I would strongly discourage to use: MongoDB. It is the easiest way to create a mess in your startup, it's hard to host after they changed the license, it's expensive and it's just not scaling that well in a team, as they will lose time not working on proper constraints.
Hosting
The most critical part of your setup. It will shape your entire startup, including the cost, maintenance, agility, performance and security.
Good
We recommend a PaaS: Clever Cloud. They are a crazy bunch of French people, based in the fabulous city of Nantes. They have a presence all over the world: US, Europe, Asia and Australia (soon in Saudi too).
Furthermore, they follow all standards of industry, so you can easily get out if you want (but you don't want, trust me).
Not Good
Our recommendation is to not go with AWS, Azure or GCP: it's expensive, you have too many options, and it's complicated to operate. Don't get focus on the free credit, it's a trap to lock you in.
Asynchronously
If you do some e-commerce, you are going to send some emails for:
- order
- followup
- registration
- etc...
This action should not be linked to the other: sending an email should not block the "thank you" page for instance.
We highly recommend using RabbitMQ to manage all tasks asynchronously.
Conclusion
I hope those 2 articles were useful to you or someone you know and I wish you good luck with your venture ! Like usual if you have any questions, do not hesitate to ping me on Twitter.
If you have a problem and no one else can help. Maybe you can hire the Kalvad-Team.