When a software proposal starts with “we need an app,” the riskiest part is often not the code. It is the missing decision about what should be built first.
A short technical-commercial diagnosis can reduce that uncertainty before implementation begins.
A five-step diagnosis
1. Define the decision
Write the decision the project must enable. Examples:
- Should we build a mobile app or start with a web workflow?
- Is an integration technically feasible with the available API?
- Which part of the process should be automated first?
If the decision is vague, the implementation will be vague too.
2. Separate requirements from preferences
Requirements are constraints that must be satisfied: users, inputs, outputs, compliance, latency, integrations and delivery format. Preferences are choices that can change: framework, visual style, hosting provider or optional features.
This distinction keeps a small first version from becoming an unbounded project.
3. Map dependencies and risks
List the external systems, data, credentials, policies and human decisions that the project needs. Mark each dependency as available, uncertain or missing. A risk is useful only when it includes a mitigation or a decision point.
4. Recommend the smallest credible next step
The output should be actionable: a prototype, an API spike, a requirements clarification, a short audit or a bounded implementation. Avoid promising a complete system before the unknowns are understood.
5. Define acceptance criteria
A diagnosis is complete when the buyer can check it. For example: requirements are listed, dependencies are identified, risks have mitigations, an architecture direction is recommended and the next implementation step is explicit.
A reusable workflow
I maintain a small downloadable HTML workflow called Pulse for diagnosing commercial proposals. It is intended for agencies, local businesses and sales teams. It provides a standalone file, quick-start material and a structured way to turn an unclear request into a focused next step.
You can review it here: https://moralesalerson.gumroad.com/l/pulse
The workflow is a starting point, not a guarantee of a business or technical outcome. Review its output against your own requirements before making decisions.
Top comments (0)