When an organisation needs a paid Diagnose before building a system

Many system projects fail not because the developers are weak, but because the problem was not understood when the contract was signed. The quote was put together after one or two meetings, and the wrong assumptions only surface halfway through the build.

A paid Diagnose exists to close that gap. The goal is simple: clarify the problem, the risk, and the options before a large budget is committed.

Five signs you need a Diagnose

1. The need is written as a feature list, not a problem. "We need an approval module" does not explain why approvals are slow today, who is involved, and which data gets lost along the way.

2. More than two systems have to talk to each other. Integration is where assumptions go wrong most often: data formats, API access, master data quality, and who owns each interface.

3. Vendor estimates differ widely. A large gap usually means each vendor is picturing a different scope.

4. Leadership does not agree on the risk. If the operations director and the finance director see different stakes, the budget decision keeps getting postponed.

5. An existing system will be replaced or taken over. The state of the code, documentation, and data decides whether fixing is enough or replacement is needed.

What a Diagnose should produce

A discovery engagement worth paying for produces documents you can use, with or without the same vendor. At MarkasDev, Diagnose outputs include:

• findings and prioritised risks,
• a process map or an inventory of systems and interfaces,
• solution options (buy, build, or integrate) with their consequences,
• a 90-day backlog and a proposed Deliver scope, and
• an Operate framework for after go-live.

When you can skip it

If the specification is final, documented, and approved by the decision maker, Diagnose can be skipped or reduced to a scope validation. For pure server upkeep, an initial check is usually enough before moving to Operate.

Next step

Prepare the list of systems involved, the symptoms that hurt most, and who makes the decision. With those three, a first conversation can settle which Diagnose package fits, or conclude that you do not need one yet.