Self-hosting your apps without a platform team
Verdict: good for a handful of internal apps; I still default to plain Docker Compose for anything critical.
Self-hosted deployment dashboards such as Coolify promise the convenience of a commercial hosting platform on a server you rent for a fraction of the cost. For a small business, that's a genuinely attractive offer. I've run one in the homelab for several months to see where the convenience ends.
Read the full entry
What it does well
Point it at a code repository and it builds, deploys and puts HTTPS in front of the app. Adding a database is a few clicks. For staff-only tools — a wiki, a form builder, an internal dashboard — it removes a lot of fiddly setup.
Where I'm cautious
The dashboard itself becomes something that needs updating, backing up and understanding. When something goes wrong underneath, you need someone who knows the layers it hides. And moving away later is more work than moving a plain set of configuration files.
What this means for you
If you'll have three or more small internal apps and want to add more yourself, I may suggest it. For a single system your business depends on, I'll use plain, documented Docker Compose, because any competent developer can read it without learning a product first.
Workflow tools vs. writing code: where I draw the line
Verdict: visual tools for glue between existing apps; code for anything with real business rules.
Visual automation builders like n8n let you wire apps together by dragging boxes: "when a form is submitted, add a row and send an email". They're excellent, and I use them. They're also the most common way I see small businesses end up with automations nobody understands.
Read the full entry
When a visual tool is right
Short, linear jobs between well-known services, with no decisions beyond "if this field is empty". Someone in your team can open it, see what it does and change it. That transparency is worth a lot.
When it goes wrong
Once a flow has branches for exceptions, retries and special customers, the diagram turns into spaghetti. It can't be tested properly, changes can't be reviewed, and a small edit can quietly break something else.
My rule of thumb
If I can't explain the flow on one screen, or if a mistake would cost money, the logic moves into ordinary, tested code — and the visual tool, if kept, just triggers it.
Why nearly everything I build starts with PostgreSQL
Verdict: the safe default. You'd need a specific reason to choose anything else.
The database is where your customer records, orders and history live. It's the part of a system you least want to be exciting. PostgreSQL has been developed in the open for decades, is free to use, and is supported by every serious hosting provider.
Read the full entry
Why it matters to you
It's a standard. If you part ways with me, finding another developer who knows PostgreSQL is easy. Your data can be exported in open formats. And there's no licence fee that can rise later.
When I use something else
For a small tool used in one office by a few people, SQLite — a database in a single file — is simpler to run and back up. I'll explain the trade-off during discovery.
Backups you've never restored are a hope, not a plan
Verdict: restic is my standard backup tool; the restore test matters more than the tool.
Most small businesses I speak to believe they have backups. Fewer know where they're stored, whether they're encrypted, or how long a full restore would take. This entry covers the setup I use for clients and the monthly routine that proves it works.
Read the full entry
The setup
restic takes encrypted, deduplicated snapshots and sends them to off-site storage in a UK region. Old snapshots are thinned automatically: daily for a few weeks, weekly for a few months, monthly beyond that.
The routine
Once a month a script restores the latest snapshot to a scratch machine and checks the files match. If it fails, I'm alerted. That's the part that turns "we have backups" into "we can recover".
Questions to ask any supplier
Where are the backups? Who holds the encryption key? When was the last test restore, and how long did it take?
Running AI models on your own hardware: when it's worth it
Verdict: worth it for sensitive documents and simple extraction; hosted models still win on harder reasoning.
Tools like Ollama make it straightforward to run open-weight language models on a machine you own, so documents never leave the building. I've tested this in the homelab against the kind of jobs clients ask for: reading invoices, sorting enquiries, summarising notes.
Read the full entry
Where local models do well
Pulling named fields out of fairly regular documents, classifying short messages, and drafting from templates. With good instructions and rules checking the output, they're dependable for these jobs.
Where they struggle
Long, messy documents and multi-step reasoning. Larger hosted models are noticeably better here. A capable local machine also has an upfront cost and uses electricity.
How I decide
Start with the data: if it's personal or commercially sensitive, local is the first option tested. Otherwise I compare both on your real examples during discovery and show you the results side by side.
Internal tools don't need a heavy front-end framework
Verdict: server-rendered pages with htmx cover most internal tools, with less to maintain.
Much modern web software is built as two separate systems: a back end and a large JavaScript application in the browser. For a customer-facing product with a big team, that can make sense. For a quoting tool used by six people, it mostly adds cost.
Read the full entry
The alternative
The server builds each page, and a small library called htmx swaps in updated parts without a full reload. It feels quick to use and there's half as much to build, test and keep updated.
What it means for your budget
Fewer moving parts means a smaller quote and a lower cost to change things later. Where a screen genuinely needs rich interaction — a drag-and-drop planner, say — I add it to that screen only.