Why go the no-code/low-code route

“We buy commodities and we build assets,” is our guiding principle. But you need time to build those assets. So the question I always ask myself is: “How can we remove all extra tasks from the engineering team, so they can really focus on building assets?” Other companies do the same common tasks in various domains. These tasks can easily be accomplished using a low-code tool integrated into their hard-code stack. By using developers more efficiently, you can do more with a smaller team—which is preferable from both a budget and organisational point of view. More engineers is more fun, but also more problems, because you're turning into a big organisation, and then you get all the traditional problems of a big organisation.

“The best engineer is the one that can solve a problem without writing a single line of code” – Andreas Wixler, CTO of FINN, speaking on the alphalist CTO podcast #59

You can tackle this in two ways. You can hard-code only the core business code that needs it, and do the rest via APIs in low-code tools. Or you can get citizen developers: get the entire company automating processes in no-code and low-code tools.

How to create a start-up using low-code tools

No code was what got us off the ground in 2019, when we were seven people in a small room with no engineers. Just a nice idea of car subscriptions for everyone. As it was an asset-heavy business, we were looking for an asset-light operation to run it. We wanted to avoid the trap that many founders with engineering backgrounds fall into in the early stages of starting a company: engineering for the sake of engineering.

We debated various options, but with things kicking in and me as the CTO being occupied with recruiting, we just set up a webflow and connected it to a Google spreadsheet containing the five different car models that we had available. An intern built a website connecting some spreadsheets together. And this is how we got into no code with Make.

We soon moved to Airtable as we needed a better spreadsheet that can be accessed via an API. We continued on Airtable and it worked great to power our MVP. We had many tables and automation..

Furthermore, no-code gave us the flexibility we needed when we outscaled our providers. We have exchanged every partner in every single domain, as of now. Registration provider, 24/7 support provider, damage providers, compound providers, …. It would have been harder to adapt a hard-code stack to such changes.

We did this for three years, but then we realized there are some pitfalls. We reached the rate-limit ceiling. Five requests per second per base. We ran into limitations to the baseline items. I think it was 100,000 back then. Now it's 250,000. There are a lot of limitations to that.

So this is our guiding rule. If in the next ten years, you expect to have more than 50,000-line-items, perhaps you need to hard-code your core business processes. If you think: in the next 10 years, we won't get more than 50,000 rows, then go for Airtable, for instance. Airtable is great for internal tools such as employee portals, as I don’t expect to have 50,000 employees ten years from now 😉.

However, it is good that we already had three years of experience operating no-code and low-code before we set out to write our hard-code. Starting out using a low-code tool had given us the insights we needed to write good code for our complex operations.

And that is how our system evolved into what it is today. No-code and low-code tools working off an API-first, hard-coded database, hosted serverlessly.

Create an API-first hard-code set up

The idea behind an API-first, hard-code set up is to get the scalability of hard-code together with the accessibility of no-code for core business entities. It works by creating internal APIs in hard-code which employees call when creating an app in no-code or low-code.

The way we did it is that we have a serverless API-first infrastructure. Using lambda functions, it exposes about 35 APIs. An Invoicing API, a Payment API, a Creditworthiness API, a Lead API, an Offer API, and things like that. These are primarily REST APIs, which are simple HTTP APIs with CRUD functionalities.

Employees then call these APIs to use their data to create processes in low-code tools such as Airtable and Retool and even no-code tools like Make. 

Because of the accessibility that no-code provides, everyone within FINN can just run whatever process they like. For example, they can run a system that monitors a particular car and get notified when the car is in production. Based on that they can take further action, such as notifying the customer: "Hey, your car is in production. We expect the production to be finished in two weeks.” This allows us to build up excitement. And anyone on the team can set it up. That's the beauty, and this is exactly what we do right now.

Maintaining an API-first infrastructure

How we set it up

Our hard-code setup is like a traditional web tier application—just serverless running on AWS Lambda. We like how serverless just allows us to scale up or scale down with ease and stay elastic. It might not be the most cost-efficient, but the ease makes it worth it. It's also easy to analyze the costs of each service when using something like Lambda. We also use Docker containers for the local environment.

