1. Project start: requirement gathering
2. Create workflows and prototypes
3. Customer confirms the workflow and prototypes
4. Develop the system
5. Initial feedback : customer is happy
6. Testing and deployment
7. Customer changes the requirement to something completely different and says you just need to click a button to implement the changes

Wtf!!!!!!!

I know, it's nightmare

@nanl I think devs need to show the importance of requirement analysis stage and not accept any changes after .

For me problem is that some devs accept major changes and when other teams don't accept they will complain, terminate contracts or hold payment.

@peacefrog get paid by the hour,. and make sure any changes requested by the client at any point, will increase the required hours of work, is in the contract. Also make sure delivery times will move accourdingly.

@zickig yeah flexible architecture and customization workflows are possible (good points). But not having the full scope of the project identified and devs quoting for the identified scope will tend not to prepare for major changes. (and most projects here dont have a service contract as well)

Also even if we can set custom plugins I believe it should not be within the current project budget and timeline.

@peacefrog have a "paper" trail.

If you're an employee, send them an email with your workflows and prototypes, and ask for confirmation.

If you're a freelancer or contractor, write documentation describing the project in detail and mention it in the contract.

If they want to change stuff afterwards draft a new contract with new prices, or if employee, a new analysis with a new estimate.