Einmal noch schlafen

Why it’s built this way

Four places where it could have gone differently.

• A new calendar is one row in the database

  Every customer used to get a running instance of their own, with a proxy entry and a certificate. The back office needed nearly the rights of the server administrator for that. And every order was a chain of steps that could break in several places. Nobody needs the isolation all of that bought: all calendars run the same code, and the order data sits together anyway. Creating a calendar now means writing one row to the database.

• A hosted checkout instead of a payment service of my own

  Payment used to run through a service I had built myself: around 3,000 lines for exactly one provider, with the API secret in the log and empty error handling. The hosted checkout charges a lower fee, brings Apple Pay and Google Pay with it and produces the invoice with the tax breakdown at the same time. For an impulse buy of just under five euros on a phone, those two wallets are what decides it. The price is a dependency on someone else’s service.

• No user account for the recipient

  The plan had been an account per calendar in a sign-in service of my own. But the complaint from real use (“you have to log in again all the time”) was not about identity, it was the cookie lifetime. Accounts would not have fixed it, and they would have sent grandparents who only want to look at a photo through a sign-in flow. So I fixed the lifetime and left the accounts out.

• Design first, pay afterwards

  The other way round would have been simpler: no unpaid drafts taking up space and inviting abuse. But anyone who has picked 24 photos and written a message for each has put in half an hour, and that work is the product’s strongest selling point. Behind a paywall it would be wasted. Drafts are therefore created on the server before any payment, and expire after 30 days.