In general, we have a mission-based, cross-functional department setup. This means the choice of tools and language is a department-by-department decision. So the teams have the flexibility to decide: NodeJS or Typescript, Python or Go? Currently, we have about 85% in Typescript, 14% in Python, and about 1% in Go. But let's see, this might change. That's a flexibility that the department can go for.

What tests do you perform on your API-first infrastructure?

We follow the classic software development process. We perform end-to-end tests for the commercial aspects of our website. We have integration tests, of course, or you can also go for some contract tests. Unit testing is something the teams themselves decide. They decide whether they want to have 100% code coverage, or whether they go for some integration tests. 

How to migrate from low-code Airtable to hard-code

Migrating from low-code to hard-code takes time. Just to give you a number, we need around 118 partners, just to operate the car subscription business. We do it step-by-step. We’re starting with our most complex domain, which is the Operations department. We take the entity car, then we take the entity subscriptions. We put them together: deliveries, infleeting, defleeting, fleet management, insurance, damages, appraisals,…. It takes time.

Write good API documentation

Good API documentation is essential in an API-first setup, so we have technical writers within every department whose only role is to write the API documentation. We don’t have engineers documenting the APIs, because most would rather code and when forced to write would put in the minimum amount of effort. 

How to recruit good technical writers for API documentation

Our technical writers are usually people with a non-engineering background, but with very high attention to detail. In fact, in our recruiting process, we analyze candidates with a tool called Bryq to see how they perform in four categories, and attention to detail is one of those.

It's really not a miracle how to find such technical writers. If you go to, say, AWS, they have also lovely documented APIs and someone is doing that. You can just look at who is writing great API documentation at other companies. So this is what we did. For our first API technical writer, I just hired someone from Yandex Cloud.​​

Currently, we have two full-time employees and one intern working as technical writers, and most of them have a background in something tech-related. This also gives them the ability to review all our technical articles.

Our API documentation workflow

Our technical writers set up a CI/CD pipeline for all the documentation, using Redocly. We use OpenAPI, so once the initial specification file is in the repository, the engineers take care of updating it. For example, if the engineers deprecate or add a parameter, they just go to the repository and do this little adjustment by themselves.

Get non-engineers to automate processes

It is important to enable non-engineers to automate their processes in your company. I think they call it ‘citizen developers’. They need to be using no-code and low-code not just to access the data coming out of your API, but also for their regular business tasks. Like, imagine you show an Excel person how to automate things and give them the tools to do so? Because they are smart. The sky is the limit in what they can automate. 

In fact, automating is one of our core company values. We say: “You do it, you do it, you automate it,” which means you do it twice manually, and then automate it. 

You do it. You do it. You Automate it. – Andreas Wixler, CTO of FINN, speaking on the alphalist CTO podcast #59

We have a company-wide culture of using no-code and low-code tools to automate common processes. The majority of our employees—yes, our non-engineers—use no-code tools like Make (formerly Integromat) daily. I would love to see also customer care agents using no-code to a certain degree, but I think the fact that 60% to 70% are using Make daily is pretty admirable in itself. 

It is not just our engineers who use low-code tools such as Retool or Airtable for writing internal tooling. The best Retool I saw so far was built by non-engineers. They put a lot of love into it and added a lot of details.

So in terms of using low-code tools, I see a 50/50 split between engineers and non-engineers. But as CTO, you need to drive this organisational change and get your non-engineers to see no-code automation as an essential part of the business.

Onboarding new joiners so everyone automates processes using no-code tools

How do you get everyone involved with automation? It starts with good onboarding. You need to make people less wary of using tools—even if it means that as the CTO, you put your face in front of a camera and record a one-hour ‘how to use this tool’-video.

During their first week at FINN, employees participate in a mandatory onboarding process.  They get access to Airtable right at the beginning when they get their email account. It is that much of a company-wide tool.

Employees watch videos showing various use cases of low-code tools, such as: how to connect spreadsheets, how to connect to the customer relationship management ​​(CRM) system, or how to export a product feed. They play around in a demo Airtable where they actually create their own automation using Make. And they have a one-hour scheduled meeting for personal guidance.

Automate for fast growth

Pairing an API-first, hard-code infrastructure with low-code tools and an automation-first company culture with no-code saved us a lot of time. It allows our engineers to focus on what really needs their involvement, and allows us to do more with fewer people. It has been a great journey so far and I can definitely say that using low-code where possible allowed FINN to grow so fast in so little time.