Sheet 03 · About
One engineer. No account managers.
LanceTek is me. The person you speak to on the first call is the person who writes the spec, builds the software, sets up the server and answers the phone when something breaks.
That’s a deliberate choice, not a stage on the way to an agency. It keeps prices sane and nothing gets lost between a salesperson and a developer.
How I work
Small, careful, and written down.
I’ve spent my career building and running software, and the lesson I keep relearning is that most problems come from things nobody wrote down: an assumption, a password, a “we’ll sort that later”. So I write things down — specs before building, notes after every fortnight, runbooks at the end.
Being one person has limits, and I’d rather be straight about them. I take on a small number of projects at a time. I don’t do 24/7 on-call. If your project needs a team of five, I’ll tell you, and help you brief one.
- P-1
Boring technology first
Proven tools that will still be supported in ten years. New things only when they earn their place.
- P-2
A person approves what matters
Automation does the drafting. Money, customers and deletions get a human click.
- P-3
You can leave
Everything is in your name and documented well enough for another developer to take over.
- P-4
Tested on my kit first
Every tool I recommend has run on my own servers before it goes near yours.
- P-5
Plain English, always
If I can’t explain why something is needed, it probably isn’t.
The homelab
Where things get broken before they reach you.
In a small rack at home I run the same kinds of systems I set up for clients: virtual machines, a backup server, a firewall, monitoring, and the AI agents I’m testing. When a new version of something comes out, it gets upgraded here first. When I write a restore procedure, I run it here first.
It’s also where the Journal comes from. When I review a tool, it’s because I’ve run it for a while on this kit, with real workloads, and seen how it fails.
Drawing is representative of the setup
Bill of materials
The stack I build with.
Mostly open source, all widely used. Chosen so that you could hire someone else to look after it.
| Item | Tool | What it’s for, in plain English |
|---|---|---|
| Building software | ||
| 01 | Python & TypeScript | The two languages most of my client work is written in. Easy to hire for later. |
| 02 | Django / FastAPI | Frameworks for the server side of web apps: logins, data, admin screens. |
| 03 | PostgreSQL | Where your data lives. Reliable, free and very well understood. |
| 04 | htmx & plain HTML | Fast, simple screens that work on old phones and don’t need a heavy app. |
| Automation & AI | ||
| 05 | Hosted LLM APIs | Large language models from established providers, chosen per job for cost, quality and where data is processed. |
| 06 | Local models | Smaller open models run on my own hardware — or yours — when data shouldn’t leave the building. |
| 07 | Evaluation sets | A folder of real examples every agent is tested against before any change goes live. |
| Running it | ||
| 08 | Debian Linux | The operating system on almost every server I set up. Stable and dull, in a good way. |
| 09 | Docker & Ansible | Written-down server setups, so a machine can be rebuilt exactly the same. |
| 10 | Caddy | The web server in front of everything; handles security certificates automatically. |
| 11 | restic | Encrypted backups, copied off-site, restored on a schedule to prove they work. |
| 12 | Uptime Kuma & Grafana | Watching for trouble, and sending a message to a person when there is some. |
Next step
Want to see whether we’d work well together?
A thirty-minute call is the quickest way to find out. No preparation needed.
I read every enquiry myself.
Usually within a working day.