4+ years in software engineering
Production applications, integrations and internal systems used in day-to-day business operations.
About
Build software that solves measurable problems.
Not software that demonstrates a technology. The difference shows up about three months after launch, when someone has to rely on the thing every day.
I'm an independent software engineer working with small and medium-sized businesses on AI and automation. Before that, most of my work was the unglamorous kind: enterprise systems, integrations, and applications that a company depends on to operate.
That background is the reason I'm careful about AI. A model is easy to demonstrate and difficult to depend on. The engineering that closes that gap — permissions, validation, retries, monitoring, evaluation, an honest audit trail — is the part that decides whether a business can actually put the system into its daily operation.
The AI side of my work runs from applied research through to production systems: language models, retrieval, agents, and computer vision. The useful part isn't the breadth. It's knowing which of those tools a given problem actually needs, and being willing to say when the answer is none of them.
Engineering depth that stays connected to the work.
Enterprise foundations, SME focus
The controls expected in larger systems, applied without importing the delivery overhead of a large consultancy.
Reliable applied AI
Evaluation, retrieval, agentic workflows, computer vision and human control at the points where uncertainty matters.
Five things I hold to on every project.
They cost me work occasionally. They're also why projects finish.
Solve the business problem first
If ordinary software or a simple automation does the job better, that’s the recommendation — even when it makes the project smaller.
Human control where it matters
Not every decision should be autonomous. Thresholds, approvals and escalation paths are designed in, not bolted on afterwards.
No unnecessary lock-in
Code, infrastructure, accounts and data stay under your control. You should be able to replace me without replacing the system.
Direct engineer access
The person who hears the problem is the person who designs and builds the answer. Nothing is lost in translation, because there is no translation.
Built for production
A prototype that works in a demo isn’t the deliverable. Security, logging, error handling and maintainability are part of the build, not polish at the end.
“Would I be comfortable if this ran unattended in someone's business next Monday?” — everything above is downstream of that question.
A consultancy's overhead is not free, and you pay for it.
Layers exist to coordinate large teams on large programmes. For a project sized to an SME, they mostly add cost, delay and distance between the problem and the person solving it.
- Client
- Salesperson
- Account manager
- Project manager
- Consultant
- Technical lead
- Developer
- Client
- Luke
Faster decisions, fewer misunderstandings, and small projects that stay commercially viable for both sides.
Technical
What I work with
Listed for completeness. It's rarely the thing that decides whether a project succeeds.
AI
7Models, retrieval and evaluation inside controlled workflows.
Backend
6Services, APIs and data flows that carry business rules.
Frontend
5Interfaces designed for clear, everyday operational use.
Cloud & infrastructure
6Portable deployment, automation and production operations.
Start with the process, not the technology.
Describe how something works in your business today and where it slows down. If AI isn’t the right answer, I’ll tell you that in the first conversation.