Fixed-scope engagement
Best for a bounded discovery, assessment, prototype or delivery slice with agreed outputs and acceptance criteria.
Make the important decisions early.
Complex software cannot be made risk-free, but it can be made legible. We expose the important decisions early, deliver in controlled slices and keep business context close to engineering.
We begin with a fit and scoping conversation. If the problem is clear enough, we recommend a delivery shape and indicative investment. If uncertainty is material, we propose a bounded discovery with explicit questions, outputs, timing and cost.
How a project moves from scope to operation.
The stages may overlap, but their purpose does not: understand the outcome, de-risk the path, deliver value and sustain it.
- 01 / FRAME
Understand what must improve
Current operation, users, rules and exceptions. Then the baseline you want to improve.
- 02 / SHAPE
Design and de-risk
Target journeys, architecture, integration boundaries and delivery slices.
- 03 / DELIVER
Build in working increments
Short feedback loops, automated quality controls, real data paths and stakeholder validation.
- 04 / OPERATE
Launch and improve
Migration, release, observability and support—then an improvement backlog led by evidence.
Choose a contract that fits the work.
A fixed number does not remove uncertainty; it decides who carries it and how it will surface. We choose the model that makes incentives and trade-offs clearest.
Dedicated capacity
Best where priorities can change as users, data and the system reveal what creates the most value.
Support and evolution
A planned blend of operational support, maintenance and incremental improvement after launch.
What every proposal should make clear
Outcome, scope and exclusions. Team and responsibilities. Delivery stages, timeline and fees. Material risks, and how change will be handled.
Keep decisions, risks and progress visible.
One accountable product view
A visible outcome, prioritised backlog and named decision-makers keep work aligned.
Working software as the centre of the conversation
Progress is demonstrated in the product and its operating data, not inferred from status reports.
Risks owned while they are still small
Architecture, security, data, migration and dependency risks are tested before they become release blockers.
Context that survives handovers
Decisions, contracts, runbooks and system knowledge are captured where the future team can use them.
Questions about working together.
How does a software project start?
With a fit and scoping conversation. If the path is clear, we can recommend delivery and an indicative investment. If not, we define a bounded discovery that resolves the uncertainty required for a responsible commitment.
Do you use fixed-price or time-based pricing?
Both, depending on uncertainty. Defined discovery or delivery slices can be fixed by scope. Evolving product work is usually better served by transparent dedicated capacity with explicit priorities and regular investment decisions.
Will we own the software and documentation?
Ownership, licensing, repositories, environments and access are made explicit in the agreement. We design for practical client ownership and do not rely on hidden proprietary dependencies to create lock-in.
Can you take over an existing system?
Yes. We begin with a structured technical and operational assessment, stabilise the highest risks, establish a safe delivery path and then improve or modernise in measured stages.
Tell us where the work is stuck.
We will help you work out the smallest responsible next step.