Existing tools leave a critical process dependent on spreadsheets.
02TECHNOLOGY & DIGITAL SYSTEMS / CUSTOM SOFTWARE
Software should fit the operation, not force a workaround.
Design and implement internal tools, integrations and customer-facing applications around a defined business requirement.
BEYOND THE SERVICE LIST
A feature is not a requirement until its user, purpose and acceptance condition are understood.
THE DECISION BEHIND THE WORK
Start by discovering which problem is worth owning in code.
A purpose-built system can be an advantage when the business has a distinctive workflow, integration requirement or customer experience that available products do not support adequately. It also creates a long-term responsibility for security, accessibility, support, updates and technical decisions.
The best specification distinguishes what users need to accomplish from what stakeholders initially request. We examine alternatives before recommending bespoke development, including configuration of existing products, integrations and process changes. If custom work is warranted, a narrow first release with clear acceptance criteria is often more informative than an ambitious list of features.
THE OPERATING REALITY
Custom software is justified by the problem it solves.
New software can simplify a critical workflow or become another application to maintain. The key decision is what truly needs to be built, connected or replaced.
Teams repeat work because systems are not integrated.
Feature requests accumulate without a clear owner or implementation priority.
WHERE WE FOCUS
Product thinking with an operational mandate.
Move from a testable requirement to a maintainable, secure and useful implementation.
Discovery and fit
Understand users, requirements, current systems and whether configuration, an integration or a new application is justified.
Architecture and prototypes
Define user journeys, interfaces, APIs, data models, security boundaries and a testable first release.
Engineering and integration
Coordinate web applications, internal tools or system connectors with quality, accessibility and security testing proportionate to use.
Launch and ownership
Plan deployment, documentation, administrator access, adoption, support and the continuing cost of maintenance.
The build-or-buy comparison
Justify the product before the project.
Compare a new build with adaptation, integration or an existing tool against the actual cost of operating it.
DECISIONEVIDENCE TO MAKE VISIBLE
Requirement
Which workflow must change?
Named users, job and measurable acceptance testsAlternatives
Can an existing product solve enough of it?
Fit, constraints, integration and license tradeoffsOwnership
Who maintains the result after launch?
Security, support, hosting and change responsibilitiesWhat the first working output might be
Possible first output: an option appraisal and an incremental delivery specification.
Important limitation: A custom application creates continuing operational and security obligations.AN EVIDENCE-LED REVIEW
Protect the business case from unnecessary complexity.
These are useful lines of inquiry, not a universal checklist. The specific evidence and scope depend on the business context.
Fit
What gap remains after existing products and process options are assessed?
Document users, constraints, integrations and alternatives.
Maintainability
Who will own the software after launch?
Review architecture, code quality, documentation, access and support assumptions.
Delivery quality
What evidence will show that the release works?
Define security testing, user acceptance and operational checks.
ILLUSTRATIVE OPERATING SITUATION
An internal platform that began as a spreadsheet.
This is a hypothetical example for explanation. It is not presented as a client engagement or result.Consider an operations team using several spreadsheets to schedule jobs, record status and invoice customers. Leadership requests an all-in-one application, but each department describes the process differently. Building from that request alone would encode the disagreement into software.
A more defensible sequence would map the shared workflow, identify the system of record, prototype the most painful handoff and test it with real users. The first release might be an integration or small internal tool rather than a complete platform replacement.
BOUNDARIES AND RESPONSIBILITY
Maintenance begins at delivery.
Architecture, implementation and security controls must reflect the actual environment. A working prototype should not be represented as production-ready without the appropriate testing, documentation and governance.
Independent reference: NIST Secure Software Development Framework ↗. This source informs the topic; it does not endorse Avermont Partners.
QUESTIONS WORTH CLARIFYING
What must be true before building?
An informed first conversation is often more useful than a prematurely detailed proposal.
When is custom software preferable to an existing platform?
When requirements, integration needs, user experience or ownership economics justify the additional lifecycle responsibility. The comparison should include maintenance and change cost, not just initial build price.
Should development start with a full specification?
The outcome and constraints should be clear, but details often benefit from prototypes and user feedback. A controlled discovery phase can reduce expensive assumptions.
What makes a handover effective?
Documentation, access ownership, deployment procedures, tests, support responsibilities and an understandable roadmap help the client operate what has been delivered.
THE QUESTION WORTH ASKING
What becomes possible when this workflow no longer needs a workaround?
Useful progress begins with a clear requirement, the right evidence and ownership of the next decision.
View all Technology capabilitiesTHE NEXT CONVERSATION
A better application starts with a better brief.
Share the situation, constraints and intended outcome. We can then assess whether a focused engagement would be useful.
Discuss an Engagement