Products With an Expiry Date Baked In

Most software we build doesn't have an end date.

Barba Studio exists as long as it has paying users. Gestionale Molinari exists as long as I have a business. Clover, Honeyside's product, has existed for years and will continue as long as someone buys it. The time horizon for these products is indefinite — and that indefiniteness is normal, it's implicit in the model.

ReD Sposi is different. It ends in August 2026. Not because I'll stop maintaining it, not because I'll change my mind, not because I'll find something better. It ends because the wedding is in August, and after that there's nothing left to do.

This biological expiry date changed every decision I made building it.

The Clarity That Comes From Knowing When It Ends

The most common problem in software development is over-engineering: building for use cases that will never arrive, scaling for loads that will never materialize, adding configurability for future needs that will remain future.

With ReD Sposi, this problem doesn't exist.

I know how many users there will be: a few hundred. I know what the traffic peak will be: the day of the wedding, probably a few dozen simultaneous requests at most. I know which features must exist: the ones guests need to participate in the event. I know which features are optional: the ones that would be nice but don't change anything for anyone on August 2nd.

Having these clear boundaries — not as an external constraint but as an intrinsic property of the product — makes decisions much simpler. I don't need to ask "what if we had thousands of users?". The answer is: we won't. I don't need to ask "should we add this feature for version 2.0?". There is no version 2.0.

How It Changed Technical Decisions

Database: MongoDB on a single VPS, no replica set, no sharding. For a product that ends in August, 99.99% availability isn't a requirement. If the server goes down for an hour during wedding preparations, it's not a crisis — it's an inconvenience. I chose operational simplicity over theoretical resilience.

Auth: Invite codes with long-expiry JWTs, as I wrote recently. No recovery system, no token rotation, no server-side session management. A guest who loses their code sends me a message. Done.

Feature freeze: From April onwards, no new features. Only maintenance, real bug fixes, and responding to guests. This decision isn't hard when you know the product ends in four months.

Monitoring: PM2 logs and a Telegram webhook when the server crashes. No dashboarding, no sophisticated alerting. If something serious breaks, I'll know within an hour.

All these choices would be wrong for Barba Studio, which is a live product with paying users and a roadmap. They're right for ReD Sposi because ReD Sposi's requirements are fundamentally different.

The Opposite Risk

There's a risk in the other direction too: under-engineering a product that has a predetermined end date but where failure has a very high cost.

ReD Sposi cannot be flaky on the wedding day. I can't afford the chat to be down while guests are trying to message each other, or the gallery to not load while someone wants to share a photo. Not because there are professional consequences — but because it's my wedding, and it's an event that happens once.

So the expiry date didn't give me permission to build badly. It gave me permission to build exactly what was needed — no more, no less — with that date in mind as an absolute quality constraint for the important time window.

The product is stable because I made it stable where it mattered. It's not scalable because it doesn't need to be.

The Transferable Lesson

Not every product has a biological expiry date like a wedding. But many products have shorter time horizons than we assume — campaigns, events, prototypes, internal tools for a finished project.

The useful question isn't "how do we build this to last?", but "how long does it need to last, and what happens at the end?". The answer to that question changes almost everything: infrastructure choices, level of polish, architectural complexity, the amount of features to ship.

A product that lasts a year and works well for that year is a successful product. It's not a failed product because it doesn't last ten years.

August can't come soon enough.