Satispay: the corporate web app of a European fintech
The website of a payments super app, rebuilt to speak to three different audiences and to make room for the products still to come.
The problem
In 2024 Satispay changed almost everything: a new payoff, People Paying People, and two new products for corporate welfare, meal vouchers and shopping vouchers. Everything except the website, which was still describing the company of a few years earlier.
The problem was not a cosmetic one. A site that serves consumers, shops and companies is holding three different conversations in the same place, and each of them ends on a page somebody has to find on Google. On top of that it has to house products that do not exist yet at launch. The real question was not how it looks today, but who updates it tomorrow.
How we solved it
The answer was to stop building pages and start building pieces. The UI Kit produced modular components, each with its own colour and content variants, and every component became a widget in DatoCMS. Whoever writes opens the CMS, picks the blocks, composes the page and publishes. Adding a section does not mean opening a code editor.
The fastest page is the one that was ready before anyone asked for it. The hard part is changing it quickly.
This is where the project gets technical. Next.js builds pages ahead of time and rebuilds them when the content changes, but the cache behind that lives in the memory of a single instance, and a distributed architecture has many instances: you publish a change and only some people see it. We wrote a purpose-built invalidation layer that propagates the update to all of them, so whoever publishes from the CMS sees the site change everywhere without giving up the speed of static pages.
Around all of this, REST integrations keep the help desk, careers and CRM connected: the site is not an island, it is where the systems Satispay already ran come out to meet the public. The result is not measured on launch day. It is measured at the next product, when a new section is needed and nobody has to call us.
TypeScript, Next.js, Node.js and Tailwind on the front end, DatoCMS as the headless CMS with the UI Kit components exposed to editors as widgets, all running on AWS (ECS, CloudFront, CloudWatch, WAF, CodeBuild) for a distributed, secure, highly available architecture. Help desk, careers and CRM come in over REST APIs. Performance is tuned down to the Core Web Vitals, because on a site that has to be found, speed is already SEO. The part we are proud of: a purpose-built invalidation layer on top of Next.js Incremental Static Regeneration, to get past the limits of in-memory caching in a distributed environment.
TypeScript, Next.js, Node.js and Tailwind on the front end, DatoCMS as the headless CMS with the UI Kit components exposed to editors as widgets, all running on AWS (ECS, CloudFront, CloudWatch, WAF, CodeBuild) for a distributed, secure, highly available architecture. Help desk, careers and CRM come in over REST APIs. Performance is tuned down to the Core Web Vitals, because on a site that has to be found, speed is already SEO. The part we are proud of: a purpose-built invalidation layer on top of Next.js Incremental Static Regeneration, to get past the limits of in-memory caching in a distributed environment.
Got something similar in mind?
Tell us what you want to build and we will help you find the shortest way there.
