01 / ALL WORK
AI applications, automations, and infrastructure.
The problem, my contribution, and what changed.
A new enquiry. A customer reply. A team ready to follow up.
Ask your documents a question. See where the answer came from.
Find business information and update records through a conversation.
Run a model on your infrastructure and connect it to useful work.
See your servers and network clearly. Notice what changes.
A new enquiry. A customer reply. A team ready to follow up.
An enquiry-handling workflow for a cleaning business, connecting the website to customer and staff communication.
The workflow connects website intake, customer acknowledgement, and staff notification. Those communication steps no longer need to be started separately for each enquiry.
Receiving an enquiry is only the first step. Someone still has to acknowledge the customer and pass the details to the people who will follow up. Doing those jobs manually creates repetitive work and makes the handoff dependent on someone checking the inbox.
One connected workflow handles the enquiry from capture to acknowledgement and team notification. Staff can pick up the conversation with the enquiry details already available.
I built the automation that collects website leads and sends the customer and staff the information they need.
Their website form details enter the workflow.
The submitted information is passed through the automation.
An automated email acknowledges the enquiry.
Staff receive the details for a personal follow-up.
Built in n8n with website lead capture and email steps. Lead scoring, CRM synchronisation, and additional follow-up sequences are possible extensions; they are not presented here as part of the completed scope.
Ask your documents a question. See where the answer came from.
A document question-answering application for finding information across a collection of uploaded files.
Users can ask questions across their uploaded documents and inspect the references returned with an answer. New uploads enter the ingestion process without someone manually starting it each time.
When knowledge lives in many files, finding an answer means opening documents, searching, and checking whether the information is relevant. A useful assistant must make the supporting source visible as well as produce an answer.
The application watches the upload directory and starts processing new files automatically. Users can then ask questions across the indexed documents and follow the source references in the response.
I built the document-ingestion and question-answering application, including automatic upload detection, searchable document storage, context selection, and source references.
A directory watcher detects new files and starts ingestion.
Content is extracted, split into smaller passages, and indexed in a vector database.
Retrieval finds candidate passages; a reranker puts the most relevant evidence first. The application can search again if needed.
The response includes sources so the reader can inspect the supporting documents.
This is a retrieval-augmented generation (RAG) application with a directory watcher, chunking, vector retrieval, reranking, and source attribution. Reranking improves context selection; it does not guarantee that every generated answer is correct. Privacy depends on the complete deployment and any external services used.
Find business information and update records through a conversation.
An AI assistant built in n8n and connected to ERPNext, a business-management application.
The assistant can work with ERPNext records through connected tools, bringing common data questions and requested updates into the conversation.
Everyday questions and data changes often require navigating several screens. A conversational assistant becomes useful when it can work with the underlying business records, rather than only explain what someone should click.
The agent receives a request, chooses a relevant tool, works with ERPNext through its API, and uses the returned information to answer the user or report the action.
I created tools for reading, creating, updating, and deleting ERPNext records, and connected those tools to an AI agent in n8n.
The user asks a question or requests a record change.
The agent selects the operation exposed by its ERPNext tools.
The selected tool calls the relevant ERPNext API operation.
The assistant uses the returned data to answer or report what happened.
The original implementation uses n8n agent tools and ERPNext REST APIs. MCP is a possible future integration path, not an already completed migration. The available operations and permissions must match the intended business access.
Run a model on your infrastructure and connect it to useful work.
A setup and deployment service based on my work with local models and application integration. This entry describes a capability, rather than a named client case study.
The intended deliverable is a usable model environment matched to the agreed workload. Its final scope depends on the hardware, application, and operating requirements.
A model that runs on a computer is not automatically ready for everyday use. Memory limits, response needs, application connections, and the path taken by data all affect the right setup.
Start with the intended workload, match a model to the available hardware, configure the runtime, and connect the assistant or application that will use it.
My work includes local model setup and application integration. I help shape the model environment around the tasks and infrastructure available.
Clarify the tasks, users, data needs, and response expectations.
Consider the model alongside memory and compute limits.
Set up inference in the chosen environment.
Make the model available to the assistant or application.
Ollama, local inference, application integration, and deployment. Local processing can keep inference on your own infrastructure; end-to-end privacy still depends on external tools, logging, and other integrations.
Service offering. No named client deployment, benchmark, or guaranteed model performance is claimed.
See your servers and network clearly. Notice what changes.
My ongoing self-hosted monitoring project for servers and an authorised home network.
The intended outcome is clearer visibility into servers, connected devices, and meaningful changes. Development and validation are ongoing; this is not presented as a finished monitoring product.
New devices, exposed services, and configuration changes can be easy to miss. Understanding them is harder when observations are spread across individual machines and commands.
Bring server and network observations into a central view so an operator can inspect the current state, recognise changes, and decide what needs investigation.
I am developing the monitoring application and bringing together my application-development work and interest in infrastructure.
Gather information from the authorised servers and network.
Present device and server information together.
Compare observations to highlight new activity.
Give the operator context for investigation and a next step.
The project focuses on self-hosted monitoring for Linux servers and Docker-based environments. Monitoring is limited to authorised systems. Any system-changing fixes should require operator approval.
In active development. Current work focuses on completing and validating the monitoring experience.
Chat on WhatsApp