01
System discovery and documentation
Trace what the tool does, where data lives and which pieces are risky to change.
Internal tools and inherited systems
Internal tools & inherited system cleanup.
When an internal tool, admin process or inherited system is too useful to throw away but too messy to trust, I can help document, stabilise and extend it.
- System discovery and documentation
- Admin workflow cleanup
- Dashboard or tool extension
- Data and spreadsheet drift review
- Support notes and handover paths
- Practical stabilisation before replacement
01 Problems
When a useful tool becomes too risky to touch.
These are signs an internal system should be documented and stabilised before anyone tries to extend or replace it.
- A useful internal tool has no clear owner.
- Only one person knows how the process works.
- Documentation is missing or out of date.
- Spreadsheets, scripts and dashboards have drifted.
- The system is too useful to throw away but too fragile to trust.
- Small improvements feel risky because nobody understands the setup.
02 What I’ll fix
What I'd map before changing.
The goal is to understand the system first, then stabilise or extend it without making the mess worse.
02
Admin workflow cleanup
Remove confusing steps and make the important actions easier to follow.
03
Dashboard or tool extension
Add focused improvements without turning a useful tool into a rebuild by default.
04
Data and spreadsheet drift review
Compare sources of truth and reduce duplicated or contradictory records.
05
Support notes and handover paths
Leave practical notes, access context and support paths for the next maintenance moment.
06
Practical stabilisation before replacement
Fix risky foundations first so replacement decisions are made calmly, not in a panic.
03 Relevant proof
Proof from inherited and internal systems.
These examples show how useful but messy tools can be documented, stabilised and made easier to support.
Support and service registry
CMND
A registry for service routes, status feeds, documentation and deployed app entry points so support context is not scattered.
Why it matters here: Inherited system work often starts by putting scattered context into one maintainable place.
- Problem
- Service routes, status and deployment notes were too easy to separate.
- Built
- Registry views, status surfaces, route references and documentation hooks.
- Outcome
- Created one clearer place to understand and maintain deployed systems.
Cash-flow planning workflow
BillBoard
A local single-user cash-flow MVP built around calendar, budget, accounts and bank views.
Why it matters here: Spreadsheet-heavy planning needs clearer surfaces before it becomes safe to extend.
- Problem
- Planning cash flow across accounts needed a clearer day-by-day surface.
- Built
- Calendar-led views, account structures and budget planning flows.
- Outcome
- Created one reliable place to model the process and reduce spreadsheet drift.
Domain and naming workflow
Doname
A domain idea generator with keyword and tone input, optional AI seeding, availability checks, analytics, caching and deep links.
Why it matters here: Useful tools often need clearer states, checks and result paths before more features are added.
- Problem
- Domain research can become a messy loop of ideas, checks and dead ends.
- Built
- Search flow, API integration, caching, analytics and result states.
- Outcome
- Turned scattered domain checks into a clearer availability workflow.
Inherited system documentation
oOMF! Logic
A self-hosted platform for scanning software projects and generating documentation, architecture notes, diagrams and project bundles.
Why it matters here: Messy systems become safer to change when they can be inspected and documented first.
- Problem
- Project knowledge was too easy to lose inside files, assumptions and handover notes.
- Built
- Read-only analyser, generated docs, diagram export, agent workflows and browser QA.
- Outcome
- Made inherited systems easier to inspect, document and maintain.
File workflow / sync safety
Cloud Sync Toolkit
A safer local-master and SharePoint sync workflow with preflight checks, seed scripts, filters, logs and user-level timers.
Why it matters here: Fragile file or workflow systems need guardrails before they can be trusted.
- Problem
- File sync can become risky when rules, filters and state are unclear.
- Built
- Preflight checks, local-master structure, logging, filters and operational guardrails.
- Outcome
- Made file sync safer, easier to inspect and easier to recover.
Technical inventory / documentation
PC Customisation Inventory
A living inventory of customisations, services, scripts, automations and helpers with generated summaries and stale item tracking.
Why it matters here: Living documentation reduces the risk of useful scripts and customisations becoming forgotten infrastructure.
- Problem
- Useful scripts, services and setup notes are easy to forget or duplicate.
- Built
- Inventory automation, documentation structure, refresh commands and audit modes.
- Outcome
- Made the system easier to maintain, explain and improve.
04 Entry offer
Good first step
Inherited-system review
I will inspect the tool or workflow, document what matters, identify the risky parts and recommend the smallest useful stabilisation path.
Request an inherited-system review05 How it works
How I'd make the system safer.
Inherited systems need patience first: understand the useful parts, then make careful changes.
Map what exists
Trace users, data, dashboards, scripts, admin steps and risky dependencies.
Document the fragile parts
Make the system easier to understand before changing it.
Stabilise first
Fix the smallest risky pieces before deciding whether to extend or replace.
Extend carefully
Add practical improvements without making the inherited mess harder to maintain.
06 Fit and budget
A quick check before changing a risky system.
Inherited tools usually need discovery, documentation and stabilisation before anyone makes bigger decisions.
Fit check
This is probably a good fit if...
- Odd but valuable internal tools
- Inherited systems nobody fully understands
- Admin workflows that need documentation before change
Scope check
It is probably not the right fit if...
- Rip-and-replace before discovery
- Unsupported black-box access without context
- Large enterprise transformation programs
08 FAQ
Questions worth clearing up.
Can you work on a system nobody fully understands?
Yes. The first step is discovery and documentation so changes are made with less guesswork.
Do you replace old tools or stabilise them first?
Usually stabilise first. Replacement decisions are better once the risks, users, data and workflows are understood.
Can you document the system before changing it?
Yes. Documentation, diagrams, access notes and handover context can be the first useful outcome.
Can you work with spreadsheets, scripts and dashboards?
Yes. Many inherited systems are a mix of spreadsheets, scripts, dashboards, admin pages and manual steps.
What access do you need?
I will ask for the minimum useful access, which may include admin panels, repositories, hosting, spreadsheets, dashboards or sample data.
What happens if the system should be rebuilt?
I will outline the smallest safe stabilisation path first, then separate rebuild, replacement and migration options clearly.
10 Start
Have a useful internal system that feels risky to change?
I'll help document what exists, identify what is fragile and recommend the safest path to stabilise or extend it.
A rough version is fine; context is useful. Prefer email?
Email me directly