Web platforms

The application, the content system behind it, the deployment that carries both, and the payments the product needs.

A web platform is four things that have to agree: the application, the content the business can edit without a developer, the payments, and the place it all runs. We build the four of them, then keep them running.

  • Next.js
  • TypeScript
  • React
  • PayloadCMS
  • PostgreSQL
  • Supabase
  • Stripe
  • PayPal
  • Alipay

A Rails application, moved to Next.js on Supabase.

For a logistics and transportation SaaS in Germany, we modernised a Ruby on Rails application to Next.js on Supabase. Access is enforced in the database with Row Level Security, and the platform issues ZUGFeRD invoices, the German e-invoicing standard.
Client
Logistics and transportation SaaS, Germany
From
Ruby on Rails
To
Next.js on Supabase
Access
Row Level Security, enforced in the database
Invoicing
ZUGFeRD

The client’s name is withheld by contract. Everything else is what was built.


Where we come in.

Four situations, and most platform work we are asked for is one of them.
  • The content has to be editable without a developer.

    A platform where every wording change is a deployment does not get its wording changed. We build on PayloadCMS, so the content model is versioned with the application and the people who own the words can edit them.

  • Payments are a product decision before they are an integration.

    Which provider, which currencies, and how a refund or a failed charge reaches the rest of your system: those are settled before any code. We have integrated Stripe, PayPal and Alipay, and the work that matters is the webhooks and the reconciliation, not the checkout page.

  • Access has to be enforced where the data is.

    Checking permissions in the application makes every new reader of that data a new place to get it wrong. Row Level Security puts the rule beside the row, where Postgres enforces it for anything that connects. That is how the platform above works.

  • The platform needs to be somebody’s job after launch.

    We stay on when that is what is wanted: version upgrades, dependency and security updates, and whatever the product needs next.


When to bring us in.

  • When a framework version is far enough behind that upgrading is a project.
  • When the product has to start billing and nothing bills yet.
  • When the marketing site and the application have drifted into two codebases.

Tell us what you are building.

We work in German and English. Our clients are across the DACH region and the EU, more than seven of them since 2022.