How I Help

01

Understand

Work out what is really there.

This is often the right starting point when a system, body of content or operational process has grown over time and nobody now has the whole picture. Something may work, partly work or have stopped working, while important knowledge sits across people, documents, databases, spreadsheets, WordPress, email or old technical decisions.

I can reconstruct the current state, trace how information and responsibilities move through it, recover decisions from project history, and identify the parts that are useful, duplicated, fragile or poorly understood. The point is to understand enough to make a sensible decision about what should happen next, including the possibility that some things should be left alone.

Depending on the situation, that might involve:

• reconstructing a system, workflow or project history;
• tracing data, content and responsibilities across several tools;
• talking to the people who understand different parts of the work;
• recovering decisions from documentation, archives or earlier versions;
• mapping dependencies, ownership and hand-offs;
• identifying risks, gaps and realistic next options.

This kind of work is visible in IMLPO, the Digital Archaeologist and long-running publishing or platform environments where understanding the inherited system is part of the job.

02

Make usable

Turn existing knowledge into something people can work with.

Sometimes the useful material already exists but it is trapped in the wrong form. It may be spread across documents, files, websites and individual memory; buried inside a publishing archive; or organised well enough for the person who created it but not for anybody else.

Here the work is less about producing more information and more about giving what already exists a clearer structure. That can mean deciding what the important objects are, how they relate to one another, which source should be treated as current, and what kind of interface will make the material genuinely usable.

That can include:

• restructuring content, navigation or publishing workflows;
• designing fields, metadata, entities and relationships;
• connecting source material to a searchable or browsable interface;
• creating review and approval routes where material needs checking;
• preparing migrations without losing useful context or relationships;
• building documentation and handover so knowledge is less dependent on one person.

Richard Craven / Cravenverse, the Interactive Professional Portfolio and London Drawing all contain versions of this problem: the difficult part is not simply storing more material, but preserving enough structure and context for somebody to use it.

03

Build

Make the next useful thing.

Sometimes the problem is already understood well enough to move into implementation. That may mean a prototype first, or it may be sensible to build, connect, migrate or automate directly. I tend to favour the smallest credible thing that will tell us something useful, rather than making the first version bigger than the problem requires.

I now do much more of this implementation myself, often with coding agents as part of the development process. The important question is still what the system needs to do and what kind of decision belongs where. Some tasks benefit from AI interpretation; some need ordinary repeatable rules; some should remain explicitly with a person.

Depending on the project, I can:

• build a working prototype or internal tool;
• develop WordPress plugins and bespoke web applications;
• connect existing services and APIs;
• turn repeated manual work into a clearer workflow;
• implement deterministic rules where repeatability matters;
• use AI where interpretation, comparison or synthesis is useful;
• move a successful prototype towards something maintainable and usable in practice.

Lettings Compliance Checker and Trigger SMARTS are the clearest current examples. Both became working software, but from very different starting points and with different boundaries around automation and judgement.

Sometimes a smaller piece of work is enough

Not every problem needs a project. You may be deciding whether to rebuild something, choosing between two approaches, wondering whether AI is actually useful in a particular workflow, or wanting an experienced outside view before committing money or time.

A short review, a second opinion or a bounded investigation can be useful in its own right. If the right conclusion is that the existing system is good enough, or that the next step should be smaller than originally imagined, that is a perfectly worthwhile outcome.

That kind of work can include:

• second opinions and sense-checks;
• reviewing an existing proposal or technical approach;
• helping turn a vague problem into a brief somebody can act on;
• prototype or migration scoping;
• AI/workflow reviews;
• a short investigation before a larger decision.

What happens next?

You do not need to arrive with a finished brief. A rough account of what is happening, what you have already tried and where it feels stuck is enough to start. From there we can work out whether the useful next step is a conversation, a bounded piece of investigation, a prototype, an implementation or something longer-running.

If you want to look at the evidence first, Work shows selected projects and their current state. Method explains how I tend to approach complicated situations, and Ask Niche Clever lets you explore the wider professional record directly.