One product, shipped all the way.

The shop

sailtacperformance.com

Everything between “I want this” and “it’s running on my computer”: the sales pages, the checkout, the licence that arrives by email, and the download itself. Around 7,000 lines of code across ten pages and twelve behind-the-scenes endpoints.

One place to look, instead of two that disagree

The usual approach is a separate customer database sitting alongside the payment provider — two records of the same person that slowly drift apart until someone is billed for something they cancelled. Here the payment provider is the only record: what a customer bought and when it expires live on their billing profile. Nothing to reconcile, because there is nothing to reconcile against.

The purchase completes even if something goes wrong halfway

After payment, two separate things race to deliver the licence — the notification from the payment provider, and the page the customer lands on. Either can be delayed or fail. Both are allowed to run, because the licence each would produce is character-for-character identical, so there is no harm in it happening twice. A separate check makes sure only one email goes out.

One command that answers “is the shop actually open?”

A storefront can look perfect and still be quietly broken — a card processor in the wrong mode, a price that no longer exists, an email service that stopped sending. Before every release one command interrogates the live site about all of it, and confirms the download people receive matches its published fingerprint. It buys nothing, sends nothing and changes nothing.

A test that buys the product and checks it works

When you sell software, the worst possible failure is that the payment succeeds and the thing they paid for doesn’t open. So an automated test does the whole journey: it starts the real application, confirms it is locked, requests a licence the same way a customer would, and confirms the application unlocks. Then it damages the licence and confirms it is refused.

Visit sailtacperformance.com →

The back office

Licence Manager

The tool behind the counter: issue a licence, renew one, see who is about to expire, and know which version every customer is running. Around 2,300 lines. It runs only on my own machine and is deliberately never given to anyone else.

Because “I’ll remember” stops working at customer three

Licences were originally created by typing a command into a terminal. That works, and it remembers nothing — no record of who bought what, what they paid, or when they run out. This replaced it with a proper back office: every customer on one screen, sorted by who needs attention first, with the full history of every licence they have ever been issued.

It can check on customers without exposing their licences

To show which version each customer is running, the tool has to ask the website. It never sends the actual licences to do that. It sends a one-way fingerprint of each one, and the website confirms only the ones it already knew about — so a licence key, the thing that unlocks the paid product, never travels over the internet at all.

Support sees exactly what the customer sees

When someone gets in touch because their software is warning them about their licence, the answer on my screen has to match the one on theirs. So the expiry rules here are not a second version written from the same description — they are the application’s own rules, reused directly. Support can never say “you’re fine” while the customer’s screen says otherwise.

Built to survive an ordinary bad day

Lose power mid-save and the customer file is not left half-written; it is swapped in complete, with a backup kept behind it. If the file is ever damaged, the tool refuses to open rather than starting up looking convincingly empty — the failure that would quietly lose a customer list. And exported spreadsheets are sanitised, because a customer’s name should not be able to run as a formula in Excel.