Custom software or an existing tool? Test the requirement first.

Describe the work before the software

Choose one operating process and follow it from its trigger to a completed outcome. Record who starts it, which information is required, who makes decisions and what must be true before the work can close.

Separate the normal path from the exceptions. If staff handle cancellations, incomplete records, unusual approvals or customer changes differently, those rules are part of the requirement rather than details to add after a tool is chosen.

• What event starts the work?
• Which person or role owns the next action?
• What information is required before a decision?
• Which exceptions need human judgement?
• What record proves that the work is complete?

Improve the process before replacing it

A confusing process can remain confusing inside new software. First check whether a clearer responsibility, a smaller set of statuses, a shared template or a regular review would solve the immediate problem.

Remove steps that exist only because the current process was never updated. Do not automate a duplicate approval or repeated data entry until the team confirms that it is still necessary.

Compare four practical options

Treat the decision as a comparison rather than a choice between doing nothing and commissioning a build. The right option depends on the actual requirement and the capabilities available in the tools and account plans being assessed.

Document why each option does or does not fit. A useful comparison names the unresolved requirement instead of rejecting a tool because it feels generic.

• Improve the current process without changing software.
• Configure an existing tool more clearly.
• Connect two tools after confirming the connection is supported.
• Assess a bounded custom application for requirements the other options cannot meet.

Know when an existing product may fit

An existing product may be the better starting point when the process follows a common pattern, the required roles and reports already exist, and the team can work within its terminology without creating constant workarounds.

Test the actual product and account plan with representative scenarios. Marketing descriptions are not a substitute for confirming permissions, exports, limits, support responsibilities and the behaviour of any proposed connection.

• The normal workflow can be represented without hidden side spreadsheets.
• Required staff roles can access the right information.
• Important records can be corrected and retrieved.
• The team understands who administers the account.
• A workable fallback exists when the service is unavailable.

Know when a custom assessment may be justified

Custom software may be worth assessing when a stable, important workflow has requirements that existing products repeatedly cannot represent. The evidence should be specific: a role-based decision, a unique operational sequence or a necessary view that staff otherwise rebuild by hand.

Complexity alone does not prove that a custom build is appropriate. Confirm that the process is understood, the business can own the resulting system and the smallest useful version can be described and tested.

• Staff repeatedly reconcile conflicting records to complete the same task.
• A required approval or exception cannot be represented without an unreliable workaround.
• Different roles need a shared operational view with clearly separated actions.
• The business needs a defined workflow rather than a collection of unrelated features.
• The requirement remains after the current process has been simplified.

Scope the smallest complete operating loop

A first custom scope should complete one useful loop from trigger to outcome. Include the staff action, the authoritative record, the exception path and the way the work is closed.

An illustrative internal workflow might receive a job-completion record, route it to an authorized reviewer, return incomplete information for correction and mark the approved handoff complete. This is a planning example, not an 1120 client result or a promise of a specific integration.

Define data, roles and approval boundaries

List the information the system needs, where it originates and which record controls the next action. Avoid copying every historical field simply because it exists in another tool.

For each role, define what it may view, create, change, approve and export. Identify actions that must remain human decisions. Access, retention, privacy and regulatory requirements need review appropriate to the business and information involved.

Turn requirements into acceptance tests

Write test scenarios before a build is treated as complete. Use fictional or specifically approved test data and include normal work, missing information, duplicate submissions, corrections, permission boundaries and a failed notification or connection.

Each test should state the starting condition, action, expected result and person responsible when the result is wrong. This makes a requirement observable without promising a performance outcome.

• A normal record reaches the correct owner.
• An incomplete record is held for review rather than silently accepted.
• A duplicate does not create two conflicting actions.
• An unauthorized role cannot complete an approval.
• A failed handoff becomes visible and has a manual recovery path.
• A corrected record updates the authoritative status.

Plan ownership after launch

A custom system creates operating work after the initial release. Name who manages users, reviews failures, approves changes, maintains documentation and decides which requests belong in a future release.

Agree how needed records can be retrieved or exported and what happens if the business changes provider or process. Hosting, support, maintenance and future development responsibilities belong in the project scope; this guide does not quote a price or timeline.

Bring one requirement to 1120

1120's published services include custom business software, customer portals, business websites, lead and CRM automation, and booking and email workflows.

Bring one recurring process, its difficult exception and the names of the tools already involved. That gives the assessment a concrete starting point. Specific integrations, architecture and project deliverables need confirmation before they are committed.

Start with your business process.

Describe how customers reach you and what your team needs to do next.

Explore 1120 capabilities