FinUA: The Tech Journey

After 2 years in existence, we wanted to talk about the tech solutions we made.

Published in

FinUA

10 min readMar 4, 2024

Since FinUA is a tech non-profit, I would like to talk a little bit about the technological part here: how throughout our journey we created a very high load very fast-to-update website finUA.org, what technologies we used, but most importantly why we made those decisions.

Overengineering and Hammocks

One of the most inspiring people in the tech world to me is Rick Hickey. For those who do not know, Rick Hickey is the creator of Clojure. I have watched Rick Hickie's talk called “Hammock-driven Development”, and the philosophy he has resonates with me a lot: think why first. We kept the spirit of the idea.

Very often when we talk about technology, we dive right away into tech and implementation. When you have a hammer, pretty much everything is a nail, right? So when someone comes to you and says “Help me set up MongoDB” — something is missing in that question, why do you need MongoDB? What problem does it solve?

I feel like we very often forget to take into account the context and rush into implementation.

Our Context as of March 2022

During the war 8 million Ukrainians were seeking refuge in other countries. A lot of people were presumably going to come to Finland.

It is nerve-wracking to have to move to a foreign country, even if you planned it, let alone when you do not speak the language and have kids with you and about 3 days to make a potentially life-changing decision.

I decided to do something very simple: I wanted to create a source where people could easily find information on how to come to Finland.

The info existed but was not translated, not full, and in over 100 different places. De-facto use cases were not exactly by the book. The idea was to simplify and make it as concrete as possible: single-door principle, where people can find everything.

Now let's take a look at the facts of the situation and try to derive the requirements. Some very concrete and real context:

it is February 2022
thousands of Ukrainians are coming to Europe through Poland
the information is changing almost every day: new rules, new temporary protection status has been introduced, etc.
the information is scattered across different organization websites, some of it is translated, and some of it is not.
there are a few volunteers, who are not consistently contributing
they have no tech experience whatsoever
the Internet at the border is slow, a lot of people use expensive roaming
the information has to be checked, and verified, even if it comes from a governmental source, as the de facto process can be different

These nuances are very important. Normally, you start doing a project by defining specs, designs, etc. Here we started from the bare minimum: just text that provides essential information.

Iteration 1: Simple CMS

The task that we had was essentially content management of a wiki-like website. It was for all kinds of content, as in we could not predict the format: text, image, video, links, tables, anything, really. It had to be a system that allowed collaboration, historic versioning, different levels of access rights for a few dozen people, and most importantly zero dev pipeline, all at no to a minimal cost. That pretty much ruled out all the headless CMS systems and WordPress.

