A half-formed idea is a perfectly good place to start.
Direct email details coming soon.
CASE STUDY / ENTERPRISE KNOWLEDGE / AI
Finding conflicting claims before they propagate throughout the business.
Surfacing contradictions across complex document estates so teams can establish what is current, accurate, and safe to act on.
The full case study will cover how claims were identified and compared across a large knowledge estate, how potential contradictions were prioritised for review, and how the supporting evidence was kept close to every flag.
The supporting code and full case-study content will be made available at a later date. Client and project details need to be anonymised carefully before publication.
Developing a job search and matching engine for a regional employment service.
The full case study will explore the search and matching approach, how relevance was evaluated, and how the experience was designed around the needs of jobseekers.
The supporting code and full case-study content will be made available at a later date. Client and project details need to be anonymised carefully before publication.
Turning 200,000 scanned pages a day into structured information.
Automating document classification and information extraction with AI running on confidential computing.
The full case study will describe the document pipeline, the classification and extraction challenges, and the safeguards required to process sensitive information at scale.
The supporting code and full case-study content will be made available at a later date. Client and project details need to be anonymised carefully before publication.
Turning EU regulatory requirements into compliance checks.
Automating checks to assess whether institutions comply with applicable EU regulations.
The full case study will cover how regulatory requirements were translated into verifiable checks, how evidence was handled, and where human review remained essential.
The supporting code and full case-study content will be made available at a later date. Client and project details need to be anonymised carefully before publication.
The most useful work often happens before the first answer.
A request usually arrives wearing the clothes of a solution. Build a dashboard. Add a feature. Automate a process. It sounds specific, which makes it tempting to start immediately. But specificity is not the same as clarity.
Before making anything, it helps to ask what should become different. Who is struggling? What decision cannot be made? What would a better day look like for the person doing the work?
Describe the change, not the deliverable
"We need a report" describes an object. "We need to notice a problem before it affects a customer" describes an outcome. A report might be the right response, but so might an alert, a better conversation, or removing a broken step.
This distinction creates options. It also gives the work a way to be evaluated that does not depend on how polished the deliverable looks.
Make room for a little uncertainty
A useful question should be specific enough to act on and open enough to be wrong about. If the answer is already embedded in the wording, the team is not really exploring. It is executing a decision that has not been named.
Write down the assumptions. Pick the one that would change your direction if it proved false. Find a small way to learn about it before the project becomes expensive to change.
A practical starting point
Try completing this sentence: "We want to help this person do this thing, because today this obstacle gets in the way." If the sentence is difficult to write, that difficulty is useful information.
A better question will not remove all the uncertainty. It will make the uncertainty worth working on.
MAKING / DRAFT NOTE
Make something small.
A real experiment beats a perfect plan that never leaves the page.
An idea can feel remarkably complete while it lives in a conversation. Everyone fills the gaps with their own expectations. Agreement is easy because each person may be agreeing to something slightly different.
Making a small version brings those differences into the open. It can be a sketch, a sample report, a clickable screen, or a manual version of a proposed service. The point is not to look finished. The point is to become discussable.
Choose what you need to learn
A prototype without a question can turn into a miniature production project. Before building, name the uncertainty. Do people understand the idea? Is the output useful? Does the proposed workflow fit the way the work actually happens?
Choose a form that exposes that uncertainty as directly as possible. If a conversation with a sample document can answer the question, a working application may be unnecessary.
Keep the edges honest
Be clear about what is real and what is simulated. A person testing an idea should not have to guess which parts work. Honest boundaries make feedback easier to interpret and prevent a convincing surface from creating false confidence.
Look for moments of hesitation, workarounds, and questions that repeat. Those signals are often more useful than a general statement that the idea looks good.
Decide what happens next
An experiment needs a decision at the end. Continue, change direction, learn more, or stop. Agree in advance on the evidence that would support each choice.
Small is not a compromise on ambition. It is a way to earn the next investment with something more reliable than enthusiasm.
TECHNOLOGY / DRAFT NOTE
AI is a tool. Judgment is the work.
Better tools still need a good reason to be used.
When a new tool makes something dramatically easier, it is natural to look for places to use it. That curiosity is valuable. It becomes more useful when it is paired with a clear understanding of the work itself.
Start with the task, not the technology. What takes time? What requires interpretation? What happens if the result is wrong? Who is responsible for noticing?
Separate assistance from authority
Drafting a first version is different from approving a final one. Finding potentially relevant material is different from deciding that it is reliable. Summarizing a source is different from establishing that the source is true.
Those distinctions should be visible in the workflow. A useful system makes it clear where a suggestion came from and where a person needs to exercise judgment.
Make verification part of the design
Review should not be an afterthought. Keep source material close to the output. Make uncertainty legible. Give people a straightforward way to correct a result and continue without fighting the tool.
The cost of reviewing an answer matters just as much as the speed of generating it. A fast draft that is difficult to verify may simply move the work somewhere less obvious.
Measure the whole task
Compare complete workflows, including preparation, review, correction, and recovery. Test with ordinary examples and difficult ones. Decide what level of error is acceptable for the particular use, rather than treating all mistakes as equivalent.
The goal is not to use the most technology. It is to make a piece of work genuinely better while keeping responsibility clear.
Linux
Go
Python
JavaScript
HTML
CSS
GitHub
Terraform
Azure
GCP
AWS
HTMX
PostgreSQL
Dapr
OpenCode
GitHub Copilot
Kubernetes
PyTorch
OpenSearch
Prometheus