You can throw a website away every two years, an application you cannot

There is a piece of advice you read everywhere: build your website so it still works in five years. I understand where it comes from, but it lumps two very different things together. A website and a web application are not the same kind of thing, and the rules that apply to one are often bad advice for the other.

Let me say straight away where I am heading. A website can happily be rebuilt every two years. A web application should be set up so that you do not have to rebuild it after five. That sounds contradictory until you look at what each of them actually does.

A website is a shop window

A website is mostly presentation. Text, images, a few forms, a structure that walks people through your story. The architecture behind it is simple, and if it was built well, replacing it is not much work either. The content is the valuable part, and the content moves along with you.

That is why putting up something new every few years is no disaster. Your business changes, your offer sharpens, what you wrote on your homepage two years ago is no longer quite right. A fresh shop window is simply useful at that point. It only becomes a problem when that rebuild costs thousands of euro and takes months every single time, and that is usually a sign the site was technically too heavy for what it had to do.

What I do watch closely with a website is ownership. Domain, hosting, code and content should be yours, and you should be able to get at them yourself. That has nothing to do with lifespan and everything to do with being free to leave.

A web application is something else

Software that people work in grows. Features get added, users get added, integrations appear that you never thought of at the start. Everything you get wrong at the beginning you carry with you for years, and it gets more expensive to change with every one of them.

That is exactly where a lot of projects go off the rails. An application gets built as though it were a website, quickly and without much structure, and after three or four years every change has become a risk. That is the moment someone says it is time to rebuild the whole thing. It could have been avoided, not by being cleverer, but by getting a few boring decisions right at the start.

What that looks like for us

I build and run Altrady, a crypto trading platform, and Coinray, the market data API underneath it. Altrady uses Coinray’s APIs, and that is not a coincidence but the most important architectural choice we ever made.

By separating the market data layer in Coinray from the business logic in Altrady, where the bots and the trade automation live, Altrady deals with one API contract. One. Inside that we work with the simple order types exchanges happen to offer, and we build the more complex automation on top of them ourselves.

That sounds abstract, so here is what it buys us in practice. Coinray offers a single unified API towards all the exchanges, and because we only need a limited set of things on the exchange side, the large majority of exchanges simply fit within that contract. Adding a new exchange is therefore far less work than you would expect, and it stays scalable as more of them arrive. If an exchange disappears, nothing has to change in Altrady and the application does not fall over because of it.

Compare that with the version where every exchange is wired straight into the application. Then every addition is custom work, every change on an exchange’s side is an outage, and every removal is a renovation. That is the kind of application people declare unmaintainable after five years.

What you separate at the beginning, you do not have to pull apart later while it is running.

What I would do differently myself

Architecture is not the only thing you carry with you for years. There is one decision from Altrady’s early days that has cost me more effort than any technical choice.

Altrady grew out of a problem that existing users had. I knew those people, I knew the problem, and I gave them the solution. That worked, because they did not need convincing about something they felt every day.

Years later a very different group starts arriving. New users who do not know that problem yet, or do not know they have it. They open the application and see a solution without the question it belongs to. We have since had to put a lot of time into onboarding to put that right, and I should have taken it into account from the start.

The lesson I take from it, and I think it goes wider than software: solve the problem for the group you have now, but do not shape your product so that the much larger group you have not met yet feels shut out. That second group is the one that decides your growth.

What this means for you

If you are having a website made, the way to avoid expensive mistakes is mostly to keep it small and simple. Rebuilding is not a failure, it is maintenance on your shop window.

If you are having an application built that your business will run on, the separations you put in at the beginning decide what is possible five years from now. That is a conversation better had up front than afterwards, because afterwards it is called a migration.

If you are unsure which category your plan falls into, that is less obvious than people think. Put it in front of me. I will tell you honestly whether it is something you can comfortably replace in two years, or something worth thinking through now.