Web platforms
The application, the content system behind it, the deployment that carries both, and the payments your product needs. We build them, and we keep them running.
Those four were probably chosen at different times by different people, and they were never designed to agree with each other. The trouble is almost never inside one of them. It’s between them: a wording change that needs a deployment, a payment that succeeded but never reached your ledger, a framework upgrade nobody dares to start.
Much of our web work is on platforms that are already live, with customers on them. So we change one part while the other three keep serving, in your repository and your pipeline. When we build new, we build on Next.js, PayloadCMS and PostgreSQL, and we’ve moved a Rails product onto Next.js and Supabase.
- Next.js
- TypeScript
- React
- PayloadCMS
- PostgreSQL
- Supabase
- Stripe
- PayPal
- Alipay
What we do.
Your team can’t change a word on the site without a developer.
If every wording change is a deployment, the wording doesn’t get changed. We build on PayloadCMS, so the content model lives with the application and the people who own the words can edit them themselves.
You need to take payments.
Which provider, which currencies, and what happens when a refund or a failed charge has to reach the rest of your system: we settle those with you before anyone writes code. We’ve integrated Stripe, PayPal and Alipay, and most of that work was webhooks and reconciliation rather than the checkout page.
You need to be sure users only ever see their own data.
Checking permissions in the application means every new piece of code that reads the data is a new place to get it wrong. We put the rule next to the row instead, with Row Level Security, so Postgres enforces it for everything that connects. That’s how the logistics platform below works.
Nobody’s looked after the platform since it launched.
Dependencies go stale, the framework moves on, and every change costs more than the last one. We’ll be the somebody, if you want us to be. Upgrades, security patches and the next feature, under the same contract.
We moved a logistics SaaS from Rails to Next.js on Supabase.
The framework was the visible part. We also moved access control out of the application and into the database, 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
Tell us what you’re building.
Send a note or book a call, whichever you prefer. You’ll hear from us within two business days. Our clients are in the DACH region and across the EU, and we work with all of them remotely.