Software you own,
on servers you control.
Most "custom" web work is a framework, a hosting platform and six SaaS subscriptions wired together — which works until one of them changes its pricing. We build applications that run on your own infrastructure, in code you can read, with no vendor able to switch them off.
The argument, made with this website
You are reading it right now, so it is a fair thing to inspect. This site is not WordPress, not Next.js, and not a page builder. It is a Node HTTP server we wrote, with no web framework, backed by PostgreSQL with a JSON mirror for resilience, running behind nginx on a single Hetzner box we administer.
Running on that same server, all of it built here:
- Booking systemTimezone-aware slot picking, first-free selection, confirmation email and calendar invite. Not Calendly.
- Client & billing moduleRetainer plans, billing cycles, auto-numbered invoices, publicly shareable invoice links, revenue grouped by currency with no invented exchange rates.
- Leads CRMPipeline, per-lead history, send-from-dashboard, and open/click tracking implemented directly rather than rented.
- Real-time relayA WebSocket relay behind nginx powering RoomDrop — pair two devices by sound and send an encrypted file between them, in the browser.
- Mail infrastructureEvery address on this domain, on our own Postfix/Dovecot stack. See the email pillar.
- Measurement toolingHeadless Chrome driven over the debugging protocol for real Core Web Vitals — the numbers on our work page came out of it.
Server response for this page is around 0.4 milliseconds measured on the box itself. That is not an optimisation story; it is what happens when there is almost nothing between the request and the response.
What we build
- Internal toolsThe dashboard your team actually operates the business from — orders, inventory, scheduling, approvals. Usually replacing a spreadsheet nobody trusts and three subscriptions nobody audits.
- Customer portalsAccounts, documents, statements, bookings. The things a SaaS product charges per seat for, built once for your business.
- APIs and integrationsMaking systems that were never designed to talk to each other do so reliably — with retries, idempotency, and a state you can read when something fails at 3am.
- Marketing sites that stay fastWritten, not assembled. If a page is heavy it is because you asked for something heavy, not because a builder shipped 400KB of runtime.
- InfrastructureLinux, nginx, TLS, systemd, backups, firewall and monitoring on a server you own. We run multi-tenant production on this stack.
How we think about the stack
Boring is a feature
A dependency is a promise someone else made about the future. Every one you add is a thing that can break, change licence, get abandoned, or require an urgent upgrade at an inconvenient moment. We add them when they earn their place and not because they are conventional.
The practical result is applications that still run, unmodified, years later — and that any competent developer can pick up, because there is no framework to learn first.
- PostgreSQL as the source of truth, with the schema designed rather than generated.
- Fail visibly. Every job has a readable state. Silent failure is the real risk in automated work, not a wrong answer.
- Deploy simply. One command, a restart measured in seconds, and a rollback that is just the previous directory.
- Measure, do not guess. Real instrumentation on real pages. It is how we found that our own stylesheet was shipping 130KB of fonts nobody needed.
Where this fits with the rest
Most engagements are not purely one thing. A Shopify brand needs a fulfilment bridge. A web application needs transactional mail that actually arrives. The four pillars — Shopify, web, email and AI systems — are the same team, and the reason we keep them under one roof is that the integration between them is usually where projects fail.
Common questions
Why not just use a framework?
For a large team rotating people through a codebase, conventions are genuinely worth the weight. For a focused application maintained by a small team, the weight is a cost with no matching benefit — and framework major versions arrive whether or not your project wanted one. We will use a framework when the project argues for it.
Who owns the code and the servers?
You do, both. Code ships in a repository you own; infrastructure runs on an account in your name. If you stop working with us, nothing stops working. We think that constraint makes us better, not more replaceable.
Can you take over an existing codebase?
Yes, and a fair amount of our work is that. The first deliverable is usually an honest assessment of what is worth keeping — sometimes the answer is that the existing system is fine and the actual problem is three specific things.
Do you do ongoing maintenance?
Yes, on a flat monthly retainer rather than hourly, so neither of us is incentivised to make a small fix take longer. Security updates, backups, monitoring and a defined amount of change work.
What does it cost?
Fixed quotes for defined builds, flat monthly for ongoing work. We quote after scoping rather than off a price list, because the honest number depends on integrations, not on page count.
Describe the thing your team does manually
The best custom software projects start from a person doing something repetitive, not from a technology. Tell us what that is and we will tell you whether it is worth building — including when the answer is no.
Book a call →