- Find the expensive handoff
- Define the operating model
- Keep the build maintainable
Find the expensive handoff
Map the information people enter repeatedly and the points where work waits for approval. Describe the consequence of a mistake, such as an incorrect order or a missed service visit. This makes the problem concrete enough to evaluate whether custom software is justified.
Distinguish inconvenience from an essential requirement. A process that is unclear will not necessarily improve when it is automated. Resolve ownership and decision rules before encoding them into an application.
Define the operating model
List user roles, records and integrations. Specify who may view or change sensitive fields, how changes are traced and how data is corrected. Include exceptions such as cancelled requests, duplicate records and unavailable dependencies.
Decide how the business will continue during an outage or a failed release. Backups, restore procedures and staff intervention are part of the system, not optional additions after launch. Set acceptance criteria around realistic tasks and failure states.
Keep the build maintainable
Ask for account ownership, documentation, a repeatable deployment process and an ongoing support arrangement. Custom software creates responsibilities for dependencies and future changes. An initial build estimate should distinguish those costs from feature development.
Dappr can discuss a scoped application project. Bring examples of the current process without private customer data, plus the integrations and permissions involved. The proposal should state assumptions, exclusions and the evidence required to accept the first release.
Turn the operating problem into explicit rules
Custom software should address a workflow that the business understands well enough to define. A fictional fabrication workshop might coordinate job requests through several spreadsheets, with uncertainty about who approved a revision. The initial problem is the missing decision history and ownership, not simply that the team uses spreadsheets.
This is an illustrative case, not a Dappr project result. The workshop would need to explain how a request becomes an approved job, what can change, and who can authorize those changes. If different employees give conflicting answers, resolve the business rule before encoding one interpretation into a permanent system.
Decide what the first version must replace
Identify which existing steps the software will take over and which remain outside its scope. For the workshop, a first version might manage requests and approvals while leaving production scheduling in the current process. That boundary needs a clear handoff so employees do not maintain contradictory records in two places.
A complete narrow workflow is more useful for acceptance than many partial screens. Trace one request through creation, revision, approval, and retrieval. Include a cancelled request and a rejected revision. Those cases reveal whether the software preserves the decisions the business wanted to understand at the start.
Define records and their relationships
List the important entities and the rules connecting them. A customer, request, approved specification, and job are related but not interchangeable records. Decide which information is copied at approval and which remains linked to a changing source. Otherwise a later edit may unintentionally alter the meaning of an earlier decision.
For the fictional workshop, an approved specification should remain understandable when a customer's contact information changes. The implementation needs an explicit treatment of history and correction. A database field existing in a prototype does not establish that its meaning or lifecycle has been agreed with the people who use it.
Scope security through concrete access cases
Identify what each role is allowed to read, create, approve, or correct. Test prohibited actions as well as permitted ones. A person who can enter a request may not be authorized to approve it, and an administrator's access should not be assumed appropriate for every employee.
OWASP's ASVS can provide a basis for web-application security requirements and verification where relevant to the chosen system. Specify the applicable checks and assessment limits. It is a framework, not a certification attached automatically to software because a developer mentions it or uses a particular technology stack.
Plan migration and coexistence carefully
If existing records are imported, define the source, field meanings, duplicate handling, and validation process. Start with a representative sample that includes difficult cases. A count of imported rows does not prove that relationships, dates, or approval states retained the intended meaning.
For the workshop, decide how active requests are handled during transition. Employees need to know which system is authoritative at each stage and how late changes are captured. The scope should include a reconciliation step and a response to failed imports rather than assuming the business can simply stop all work while software is introduced.
Make acceptance and support operational
Have the intended users complete the agreed tasks with representative records. Confirm that important decisions are visible and that exceptions can be resolved without hidden developer intervention. Record known limitations and the process for requesting changes after the initial release.
Dappr can scope custom software around the actual workflow, roles, and supporting services. Bring sanitized examples of the current process and the consequences of mistakes. The proposal should distinguish discovery, implementation, migration, verification, and ongoing operation. It should not promise an automatic productivity saving or a fixed price before the rules and dependencies are understood.
Questions before you begin
Should every spreadsheet process become custom software?
No. First identify the actual problem and whether clearer process rules or an existing tool can address it. Custom software may be useful when the requirements justify its development and maintenance responsibilities. The decision should follow the workflow, not a general dislike of spreadsheets.
What is a useful first release for an internal system?
Choose one complete workflow with defined inputs, decisions, outputs, and exceptions. Make the boundary with existing processes clear. A narrow release should still handle the important access and failure cases needed for its intended users, rather than leaving them to invent workarounds.
How do you check migrated records?
Define field meanings and relationships, then test a representative sample before a broader transfer. Reconcile the imported result against the source and review difficult cases. A matching row count alone cannot show that approvals, dates, duplicates, and linked records retain their intended meaning.
Who maintains custom software after launch?
The agreement should name responsibility for dependencies, support, releases, and business-rule changes. Confirm source and account access and an understandable operating handoff. A completed first build does not remove the need for ongoing ownership of the product.