Approach
How I assess, build, and hand over a project.
We agree what the work includes and what you’ll receive before starting. Depending on what you already know, that may be an assessment, a pilot, or an implementation.
Before you commission a build
One-Workflow Assessment
I’ll review one process with you and write up what could be automated, the technical constraints, and a recommended approach. You can use the report to decide whether to build it.
- A map of the current workflowWho does the work, which systems are involved, and where time is spent.
- A recommended approachWhat I would use, why I recommend it, and what could go wrong.
- A brief for a pilotWhat a first version would do and how you would test whether it helps.
This is a paid assessment. We agree the scope, fee, and schedule before starting, and you are not obliged to hire me for the build. If you already know what needs building, we can discuss that directly.
01 / Engagement stage
Discuss the problem
You explain the process and the problem you want to solve. I ask about the people, tools, and restrictions involved so we can agree what to investigate.
You receive: A problem statement, initial fit assessment, and proposed next step.
02 / Engagement stage
Assess the data and architecture
We review representative inputs, access requirements, deployment options, and the operating cost. For private AI, this includes exactly which data may cross which boundary.
You receive: A scoped design, assumptions, dependencies, acceptance criteria, and implementation proposal.
03 / Engagement stage
Build and test a pilot
We build one representative path and test it against agreed examples, including exceptions. Your team reviews the results before a wider rollout.
You receive: A working pilot, test results, and a recommendation on whether to proceed or change the approach.
04 / Engagement stage
Integrate and prepare for operation
We connect the approved systems, implement permissions and error handling, and prepare the release, fallback, and handover procedures.
You receive: The agreed implementation, source code, deployment configuration, and operating documentation.
05 / Engagement stage
Hand over and define support
We walk through how the system is operated and maintained. Support responsibilities, response expectations, and future changes are explicit.
You receive: A named operational owner, a handover walkthrough, and any separately agreed support scope.
What makes a good project
What I need to understand before proposing work
I’ll need to speak with someone who knows the process and can judge whether a change would help. A screen walkthrough, a few sample documents, and an estimate of the time spent on the work give us a starting point.
Before a build begins, the proposal specifies the deliverables, access needed, exclusions, external costs, acceptance criteria, and handover responsibilities. Private deployment and ongoing support are scoped to the environment and the available operating team.
If the pilot does not meet the agreed threshold, we can change the approach or stop with a documented finding. A useful assessment can conclude that a simpler system or an existing product fits better.
Start a conversation
Tell me about your project.
Explain what you want to improve and which tools you use. I’ll ask a few questions and tell you whether I think I can help.