What I build with
There are two foundations: WordPress and hand-written HTML. The choice turns on a single question — and what runs beneath them is the same work either way.
- Written by
- Kristóf Karner — independent developer, Budapest
- Updated
- 11 August 2026
It is easy to answer this with a row of logos. That list says nothing about when each one is the right choice — and the decision turns on exactly that, not on how many tools fit on one line.
I work from two foundations, and choosing between them is the first real decision in every project.
WordPress or hand-written code
WordPress when you have to maintain the content. If the price list changes, staff arrive, articles get published — then there has to be a surface where that can be done without calling me. This is the most common case, and there is no reason to choose anything else for it.
Hand-written HTML when the content rarely changes, and in exchange the site should be fast, simple and durable. No database, no plugins, no system to keep updating — so there is nothing to go wrong. The page you are reading is one of those; there is a piece in the Workshop on why.
So the choice turns on this: who will edit the content, and how often? There is also a piece on what a template does and where it stops.
What runs beneath the surface
Most of the work is not the interface but the part no ready-made plugin covers. That means custom PHP, with a database, scheduled runs, and messages passing between systems.
This layer decides whether a site works or merely appears to. Taking a payment can be wired up on its own; making sure that after the payment the invoice goes out by itself, access opens, and all of it holds even when one step fails — that is no longer a matter of configuration.
What I connect
- Stripe — card payments, one-off and subscription alike. Wired to invoicing, the invoice issues itself.
- Telegram — admission to a closed group, removal on expiry, notifications. There is a piece on how that works in practice.
- Google Ads and Business Profile — campaign management and local presence, typically for the same clients whose sites I built.
- Mail delivery and authentication — SPF, DKIM and DMARC, so the system's mail does not land in spam. There is a piece on that too.
- Booking and scheduling — calendar, free slots, confirmation, reminder.
- THE QUESTION THAT DECIDES
- Who edits the content, and how often?
- CHANGES REGULARLY
- WordPress: editing interface, permissions, a system to keep updated
- RARELY CHANGES
- Hand-written HTML: no database, no plugins, nothing to go wrong
- BENEATH BOTH, THE SAME
- custom code: payment, invoice, access, notification, the links between systems
What never makes it onto the list
A few things are in every project that nobody asks for separately — because from the outside there is no sign they exist.
Publishing, automated. I do not copy files to the server by hand: a script checks, backs up, uploads, then measures back that what is live is what should be. This matters because the failures of manual publishing are silent — the page loads, something is just missing from it. I wrote up four such traps.
Machine-run checks. Links, font coverage, keyboard use, contrast, several screen sizes and several browsers. I do not eyeball these; I run them — there is a piece on what is worth handing to a machine.
Backups that can actually be restored. There is always a backup before going live, and I check that the backup is intact. A zero-byte database dump exists exactly as much as a good one — it just cannot restore anything.
What I do not solve
Taking over an unfamiliar system. If a site runs on something I do not know, I will not take it on for maintenance — the details are on the page about me.
The content. Copywriting, photography, logo design: these are separate trades, and you are better off with someone who does that for a living. I help work out what is needed — I do not write it.
Anything a template already solves. If you need a brochure site and there will be nothing beneath it, a site builder gets you there faster and cheaper. I will say so — there is a whole piece looking for exactly that line.
The tools change; the question does not: what happens when somebody uses the site? If the answer is that they read it and call, this is simple. If the answer is that they pay, book or log in, then the site is only the surface, and most of the work is beneath it.
Questions on this topic
What technologies do you work with?
I work from two foundations: WordPress and hand-written HTML. WordPress when the client has to maintain the content; hand-written HTML when the content rarely changes and the site should be fast and durable in exchange. Beneath both runs custom PHP with a database, scheduled runs, and messages passing between systems.
When WordPress, and when hand-written code?
A single question decides: who edits the content, and how often? If the price list changes, staff arrive or articles get published, there has to be an editing interface — that is WordPress. If the content rarely changes, hand-written HTML is faster and more durable: no database, no plugins, no system to keep updating, so there is nothing to go wrong.
Which external systems do you connect?
I connect Stripe for card payments, one-off and subscription alike; invoicing so the invoice issues itself after payment; Telegram for admission to a closed group and removal on expiry; Google Ads and Business Profile for advertising and local presence; booking and scheduling systems; and SPF, DKIM and DMARC configuration so the system's mail does not land in spam.
What do you not solve?
I do not take over an unfamiliar system, if it is neither WordPress nor hand-written HTML. Nor the content: copywriting, photography and logo design are separate trades. And anything a template already solves — if you need a brochure site with nothing beneath it, a site builder gets you there faster and cheaper.