Hello, lovely fellows! This is gonna be my first article here; therefore I don't want to dive into technical details. You will be reading about the journey of FINN, a leading German mobility startup, started their business with No Code and then slowly migrated to more code (mix of no code and hard code with databases). The company didn't invest too much time in the beginning for the coding. It just started so simple and overall lead to a great success in several years:

• 60% process automation
• 17% increase in process efficiency
• 75% increase in time savings

The company had several phases that I will mention in this article chronologically:

1. Prototype (Google Sheets, Webflow, Zapier, Hubspot)
2. Things look good (Step 1 + Airtable, Integromat, AWS S3)
3. It's getting real (Step 2 + Looker, Serverless (AWS), Retool, Sync, Next.JS, Vercel, Netlify)
4. No Code to More Code (Step 3 + PostgreSQL, NocoDB) - with USA expansion.

So shall we begin?

1. Prototype

Everything was new and things had to move fast because the company was just founded. At this stage, there was no developer in the company but some talented people who knew how to use no-code website builders such as Webflow. On top of that, there was a quick design with blue colour and a cute logo. All the product data was coming from Google Sheets. It was a static e-commerce platform quickly built on manual editing on Google Sheets and automated with Zapier. All customer and deal data was being managed on Hubspot. It was working... Money making just started.

2. Things look good

After several years as a tech lead in a small startup in Munich, I decided to look for new opportunities in Munich and I found FINN. It was/is a promising startup. At the same time I joined, the company found Airtable and now they were thinking about an advanced Google Sheets. The good thing is that everyone could sync easily on Airtable without knowing any code and it had APIs which could be used in automation tools in the future. The first structure was built without worrying about the performance issues, as you may guess. There was a huge Airtable base with a lot of tables. In the beginning, it was only a few... But the storm was gonna come!

The change started by hiring Mr. Vova and Mahmoud. They built the first product listing service and converted the website to a real application with Next.JS.

3. It's getting real

The number of customers kept increasing. Because people love car subscriptions in Germany. The database is getting heavy and heavy - big fat Airtable base which we call Vehicle Subscription Management base yet it is the database for all departments... It sounds scary.

Then they started to build the checkout process on top of services. They also started to display products via a service. Eventually, there were a few small services written in Python and JavaScript (TS) which were responsible from non-static pages in the website. Overall, these services were only talking to Airtable and Hubspot to exchange the data. Some APIs were served directly from Next.JS and Vercel. The change started gradually.

While the company was happy that they were breaking records, the "database" was getting heavier. There is an API limit of 5 requests per second for each base. Imagine that the whole company working on a single base with lots of automation tools in place. Most of the processes are not coded, they are all no-code with Integromat and this puts pressure on Airtable with such as syncs, paginations, CRUD, etc... The company had to look for solutions. They found an open source alternative called NocoDB. They liked the product but it's really in the early stages; therefore they build a dedicated team which is working on NocoDB development. They could now use PostgreSQL on the backend and use NocoDB as the user interface on top of the database.

Until they get there, they had to work with the current implementation. They built a cross-department squad to work on this issue to gain performance and make the customers happier. They spent three weeks. What did they do to gain performance in Airtable?

• Reduce the number of bases by separating them as much as they can
• Use synced bases for read-only operations
• Use Sync (https://www.sequin.io/) to move Airtable to PostgreSQL slowly
• Link NocoDB to Sync and use NocoDB API for unlimited read-only operations

Now the performance was much much better and no more timeouts were present, thanks to the huge effort!

4. No Code to More Code

The company was growing and expanding to the USA. This time they wanted to do things right. They wanted to use NocoDB APIs for the services responsible for the USA. There are some bug fixes and improvements have to be done, but it's still okay to use in production - unless you are very careful. Version upgrades can be a pain in the a**.

They now use NocoDB for www.finn.auto/en-US/ and so far, so good! Slowly they are moving out from Airtable to NocoDB. In a year or two, probably most of the things will be running on NocoDB - a user interface on PostgreSQL. :)

But why are they insisting on something similar to Airtable? Because not everybody is a tech guru and creating reports/interfaces/tools for business operations takes too much development time. The company wants to enable people to do their jobs as smooth as possible. The data is easily read and manipulated with specific permissions. You still have the power of Excel but you use a real database such as PostgreSQL. This is a huge benefit for performance in all departments and sections.

Why did FINN choose No-Code to start?

In the early phase of a start-up which is working on green-field - no blueprint how to build a car subscription business, other than e-commerce - it’s key to have elastic schema (easily adding and removing columns) because the ideas are getting shaped up regarding the structure in time.

Thank you for reading my first post!