Jimdo Payments

I joined Jimdo at the end of December 2025. The job: design and lead the team building a new way for small businesses in Germany, Austria and Switzerland to get paid. Yoga instructors, photographers, nutrition coaches, small shop owners. The product needed shareable payment links, invoices customers can pay straight from the email, a public payment page, a guided setup, and connections into Jimdo's booking and shop features, where money already came in but had nowhere to land.

There were eight of us. Medina Vultur, Miklos Toth, Kevin Rademan, Pooja Gowda Thittamaranahalli, Hauke Stange, Mario Trucco, Mattia Pietroboni, and me. We met in person for the first time at an offsite in Hamburg, ate Rindergulasch mit Spätzle, and started building the same week.

Five months later, on 19 May 2026, Jimdo announced its new positioning publicly: a platform that helps small businesses get found online, get booked by clients, and get paid. Our team built the last part.

Jimdo was known as a website builder. The new direction needed three things working together: helping the business be found online (already done), get booked by clients (also done), and get paid (not yet a product). Some payment features existed inside other parts of the platform, but nothing in one place a customer could use.

The users are not big companies. A yoga instructor in Munich. A photographer in Vienna. A nutrition coach in Hamburg. The corner shop in Zurich. One person doing sales, delivery and accounting between clients, often from a phone. If the product needs a manual, they go somewhere else.

We had five months until the launch event. No existing code, no designs to start from, no direction for payments inside Jimdo. We had the design system and a deal with Stripe, the company that processes the payments.

First decision, day one: build the prototype in code on top of Jimdo's design system, not as static pictures in Figma. Every element coming from the real system. Every screen actual code an engineer could open. Whatever we agreed on, the engineers could take and use without redrawing it.

January was the foundation. The basic screens for creating, editing and listing payment links, the table views, navigation, getting the design right. February and March were the heavy months. Invoices, quotes, QR codes for bank transfers, PDF previews, one shared form for creating any kind of document, the mobile layouts, the status labels that show whether something has been paid.

March and April were testing. We put a usability testing tool directly into the prototype so real people could click through the actual screens. We ran sessions behind a password, tested in German and English. After each round, dozens of small fixes: words, spacing, button behaviour.

April and May were the guided setup and the public payment page. The step-by-step flow that takes someone from signing up to receiving a first payment. The page the customer sees, with the business owner's logo and colour at the top. The Stripe connection. The German translation. The last weeks were about connecting payments to the booking and shop features inside Jimdo, and final polish before the launch event.

231 code changes across five months. About 198 of them mine. The rest came in from the team as they reviewed, fixed things, and started building the real product on top of my prototype.

Five main screens for the business owner, plus the public payment page the customer lands on.

Overview. The main screen. Revenue for the year, the most recent transactions from payment links and invoices, and a small menu next to each row to copy a link, mark something as paid, or send a reminder without leaving the page.

Payment Links. The first thing a new user sees when nothing has been created yet. A short explanation of what the feature does, and one button. Once they tap it, the same screen turns into a checklist that picks the setup up where they left off.

Invoices. Documents with the business owner's logo and colours, a payment link inside, and a QR code so the customer can pay by bank transfer. Invoices are part of the paid plan, so the empty screen explains the value and offers the upgrade in the same place.

Settings. The four things that actually change from business to business: tax and billing details, branding (logo and colour), the payment provider connection, invoice numbering and tax rates. One searchable page, no menus inside menus.

Payment page. What the customer sees after tapping the payment link. Business logo and colour at the top, payment form below. On a computer the summary sits on one side and the form on the other. On phones they stack.

The prototype was the product spec, not a separate document. Engineers opened the same code I had been working on, read each piece, and copied the pattern across. No translation step in between.

I used Jimdo's design system as a hard constraint. Every space, every colour, every element came from it. The rule I gave myself: if I needed something the system did not have, I worked with the team to add it instead of inventing my own version. That kept the look consistent across the whole product even while I was finishing a new screen every week.

One creation flow for payment links, invoices and quotes. The user learns it once. Moving from one document type to another changes which fields appear, not how the flow works.

I used Claude Code as a coding assistant throughout the build. It made the typing faster, which meant I could try an idea, see it on screen, and decide if it was right in the same afternoon. The decisions were still mine.

Jimdo announced its new direction publicly on 19 May 2026. The payments product was built, tested with real users, translated into German and English, and ready to go live.

The prototype became the actual product definition. Engineers building the final version were looking at the same code I had been working on for five months, not a separate document that had gone stale.

What we showed on a laptop at the launch event was what a yoga instructor in Munich could open on her phone the next morning.

Small teams that own the work from start to finish move faster than larger teams that pass it between departments. There was no review queue between research and engineering. A call in the morning could be a working prototype that same afternoon.

A prototype made of the real elements answers questions a static picture cannot. What does the popup look like the moment the user taps back? How does an empty screen read next to a screen full of data? Those questions come up the moment you have to build the thing, and they are easier to answer when the prototype is the thing.

The best way to get a team to agree on what to build is to give them something they can click. Five months of reviews ran on one link behind a password. Product, engineering, leadership and legal all opened the same page. The discussions were about whether the product was right, not whether the documentation was up to date.

Claude Code was a real part of the process. It made the typing faster but did not change the decisions I had to make. The thinking is still the slow part, and it should be.