Now, let`s remember one important aspect: the Internet at the border is slow, and a lot of people use expensive roaming. That rules out Squarespace.

Requirements at the end:

The project has to be updated extremely fast
Minimum image/video content: roaming and speed
As simple editor as possible: non-tech people

At that point (2nd day of the war) I saw a website https://supportukrainenow.org/ and it became a great example of how to arrange information. Built with Notion.

We landed on Notion, which has proven to be the most pragmatic and usable solution to this day.

Now, for those who do not know, Notion can be best described as an “online text editor on steroids and done right”. You can create pages and any sort of content in them: it supports pretty much any embed. People mostly use it for note-taking. There are dozens of productivity videos about how to manage your life in Notion on YouTube, but for now, we will focus on the features that are relevant to us:

Simple text editor to add content, almost no onboarding was required for incoming volunteers.
Simple access level management: easy to give and remove access
Simple history versioning (you have to have a paid subscription, but it is nothing compared to other CMS prices)
Most importantly, we can easily make a notion page publically accessible, which effectively makes it a website.

Notion is for blog posts

Assuming you have followed the Notion hype on YouTube, you probably know that Notion is great for personal notes. But you can also share any page you want to be accessible through a URL on the Web. All you need to do is to create a Notion page, no special setup is needed. Then, click on the Share button in the upper right corner and use the toggle to share your page to the web. That’s it! You’ll immediately see the link to your new website online! The downside is: that the URL is rather cumbersome.

In this article How do I turn a Notion page into a “real” website? Marta Tatiana pretty much perfectly describes how to connect Notion page to a custom domain. We bought our custom domain on Namecheap and used super.so to connect the domain and Notion page.

Now if you went to Finua.org, you would see the notion page. We could edit Notion page, and the updates would appear on the website without any extra work.

Some downsides you notice immediately

Now, here are some downsides and whether they are critical:

Slow page updates (5 min) with super.so: After editing text inside Notion page, it would take a few minutes for the super.so page to update, so sometimes we had to refresh it manually. It is the fastest solution and the most simple one, so far, but just be aware of this
SEO could not be improved easily (advanced SEO optimization techniques are not possible as pages are autogenerated by super.so). Now what super.so provides out of the box is pretty good already, the overall Google Search Console and Google Analytics did not raise any flags. Generally, to improve our website discoverability, it would take us to code the solution to take advantage of real advanced SEO features.
Had to notify users manually about page updates (using Telegram Channels)

“Less lake pictures, more content!”

It is a quote by one of our first volunteers Oles. Some of the usual downsides of Notion webpage approach that are described in the blog posts, such as you’re extremely limited in terms of design are not an issue for us. Why making it pretty was not a big deal? As of 5th of March 2022, our webpage looked like this

Where Ukrainians come to Finland, the Internet is slow and roaming is expensive, like very. You want to have as little image content, as little video content as you can to ensure finding the info fast and there are no big visual files that take up the precious roaming money.

One of the biggest inspirations for this approach was a tech talk by Doug Sillars called Video Killed My Data Plan back in 2019. You can probably read most of what he talked about in Smashing Magazine now.

I encourage you to check him out. Yes, files cost them money. So beware of that if you are creating a product for users who travel.

Iteration 2: Let's build on top of it! Where we failed and where we went in the right direction.

As our tech requirements grew, we started to look into tech solutions to turn our notion website into an app. Especially those that we listed previously:

We did need a better SEO solution
We needed a better notification system for the users, we were doing everything manually
Faster re-renders — 5 min was a bit long.
Potential to include sign-in to be able to save pages.

Our gaze fell onto the NextJS Notion starter kit: https://github.com/transitive-bullshit/nextjs-notion-starter-kit.

Next Notion Starter Kit Way

NextJS Notion starter kit Pros: Works well if you need a very quick notion-to-nextjs solution with minimal tweaks and also when you have a small notion page structure.

NextJS Notion starter kit Cons:

If you have any depth, as in multiple nested pages in Notion, it will be critically slow.
no support for non-Latin page URLs (I submitted a PR though)
Was too hard to refactor, was easier just to use the Notion API Client inside our own NextJS app.

It seemed like the fastest option at the time, but it was de-facto just a wrapper super.so also used. It was extremely slow in dev mode with a large nested page structure, it was next to impossible to deploy it to Netlify. After working for a week with both dev env and a week for Netlify deployment, I gave up. It was too much refactoring to do for not too much gain compared to what super.so was providing. I would still like to emphasize, that the solution is good, just not for the project we had.

Notion is a religion

At some point, we found ourselves using Notion for both external information (aka website) and all of our internal docs. We found ourselves using Tally forms to collect the information we needed and connected it to the Notion database. We found ourselves storing our internal docs there. We used it as a database for our NextJS version via API.

It is just that convenient. And it comes at a pretty reasonable cost: 35 dollars for Notion + 12 dollars for super.so to deploy it.

I could be a Notion advocate, if they offered for sure.

Iteration 3: The ultimate upgrade and conclusions we made

The best code is the code you did not write.

Building the iteration #3, we still brought it into our tech philosophy. We wanted to reuse 100% of what we had, building only the necessary parts. We realized, that NextJS was a good option to go: we have templates, the ecosystem is very large and it is easy to find people to maintain.

This is what we call FinUA 2.0. As time progresses, our vision and requirements get more refined and focused.

However, for the first two years of FinUA existing, Notion + super.so was good enough. It was easy to connect Google Analytics to it. We started onboarding other non-profits with it. Nobody ever had any problems with editing it, even with zerotech skills. We in fact still brought Notion pages through API to our FinUA 2.0 version.

I guess, the conclusion I could make is that overengineering is a dangerous game. I am happy with the decisions we made: to stick to the basics and no code. I cannot wait to tell you more about FinUA 2.0 in the next posts!