Evaluate your software. Build what you need.
We evaluate software from the code outward and build custom projects. Bring an existing product or a new idea to the conversation.
We use our own tooling to trace symbols and consumers, measure codebase structure and the seams where it can be taken apart, capture browser journeys, and examine deployed crawler responses.
The product and the decision
An evaluation can read a product across its source, tests and seams, runtime and deployment, browser journeys, crawler responses and authorised security checks.
Taking over software, considering a rebuild, or investigating a recurring problem? Bring the decision your team needs to make and what you already know about the product.
Custom builds
We build custom projects, including websites. We write decisions down and run checks automatically as part of the build.
Tell us what the software needs to do, who will use it and what it needs to connect to.
An evaluation reports what it finds. Discuss a change to the existing product or a custom build as its own piece of work.
What an evaluation can examine
These are subjects for a conversation about your product. The question and the available access determine which checks belong in the evaluation.
Source and contracts
How do the concepts, schema and interfaces fit together?
What we look atThe data model, contracts between parts, abstractions and dependencies; symbols, their consumers and the paths through the code.
Tests and seams
Where can the system be taken apart, and what do the tests replace to do it?
What we look atTests alongside the code they exercise, dependency coupling and the seams between domains.
Runtime and deployment
How is the product deployed, and what can be observed while it runs?
What we look atThe deployment environment, data and service dependencies, and the signals available from the running system.
Browser journeys
What happens when a person uses the product?
What we look atA product journey in a browser, with captured evidence of the interaction and the behaviour on screen.
Crawler responses
What does a crawler receive from the deployed site?
What we look atThe responses a crawler gets for each deployed address.
Authorised security checks
Where is access enforced, and what happens at the boundaries?
What we look atAuthorisation, input validation and failure behaviour within an explicitly authorised security scope.
The written record to discuss
Agree what the written record needs to answer. For an evaluation, the subjects are:
What was examined
The parts of the product examined, the checks that ran and the access that was unavailable.
Findings and the evidence behind them
What was found, how it was checked, and what it means for the product.
Changes to consider
Proposed changes, the reasons for them and what would demonstrate their effect.
Questions still open
What could not be observed and what further evidence is needed.
What to bring to the conversation
Name the product or the project, and the people who look after it.
- Your question
- What decision are you trying to make, or what does the new software need to do?
- Access
- What can be shared or examined, and what must stay inside your environment?
- If the product cannot leave its environment
- Talk to us about mapping what stands in the way of an evaluation in place: deployment, data and service dependencies, permissions, reproducibility and observability.
- Focus
- Which product journey or requirement should the work address?
- The written record
- What would your team need to refer to afterwards?
Findings and reasoning
Ask for the evidence behind a finding and the reasoning behind a proposed change.
- What was examined?
- What supports the finding?
- What remains uncertain?
Keep the boundaries clear
Agree the scope, access and permitted checks before the work begins.
What can be examined
Identify what can be inspected in place and what can be shared. Agree the data boundary and any security checks explicitly.
What the evidence supports
Keep observed behaviour, findings from the source and questions still open distinct in the record.
What happens afterwards
Discuss how your team would use the findings and whether a change to the product is the next piece of work.
Start with a conversation
Tell us about the software you have or the project you want to build.
Get in touch