Come avvicinarsi al vecchio "questa sarà solo una piccola applicazione"? Si, come no?

Question

Ok, ci sono imbattuto molte volte, ma ecco lo scenario del caso peggiore leggermente esagerato.

Dice un cliente "Ehi, puoi farci questo piccolo modulo per svolgere questo piccolo compito"?
Me: "Certo nessun problema".

Quindi, in base a budget e vincoli ecc., Salto un po 'di architettura e mi immergo proprio e non sudolgo.

Quindi chiedono un altro modulo. E un altro. E alcuni miglioramenti. E tutto ciò accade molto lentamente, per anni, nel corso degli anni. E prima che tu lo sappia, hai questa applicazione mostruosa che è orribilmente archiviata.

Cosa fai quando ti viene chiesto di fare qualcosa di piccolo? Non sai se continuerà a crescere ... se il cliente continuerà a chiedere aggiunte (e nemmeno loro).

Non puoi over-architerare la cosa, perché dopo tutto è solo una piccola applicazione, e andranno da qualche altra parte se dici (in quanto conosco tutta la voce) "Beh, per ogni evenienza, architetto questa cosa in strati con TOP -o-la sicurezza e la separazione delle preoccupazioni. In effetti andiamo con uno strumento di iniezione di dipendenza che renderà davvero questa cosa fantastica bla bla bla ".

Diranno "sì giusto" e andranno da qualcun altro.

Budget, tempo e percezione sono importanti quanto l'architettura dell'applicazione stessa.

Come dovrebbe essere affrontato?

Immagino che la domanda si riduca davvero a "Quando non hai tutte le informazioni per il risultato finale di quella che sembra essere una piccola applicazione, come evitare (o mitigare) prendere le decisioni architecurali e di progettazione presto. Innapropap più tardi?