How a project runs, step by step
The same nine steps apply to a two-week assessment and a six-month build; only the depth changes. Each step produces something written, so progress is visible rather than asserted.
- 01
Discovery
Understand the problem, the people affected, and the systems already in place.
We meet with the people who perform the work and the people accountable for its outcome. We review current tools, spreadsheets, and any existing software, and we look at real examples rather than idealized descriptions.
Discovery also identifies constraints early: budgets, deadlines, internal availability, security and privacy requirements, and any regulatory obligations your organization must meet.
Produces
- Documented current-state process
- Constraints and success criteria
- Initial scope and effort range
- 02
Requirements definition
Write down what the software must do, in language both sides can verify.
Requirements describe behavior, rules, permissions, and data, along with the acceptance criteria used to confirm each one is met. We separate what is required for launch from what can follow.
This document becomes the reference point for estimating, building, testing, and accepting the work.
Produces
- Written requirements with acceptance criteria
- Prioritized scope for the first release
- 03
Solution planning
Choose an architecture, a delivery sequence, and a plan for the risky parts first.
We select technologies and hosting appropriate to the size of the problem, define integration points and data ownership, and agree on environments and release approach.
Where a technical unknown could affect cost or feasibility, we address it early rather than deferring it to the end of the project.
Produces
- Architecture summary and data model
- Delivery plan and milestones
- Environment and access plan
- 04
Design
Design the screens and flows around the tasks people perform most often.
We work through the primary flows, states, and error conditions before development, including empty states and what happens when something goes wrong.
Accessibility is considered here — structure, labels, contrast, and keyboard paths — because it is far cheaper to design in than to retrofit.
Produces
- Screen designs or prototypes for primary flows
- Interaction and error-state definitions
- 05
Development
Build in reviewable increments you can see, not a long silence followed by a reveal.
Work proceeds in increments with regular check-ins and access to a testing environment, so feedback arrives while it is still inexpensive to act on.
Code is version-controlled and reviewed, configuration is kept out of source control, and progress is reported against the agreed milestones.
Produces
- Working increments in a testing environment
- Regular progress updates
- Version-controlled source code
- 06
Testing
Verify the software against the written requirements, not against assumptions.
We combine automated tests for business-critical logic with structured manual testing, including cross-browser and cross-device checks and a review against WCAG 2.2 Level AA practices.
Your team performs acceptance testing against the agreed criteria. Defects are tracked, prioritized, and resolved before release.
Produces
- Test results against acceptance criteria
- Defect list with resolution status
- Accessibility review notes
- 07
Deployment
Release to production with a rehearsed plan and a way back.
Production environments, monitoring, backups, and secrets are configured before launch. Where data migrates from an existing system, the cutover is rehearsed and reconciled.
Releases follow a repeatable pipeline with a documented rollback path.
Produces
- Production release
- Monitoring, alerting, and backup configuration
- Runbook and rollback procedure
- 08
Training and handoff
Make sure your team can operate, administer, and explain the system.
We deliver task-based documentation for users and administrators, plus working sessions with the people who will run the system day to day.
Handoff includes access to repositories, environments, and accounts as defined in your agreement, so your organization is not dependent on us for basic access.
Produces
- User and administrator documentation
- Training sessions
- Access and credential handover
- 09
Maintenance and improvement
Keep the system current, and improve it as the business changes.
Under a maintenance or support agreement, we apply dependency and security updates, correct defects, monitor errors and performance, and handle small enhancements.
Periodically we review how the system is being used and what has changed in the business, so improvements are based on evidence rather than guesswork.
Produces
- Scheduled updates and change log
- Support intake and response per agreement
- Periodic review of usage and priorities
What is settled in writing
Before development begins, the commercial and legal terms of the engagement are documented and signed. This page describes how we work; it is not itself an agreement.
Defined in your written agreement
Changes to scope