What needs to change?
Describe the task, problem or goal and the operations that depend on it.
Applied software engineering
Understand the problem. Choose how to solve it.
Before writing code, we reproduce failures, measure the system and estimate what it will cost to maintain. Then we build, rescue a stalled project or fix.
01Ideas and systems assessed
02A method suited to context
03Clear criteria for evolution
What we have learned in the field
Many failures get fixed twice because nobody reproduced them.
Before touching code, we make the problem happen on demand. Only then can a fix be verified.
01
Idea and project assessment
The expensive part of software is rarely building it; it is maintaining it for years. We estimate both before starting.
02
Failure analysis
We reproduce the problem, test hypotheses about its cause and leave an automated test that flags it if it returns.
03
Development and maintenance
A team of two does not need the processes of a team of fifty. We size architecture, testing and releases to reality.
04
Requirements and regulation
Security and compliance cost little at design time and a lot at the end. We build them in from the start.
How software evolves
From assessment to a system that can evolve.
We understand the current state, design the change, build and validate it before operations. Each stage leaves decisions the team can review.
Assessment
Context, requirements and improvements
Design
Modules, dependencies and decisions
Validation
Build and verify the change
Evolution
Integration, operations and maintenance
Simplified representation of the process. Scope and stages are adapted to each project.
How we move forward
A clear method for moving forward with confidence.
We agree what done means and who looks after the software afterwards.
- 01
Diagnose
Goal, current system, failures and constraints.
- 02
Set the approach
Prioritised risks, scope and quality criteria.
- 03
Develop and maintain
Staged, tested deliveries with a maintenance path.
A practical question
How do we check a change before bringing it into the system?
A useful delivery has a clear scope and criteria for review. We connect the change to its dependencies, the necessary tests and how it will enter operations.
What your team can review
- 01
Assessment and priorities
An understanding of the problem, constraints and risks, with an initial scope the team can discuss.
- 02
Design and verifiable deliveries
Architecture decisions and staged development or correction, with agreed acceptance criteria and checks.
- 03
Continuity for the team
Relevant documentation, context transfer and an operations and maintenance path suited to what is built.
When it makes sense
When software needs a better-informed decision.
To decide what to build, recover a project or stop firefighting.
- 01
An idea needs technical assessment and a realistic plan
- 02
A project is stalled, has grown without direction or carries accumulating risks
- 03
Issues keep recurring and need investigation and prioritised fixes
- 04
Development and maintenance need clear practices and ownership
- 05
Security, quality or regulatory requirements need to be considered
Before we talk
A useful starting point.
You can start with an idea, an existing system or a recurring fault. The first goal is to understand where intervention makes sense.
What are we working with?
Identify the team, existing systems and integrations, and available documentation.
How would we recognise improvement?
Define expected behaviour, a task that should be completed or a failure that should stop recurring.
Let's talk
Let’s look at the problem behind the software.
Tell us what you want to build or what is failing.
Let’s talk