“Can we add another approval step?”
Imagine a leave-request system that is already in use. Staff can submit requests, managers can approve them, and the reports work. Then the organization changes its structure. That short request suddenly means editing the form, the database, and the notification emails.
Changing a business rule always has a cost. The question is why one rule has spread across so many parts of the system, and how the team can check that its next change will preserve the workflow people already rely on.
That conversation belongs before the first line of code.
Agree on the rules people actually use
Before choosing a language or database, write down the workflow: submit, check, approve, record. Ask the people doing the work to walk through it, including a day when things go wrong.
Who approves a request when the manager is away? What happens if an employee moves departments while a request is pending? Does clicking Submit twice on a slow connection create two requests?
These answers determine how the system should behave. More screen designs will not settle an unresolved rule.
A useful starting document can be short. It should contain examples everyone agrees on: “The applicant can withdraw a request before approval. After approval, cancellation follows a separate process.” That sentence gives users something to review, designers something to show, and developers something to test.
Where Clean Architecture helps
The central idea of Clean Architecture is to keep business rules independent of interface, database, and external-tool details. Source-code dependencies point toward those rules.
In our leave-request example, the approval logic owns the decision about who can approve. The screen collects input and presents the result. Storing data and sending emails have their own responsibilities.
Adding an approver then has a clear starting point. The team can trace which changes also affect data, screens, or notifications. Separation will not reduce every change to one file; it makes the consequences easier to follow.
For a small system, that may mean well-defined responsibilities within one application. Separate services can wait until there is a reason for them. Microsoft’s architecture guide discusses layers within a single application and the additional complexity that comes with microservices.
Ask the development team: “If this rule changes, what needs to change with it?” An answer that points to code and tests is more useful than a tidy set of folder names.
Test the rule, then the working system
When changing approval logic, start with the behavior being changed. Clicking through every screen should not be the only check.
For this example, an authorized approver should be able to act, an unauthorized person should be rejected, and a cancelled request should not be approved. Then check persistence and the complete user journey.
Testing rules independently of a database gives quick feedback. You still need tests that exercise the real connections and data storage. Ham Vocke’s The Practical Test Pyramid explains how different test levels serve those needs.
Permissions also need server-side checks. Hiding an approval button improves the interface, but a user may still send a request directly to the system.
A useful test answers “Can people still complete this important task?” A count of passing tests cannot answer that on its own.
A handover needs more than source files
Imagine a new maintainer joining on Monday. They should be able to find how to start the application, where it is configured, and how to roll back a release that causes a problem.
The handover should include setup steps, configuration examples without secrets, deployment instructions, and known limitations. It should also identify who owns service accounts and access permissions.
Discuss recovery alongside backups. Restore data in a separate environment, check that it is complete, and verify that the application can run with it. Having a backup file alone does not establish that the recovery works.
Leave a record of important decisions, too. Why is this one application? Why is offline support outside the current scope? Why is approval history retained? The next team needs to know which choices reflect real constraints and which can change.
Five questions before the project starts
Before agreeing on scope, work through these questions:
- What must users finish in the first release? Choose complete tasks rather than counting screens.
- Which rules still need a decision? Name the decision-maker and arrange the conversation.
- How will the team check the impact of a rule change? Ask for an example from the work being proposed.
- What will be checked before launch? Agree on workflows, permissions, speed, and accessibility appropriate to the people using the system.
- Who owns what after handover? Include code, service accounts, backups, and recurring costs.
Maintainable software starts with these small decisions. Clear rules, code that can be followed, and a recovery process someone has tried give the next change a firmer starting point.
If you are planning a system, pick one task that costs your team the most time. Write down a normal day and a day with exceptions. You will already have something concrete to discuss with a development team.