EXISTING ACCOUNT RESEARCH FOR SOFTWARE DEVELOPMENT & IT INTEGRATION FIRMS
The system meets the brief. The brief may no longer describe the business.
A custom system is accepted against requirements agreed at a particular time. The client's products, delivery commitments and decision rights can change without producing a new software specification.
I examine the original implementation context alongside evidence of business changes, before the team commits to a new technical discovery.
For established client relationships · One account · One written decision
WHAT COMPLETION ESTABLISHES
Technical acceptance and continued business fit are different tests.
The delivery record tells you
What capabilities were specified, built, integrated and accepted.
Which processes and stakeholders defined the requirement.
Which exceptions, dependencies and changes were documented during delivery.
The current business may require you to find out
Whether the client now makes different commercial commitments.
Whether work moves between teams or systems in a different sequence.
Whether the original data model and decision ownership still fit the operating model.
An old brief is evidence of the original scope. It is not evidence that a redesign is required. The business may need a policy change, new process controls, integration or no intervention.
THE POINT BEFORE NEW DEVELOPMENT
Establish the business question before estimating a solution.
01 / BUSINESS CHANGE
The client takes on a different kind of work.
A new product, subscription model, service commitment or geographic footprint may change the work the system is expected to support. The company announcement alone cannot establish the internal consequences.
02 / ORIGINAL ASSUMPTION
The old specification contains a boundary.
The team can identify which workflow, entity, integration or decision was designed around the prior arrangement. The question is whether that boundary is now consequential.
03 / VALIDATION
The owner of the business decision may have changed.
A delivery sponsor can explain the application but may not control cost allocation, service commitments or operations. A preliminary check identifies the question, not the authorisation for a project.
WHERE THE £50 SCREEN FITS
Use a small outside-in check only when it changes the next decision.
Useful when
You maintain an existing client system but receive few substantive new requests.
You can see a business change, but it is unclear what it means for the delivered scope.
Discovery would draw on expensive technical staff before the business issue is established.
Unnecessary when
The client already has a clear authorised requirement.
The question is primarily code quality, configuration, security or performance.
The answer requires private operating data or system access that a desk review cannot provide.
The £50 Screen provides a bounded written judgement about one existing client, the original implementation and observable changes. It does not design the next system.
Analytics choice. Analytics cookies are off unless you agree. The Google tag can send limited measurement signals without cookies, even if you reject. You can change your choice later. Cookie details.