What It Actually Means
Add a customer, look one up, change their details, remove them. Almost every business application is these four operations applied to whatever records the business cares about, wrapped in rules about who may do which.
Developers use the term slightly dismissively, as in it is just a CRUD app, meaning nothing about it is technically interesting.
Why It Is Worth Knowing
Because it gives you a way to think about what you are being quoted for.
If a proposed system is fundamentally the four operations against a dozen record types, with sensible permissions, that is well-understood work. Frameworks provide most of the machinery, the patterns are established, and the estimate should reflect that rather than treating it as novel.
The genuine complexity in business software is rarely the operations themselves. It is everything around them: who is allowed to do what, what has to happen when something changes, what must not be lost, and how it connects to other systems.
So a useful question when reviewing an estimate is which parts are ordinary and which are genuinely difficult. A supplier who can separate the two is being straight with you. One who prices everything as though it were hard has not looked closely, or is relying on you not being able to tell.
Where The Real Difficulty Lives
The D is not what it seems. Deleting is rarely simple deletion. An invoice cannot vanish. A customer with history cannot be removed without breaking the records that reference them. Most systems mark things as removed rather than deleting them, which is the right answer and is more work than it sounds, because everything that lists records now has to know to exclude them.
Update is where history matters. Changing a price or a permission overwrites the previous value unless something records it. When somebody later asks what it was in March, the answer exists only if that was designed in. This is the most common regret in schema design.
Read is where permissions get missed. Ensuring a person sees only what they should is a check that has to exist at every point where anything is listed or fetched, and a missed one is invisible until somebody finds it.
What To Ask
- Which parts of this are standard, and which are genuinely complex? A fair question and the answer is informative.
- What happens when something is deleted? Marked, or actually removed, and what happens to records that referenced it.
- What is kept as history when things change? Ask specifically about anything commercial.
- Does every read check permissions? Including exports and reports, which are the usual gap.
The Practical Use
Knowing this vocabulary lets you push back sensibly on scope and pricing without needing to understand the implementation.
If most of a system is ordinary record management, that should be reflected in the timeline, and the effort should be concentrated where the actual difficulty is: the rules, the connections, and the things that must never be lost.
More terms are in the glossary.
