How to convince the client that it's time to redo the project?

Question

Project management

Frequent situation. We are starting a project for a new client. Initially, it is not clear what our cooperation will result in. Perhaps after the completion of the project we will say goodbye to this client. And perhaps the project will be constantly refined and work on this project will develop into a long-term cooperation, the original functionality will be expanded many times, and the required performance will increase NNN times. At the start, the question arises, what will be the basis of the project. There are two extreme options:
1. Making it as easy as possible. In fact, we make a prototype on our knees, which we then bring to production. It turns out cheap and fast. But if the project is playing for a long time, then its development will turn into a nightmare. And if the project is one-time, then everything is in order. The client is happy (the required functionality is received), the developer is happy (it is not required to work with a crooked architecture).
2. Laying down a cool architecture. We think about the long-term development of the project. Only the first version will be expensive and the terms will be long. The client will most likely refuse, because our competitor LLC "Govno-code" will offer the same thing, but cheaply and quickly according to scheme No. 1.

And so we made a project according to scheme 1 and the project, to our surprise, began to develop. By the way, often the development of the project begins a few years after the delivery of the first version. The client asks to make one more small feature, then another and another. The load on the system increases hundreds and thousands of times. The client falls asleep with requests for new features several times a day.

Yes, making a small new feature is fast and not expensive. But because of the curved architecture, these are crutches. A few years later, the system turns into a prototype buried under a huge layer of crutches. But the client is happy, everything seems to be working. Occasionally, problems are identified, but a great performer quickly fixes them.

At some point, we understand that it's time to rewrite this hell from scratch and make a normal architecture and it will cost x000000 rubles. But the client absolutely does not understand why everything should be redone for such an amount, when it already works, and new features are added quickly and cheaply. The objections “it works”, “you solve all the problems”, “it crashes, there are backups”, “you quickly make new features, it still works out” ... etc.

The point of no return, when you can still do refactoring, has long passed. Each time the client actively refused to pay for refactorings, motivating that only a couple of minor improvements were needed.

Of course, you can engage in sabotage, or estimate the time to complete new features at a tenfold rate of the actual time required. Or even provoke a failure in the system or deliberately ignore them. But it's not fair.

The option to simply announce that from such and such a date we completely stop working with you on the old version of the program is fraught with the loss of a client.

How to be in such a situation when the project turns into a monster because of the initial cheap architecture?

For clarity, I am attaching a page from my working notebook, on which I expressed emotions when I was working on one of these projects:

Answer 1

Let's go in order.
1. About “making it easier” or “laying down the architecture”. You chose the first path quite naturally, because why would a client pay more to solve their problem, if you can pay less? For him, it defies common sense. Let me share my experience, for example, we always work like this, but with a small (actually key) amendment - we plan how the project will develop further and always together with the client. When there is this plan, the work is built iteratively, first the minimum viable version (mvp) is rolled out, which covers the critical contour of the system (that without which this product will definitely not work), then v0, v1 and so on. The idea is that this is normal practice. On the account of "laying down the architecture", but how do you know what it should be? Enough fingers of one hand to count how many customers I saw, who clearly know what they need and at the end of the project nothing has changed. Knowing this, how can one calculate the architecture, or at least even the desired functionality? It is better to go iteratively and gradually complete the system.
2. Now about permanent features, crutches and so on. Here we run into business analytics and requirements gathering. It is impossible to work in the mode Client said to make a feature — Made a feature. Yes, even several times a day. It is important to model business processes and embed them into an existing system, you seem to understand this, but the client does not. For him to understand this, you need to communicate with him in his language and build work from business. Ask questions at the briefing: “What is your goal by implementing this feature? How else can you achieve this goal, maybe there is a solution that does not require the introduction of any features at all, maybe it can be done for free? For example, we have a business analyst who does only this - asks the right questions, explains the consequences of certain decisions, then formulates tasks himself,
3. According to your text, it is clear that the client perceives your company as a performer, try to switch to partner status. I'm not sure if this is possible at the current stage, your work is already built, but you can try to change the approach on the next project. Show that you are not selling lines of code, but business solutions, then the relationship between you and the client will change qualitatively. After all, the client sincerely believes that he is alone with his problems and tasks, that only he understands how it is necessary and does it with your hands. That's why they ask for frequent changes and probably sometimes contradictory - they are looking for a solution, so show that you can be trusted.
4. About, in fact, the question itself, how to be and how to try to explain that a huge technical debt has accumulated and it needs to be refactored. We return to the same question, you need to speak with business in their language. Make a presentation, call the client for evening tea (or something stronger) and show how it is now and how it could be. Show that crutches and bad architecture slow down the development of new features, that they ALREADY overpaid *so much* and will continue to overpay *so much* every month (well, at least calculate approximately). Show that the quality of the product is steadily declining, that in the end everything works slowly and because of this they lose customers in such and such places. Explain that yes, now everything works and rests on your fucking high-quality crutches, but a real crash can happen here *at such and such a moment*. Show,
The client should be developed by a friend and partner, not an asshole :)
I hope I helped and you will extract something from this text for yourself, in general, in order to talk more specifically about it, you need more specifics :)
PS Pictures - TOP yelled for a long time, thanks)
Pavel Palenin
Head of design in Athanor

Answer 2

Emotions run wild in these stories. To make the right decisions, you need to learn to understand the business and its goals, learn to see a few steps ahead and make proposals at the business level, and not according to personal preferences. What kind of architecture does the project have for a business with a high bell tower as long as it fits into its idea of ​​cost reasonableness