Clients ask which technologies we work with. The honest answer is short: the boring ones. The longer answer is that every choice we make is shaped by one rule — if you decide tomorrow to take your project somewhere else, we shouldn't be a speed bump.
Here's what we reach for, and the reason behind each pick.
Plain HTML, CSS, and JavaScript.
For the websites we build, we default to plain HTML, CSS, and vanilla JavaScript. No React, no Next, no Vue, no build pipeline you'll have to keep alive for the next decade.
This isn't nostalgia. Frameworks exist to manage the complexity of writing large applications by hand — the repetition, the consistency, the refactors across many files. AI coding agents now do most of that work for us. The problem the framework was solving has moved somewhere else.
What you're left with is HTML the browser can run, on any host, edited by anyone who can read a text file. Five years from now, that file will still load. We can't say the same about whichever framework was current the day we built it.
Cloudflare for static hosting.
Marketing sites, blogs, landing pages — anything static — go on Cloudflare Pages. The deploy story is GitHub-connected: push to a branch, the site updates. The CDN is everywhere. The free tier is generous. We've never had an outage we noticed.
It also scales without a conversation. A post going unexpectedly viral doesn't turn into a bill conversation on Monday.
AWS for applications.
For anything beyond a static site — apps, dashboards, anything with a database, real users, an API — we deploy on AWS, in your account. Not ours. Yours.
The reason is mechanical. When the AWS account is in your name, the bill comes to you, the data sits on infrastructure you control, and the day you decide to move on from us, there's nothing to migrate. You change the password and we're gone. No invoice handoff, no DNS dance, no "we just need a few weeks to extract everything."
It also means the app can grow with you. If a project that started as a small internal tool turns into a real piece of business, AWS has the next ten years of capacity already waiting. No re-platforming.
GitHub for version control.
All code we write lives in a GitHub repository you own. We are added as collaborators; we are not the account holder.
This is the same pattern as the AWS choice. Your code, your repo, your history. If you replace us, the next vendor clones the repo and keeps going. There is no handover document, no zip file with the latest version. The repo is the handover, and it has been since day one.
The thread running through it.
If you read the four picks together, you'll notice none of them are really about technology. They're about handing the keys over.
Plain HTML so the code is readable. Cloudflare so the site survives without us. AWS in your account so the bill and the data are yours. GitHub so the history is yours. We don't charge for releasing what you already own. We don't keep credentials hostage. We don't run anything in our own account that you can't take with you.
The shape of the work is designed so that walking away from us is boring — a few permission removals and a quiet email.
That sounds bad for a vendor. It isn't. Clients who stay with us stay because the work is good, not because leaving would be painful. That's a healthier arrangement for both sides.
Pick boring, portable pieces. Put them in your name. Build the interesting parts on top.