Six stages, four decision points, no surprises at the end
Development projects and consultancy engagements share one process. What differs is the fourth stage — build or advise — and how far the later stages extend. Not every engagement uses every stage.
Process navigator
Select a stage
Each stage lists what is needed from the client, what DEVNOVA does, what comes out of it, and the decision that closes it. Use the arrow keys to move between stages.
Stage 01
Discover
Understanding the situation before proposing anything. This stage exists to prevent the most expensive mistake in software: building the wrong thing competently.
Client inputs
- A description of the process, product or decision
- Access to the people who do the work daily
- Examples of real records, documents or cases
- Systems and tools currently in use
- Constraints: budget range, timing, internal capability
DEVNOVA activities
- Structured conversations, following real cases end to end
- Observation of the actual process, including workarounds
- Review of existing systems and documentation
- Identification of the problem worth solving
- An early view on whether software is the right answer
Expected outputs
- A written summary of the current situation
- The specific problems identified, in priority order
- Initial view on approach and rough scale
- Any constraints or dependencies already visible
Decision point — is there a project here?
The honest answer is sometimes no: the requirement may be met by configuring an existing tool, changing a process, or waiting for a business decision elsewhere. Where that is the case, it is said at this point rather than later.
For development projects
Discovery concentrates on process detail: who does what, in which order, what must be recorded and which cases break the normal pattern.
For consultancy engagements
Discovery concentrates on the decision: what must be decided, who disagrees, what has already been tried and what would change if it were settled.
Stage 02
Define
Turning observations into a written scope with explicit boundaries. Everything agreed is written down; everything not written down is a change request.
Client inputs
- A nominated decision-maker who can confirm scope
- Priorities where not everything can be included
- Confirmation of user roles and permissions
- Any regulatory or internal standards that apply
- Review and challenge of the draft scope
DEVNOVA activities
- Writing requirements specifically enough to be verified
- Defining acceptance criteria for each item
- Listing explicit exclusions alongside inclusions
- Preparing the written proposal, price and timescale
- Recording assumptions and dependencies
Expected outputs
- A written proposal or statement of work
- Scope, deliverables and exclusions
- Acceptance criteria per deliverable
- Price and indicative timescale
- Assumptions and client dependencies
Decision point — acceptance of the proposal
Work begins once the proposal is accepted in writing. Payment timing and project-specific conditions are defined in the accepted quotation, statement of work or written agreement rather than by one universal schedule.
For development projects
Definition covers screens, roles, records, rules and integrations, with acceptance criteria written so that "finished" is a factual question.
For consultancy engagements
Definition covers the questions the engagement must answer, the deliverable components, the access required and who the report is written for.
Stage 03
Architect
Deciding structure before writing code or drawing conclusions. This is the cheapest moment for the client to disagree, so disagreement is actively invited.
Client inputs
- Details of existing systems, versions and hosting
- Realistic volume expectations, stated as figures
- Security, retention or residency requirements
- Who will maintain the result afterwards
- Access or credentials needed for assessment
DEVNOVA activities
- Data model and permission design
- Component and boundary definition
- Integration feasibility assessment against provider terms
- Hosting and operational considerations
- Technology selection with reasoning recorded
Expected outputs
- Data model and permission matrix
- Component map and data-flow outline
- Integration viability statement per connection
- Recommended approach with trade-offs stated
Decision point — confirmation of structure
Where an intended integration proves unviable, or a volume expectation changes the approach, that is raised here. Adjusting scope at this stage costs a conversation; adjusting it later costs rework.
For development projects
Architecture is sized to the build: enough structure to proceed confidently, without over-designing for scale that may never arrive.
For consultancy engagements
Where architecture is itself the deliverable, this stage becomes the substance of the engagement rather than a preparatory step.
Stage 04
Build or Advise
The stage where the two activities genuinely diverge. Development produces working software in reviewable increments; consultancy produces the written analysis a decision requires.
Client inputs
- Timely feedback at each review point
- Content, data and access as agreed in the proposal
- Availability of the nominated decision-maker
- Prompt written response to any change request
- Factual review of draft material
DEVNOVA activities
- Development in parts that can be opened and used
- Continuous functional testing during the build
- Or: analysis, option development and comparison
- Regular progress updates in terms of completed outcomes
- Written change requests where scope shifts
Expected outputs
- Working increments, reviewable as they are completed
- Or: draft findings, options and recommendations
- Progress reported against the agreed criteria
- A record of any accepted change requests
Decision point — increment or draft review
Each increment or draft is a checkpoint. Feedback here shapes the next piece of work, which is why review windows are agreed in advance and why delays here move the whole timescale.
For development projects
Typically core records first, then workflow, then reporting. Each increment is usable, so progress is visible rather than described.
For consultancy engagements
Analysis against agreed criteria, with a draft shared for factual correction. Conclusions are not negotiated; facts are.
Stage 05
Validate
Checking the result against the criteria agreed in stage two — not against what anyone hoped for in the meantime.
Client inputs
- Testing with realistic scenarios and real data
- Involvement of the people who will use it daily
- Consolidated feedback within the review window
- A clear distinction between defects and new requests
- Written confirmation of acceptance
DEVNOVA activities
- Functional testing against each acceptance criterion
- Cross-browser and cross-device checks
- Validation of permissions, input handling and error states
- Accessibility fundamentals: keyboard, labelling, contrast
- Correction of anything not matching the specification
Expected outputs
- Test results against the agreed criteria
- A defect list with resolution status
- Any new requests logged as potential future work
- A written acceptance record
Decision point — acceptance
Acceptance is measured against the written criteria. New ideas arising during review are welcome and are recorded as candidates for a later phase rather than absorbed silently into the current one.
For development projects
A defined review period in which the client tests with real scenarios, followed by correction of anything that does not match the specification.
For consultancy engagements
Validation is a factual review of the draft: correcting misunderstandings about how the organisation works, before the report is finalised.
Stage 06
Improve
Handover, documentation and an agreed route for what happens next. Delivery is a stage, not an ending.
Client inputs
- Attendance at the handover walkthrough
- A named internal owner for the delivered work
- A decision on any support or maintenance arrangement
- Feedback once the result has been in real use
- Priorities for any subsequent phase
DEVNOVA activities
- Deployment to the agreed environment
- Handover documentation written for the client's team
- A walkthrough covering structure and routine tasks
- Correction of specification defects during the settling period
- Recommendations for a sensible next phase
Expected outputs
- Deployed, documented deliverable
- Source code for custom work, where applicable
- Administrative and operational documentation
- An agreed arrangement for future changes
Decision point — what happens next
Three routes are normal: nothing further for now, occasional change requests as they arise, or a planned second phase informed by what real use has revealed. None is treated as the default.
For development projects
A settling period during which defects against the specification are corrected, followed by whichever support arrangement has been agreed.
For consultancy engagements
The report is delivered and belongs to the client. Follow-up may be a build, a further engagement, or nothing at all — with no expectation attached.
Using selected stages
Not every engagement uses all six
The process is a structure, not a procedure to be performed regardless of value. Short engagements use the stages that carry weight and skip the rest, and the proposal states which apply.
A short review
An application review typically uses Discover, Define and Build or Advise, with a light Validate stage for factual correction. Architecture is not required because nothing is being built.
A build from an existing specification
Where a client arrives with a settled specification, Discover is compressed into a review of that document, and the engagement effectively begins at Define.
Consultancy leading into a build
The consultancy engagement completes all six stages. The subsequent build then starts at Define, using the completed analysis rather than repeating discovery as billable work.
On timescales. Indicative durations shown for each service assume timely feedback, prompt access and a nominated decision-maker. Delays in client dependencies move the timescale, which is why those dependencies are listed explicitly in every proposal rather than assumed.
Same six stages
The process as one connected system
Each stage produces something the next stage consumes. Skipping a stage is a decision with consequences, which is why the skip is recorded rather than silent.
Discover
Understand the process, the people and the problem worth solving.
Define
Written requirements, priorities, exclusions and acceptance criteria.
Architect
Structure, data, integrations and the technical approach.
Build or Advise
Reviewable increments, or the written analysis a decision needs.
Validate
Testing against agreed criteria and a genuine review period.
Improve
Handover, documentation and an agreed route for changes.
Begin at stage one
Every project starts with a conversation
No charge and no obligation for the initial discussion. If the honest answer is that the requirement does not need custom software, that is what you will hear.
- Telephone
- +44 7853 151 992
- support@devnovasolutions.tech
- Registered office
- 66 Paul Street, London, England, EC2A 4NA, United Kingdom