What to Define Before Building a Custom Business Application

Software projects rarely fail because a feature was hard to build. They fail because a decision was deferred — usually a decision about data or responsibility — and by the time it surfaced, a great deal of work had already been built on top of the ambiguity.

The items below are the ones that are cheap to settle at the start and expensive to revisit later. None of them requires technical knowledge to answer; they require access to the people who do the work.

1. Who uses it, and what are they responsible for

Not job titles — responsibilities. Who is accountable when a record is wrong? Who is permitted to override a rule? Who needs to see information but never changes it?

This determines the role model, and role models are difficult to change after the fact because permissions get referenced throughout an application. Defining three real roles at the start is far better than adding a fourth once the system is live.

2. What the records are, and how each one is identified

Every operational system is built on a small number of core records: a product, an order, a job, a client, a shipment. Naming them precisely matters more than it sounds, because different departments frequently use the same word for different things.

Identity matters just as much. What makes two records the same record? If the answer is "the name, usually," the system will eventually create duplicates that nobody can safely merge.

3. Which system owns each piece of information

This is the decision most often skipped, and the one that causes the most expensive corrections. For every field that exists in more than one system, someone has to decide which system is authoritative and what happens when the two disagree.

• Which system may change this field, and which only display a copy?
• How often is the copy refreshed, and what does the interface show while it is stale?
• If both changed since the last sync, which wins — and does a person need to be told?
• When a record is deleted in one system, what happens in the other?

Without these answers, synchronization becomes guesswork, and every future integration inherits the ambiguity.

4. The rules the software must enforce

Write down the rules that currently live in people’s heads: approval thresholds, pricing exceptions, eligibility conditions, sequences that must not be skipped. Then test each one against real historical records, because stated rules and applied rules differ more often than anyone expects.

Pay particular attention to the exceptions. Exceptions are where operational software either earns its place or becomes the thing people work around. A rule that cannot be overridden by anyone will be bypassed outside the system entirely.

5. What it must connect to, and what happens when that fails

List every system the new software must exchange data with, and for each one establish the direction of flow, the trigger, and the failure behavior. The failure behavior is the part usually left undefined, and it is the part that determines whether people trust the system.

• What should happen if the other service is unavailable for an hour? For a day?
• Who is told when a sync fails, and how would they know it had failed at all?
• If the same event is delivered twice, what prevents a duplicate?
• Who owns the credentials for this connection, and what happens when they expire?

6. Access boundaries and sensitive data

Decide which categories of information are restricted, and to whom, before the schema is designed. Retrofitting access control is one of the more invasive changes possible in an application, because it touches every query rather than every screen.

Equally, decide what should not be stored at all. Data that is never collected cannot be exposed, and it carries no retention obligation. In regulated contexts, that scoping decision belongs at the start and in writing.

7. What must be reportable

Reporting requirements change the data model. If the business needs to know how long something took, the system must record when it started — and that is a schema decision, not a reporting feature.

A useful exercise: list the questions the business will need to answer from this system in a year, then check that each one is answerable from the records being designed.

8. What existing data comes across

Almost every custom system replaces something, even if that something is a spreadsheet. Establish early what will be migrated, what quality it is in, and what will be archived rather than imported.

Legacy data is usually less consistent than expected: duplicates, missing values, and records that the previous system tolerated. Discovering that during migration week is disruptive; discovering it during scoping is just information.

9. What success looks like, stated in operational terms

Not "a better system" — something observable. The order entry step no longer requires re-keying. Stock counts match between two systems without a weekly reconciliation. A status question is answered from a screen instead of an email.

Stated this way, success criteria also become the scope boundary. A feature that does not serve one of them is a candidate for a later phase.

10. Who owns it after launch

Custom software needs an owner in the business: someone who decides priorities, approves changes, and is the point of contact when something is wrong. It also needs a technical continuity plan — documentation, environment configuration, migration history, and code ownership — so the system does not depend on a single relationship.

None of this requires choosing a technology. That decision follows from these answers, which is the right order — technology selected to fit the operation, rather than an operation reshaped to fit a technology someone had already chosen.