Selected work / 03 projects
Things
I’ve
Built.
I could tell you I like building systems.
Probably easier if I show you.
Most of what I build starts the same way.
I see something being done manually, something that takes longer than it should, or a system that I think could work better.
Then I start wondering what I’d build instead.
01 · Personal technical project
Automotive Finance
Operations Platform
This came from working in automotive finance and wondering what I’d build differently.
I kept looking at the problems we deal with day-to-day and thinking about what I’d want the system to do.
So I built one.
- Operations
- Workflow
- CRM
- Data
- AI
- Reporting
Real project screenshot — to be added
Proof goes here →
The problem
A lot of operational work involves jumping between different information, checks and systems.
I wanted to see what it would look like if more of that sat in one place.
What I built
I built an automotive finance operations platform around the sort of work I already knew.
It covers deal and payout tracking, workflows, dealer information, document checks, reporting and performance.
The idea was simple: make it easier to see what’s happening, what needs attention and what happens next.
How I thought about it
I didn’t want to build software just because I could.
I tried to start with the process first:
- What does someone actually need to do?
- What information do they need?
- What are they checking?
- What happens next?
- Where could something go wrong?
Then I designed the system around that.
What it taught me
The biggest thing I learnt was that building the screen is often the easy part.
The harder part is understanding the process properly.
Then you get into permissions, exceptions, data, integrations and everything that happens when something goes wrong. That’s when you start looking at software differently.
02 · Personal technical project
Custom CRM &
Business Operations Platform
I wanted to see how much of running a business I could bring into one system, so I built my own CRM.
I wanted it to be obvious what needed doing, who owned it and what was happening next.
- CRM
- Workflow
- Automation
- Reporting
- AI
- Business systems
Real project screenshot — to be added
Proof goes here →
The idea
Bring the main parts of the business into one place and make it obvious what needed doing, who owned it and what was happening next.
What I built
I built a CRM covering customers, leads, the sales pipeline, tasks, workflows, dashboards, reporting and automation.
I also tried putting AI inside the system instead of treating it as a separate tool.
Why I built it
This made me think about the whole system, not just one feature at a time.
- If one part of the system changes, what else needs to know?
- What should happen automatically?
- What does the user actually need to see?
- What information matters to someone managing the operation?
Those are the questions I found myself enjoying.
What it taught me
Changing one part of a system usually affects something else. I had to think about those connections as I built it.
03 · Practical automation
Payout
Confirmation
Automation
This started with a much simpler question:
Why are we spending time manually processing information that arrives in a predictable format?
- Make
- Automation
- Workflow
- Exceptions
- Human review
Payout confirmations arrive in an inbox. Someone then has to identify the information, match it to the right application and record it.
It’s repetitive, so I started wondering how much of it could happen automatically.
I separated the repetitive bits from the exceptions.
If the information is clear and everything matches, let the automation handle it.
If something doesn’t look right, stop and give it to a person.
Frontend visual demonstration
A simple example of how the decision could work. It isn’t connected to a live business system.
Yes · Valid ✓
Continue automatically
Record / update
Done ✓
No · Needs a human →
Stop automation
Human review
Automate
the repetitive.
Keep people
for the decisions.
The point isn’t to remove people.
It’s to stop wasting their time on the bits a system can handle.
The common theme
They all started
with a problem.
The projects are different, but I built them for pretty much the same reason.
I like working out how something works, finding the bits that are repetitive or harder than they need to be, then seeing if I can build something better.
I’m still learning.
But I’ve learnt far more by building these projects than I would have by just reading about the technology.
Notes from the work
What building
taught me.
- 01
Start with the process
Before deciding what to build, understand what people are actually doing and why.
- 02
The happy path is the easy bit
The interesting problems normally appear when something is missing, wrong or unexpected.
- 03
Automation needs an exit
If the system isn’t confident, there needs to be a clear way to hand the work back to a person.
- 04
The user doesn’t care how clever the code is
If it makes their job harder, it isn’t a better system.
- 05
Building is how I learn
I understand things much better once I actually try to make them work.
Why this matters
I’m not applying because I want to start learning this.
I’ve already started.
I’ve got the actual projects ready to demo too.
Probably easier to show you than write another paragraph about them.