What we build on the web
There are three kinds of web work here. The first is the front door: a marketing or company site that has to be quick, clear and easy to update. The second is the application itself — a web app with sign-in, forms, dashboards or a workflow that used to live in email and spreadsheets. The third is the plumbing: the API, the data model and the deployment that the mobile app and the website both use.
We build all three, and we build them to fit together. When the same team writes the API and the clients that call it, the shape of the data is decided once, and the seams between the parts stay thin.
Front ends that stay fast
Speed is mostly decided before the first line of JavaScript is written: how much is sent, when it is sent, and what the browser has to do before it can show anything. We start with clean, semantic HTML and a stylesheet sized to the page, add behaviour only where it earns its place, and keep third-party scripts to a minimum. Accessibility is part of the same discipline — keyboard paths, focus states, contrast and meaningful alt text are checked as the page is built, not bolted on afterwards.
This site is an example of the approach: static HTML, one stylesheet, a small script for navigation and nothing loaded from a third party. No analytics, no font servers, no cookie banner because there is nothing to consent to.
Web applications and APIs
For applications we work with server-rendered pages and straightforward APIs rather than a heavyweight stack that has to be tamed. Authentication, permissions, validation, error states and the less glamorous parts of a form — retries, duplicate submissions, what happens on a bad connection — are where most of the real work sits. We handle those properly and test them before launch.
On the API side, we design for the clients that will call it: predictable endpoints, clear errors, versioning that does not break older app builds, and rate limits that protect the service without punishing real users. If a mobile app is already in the field, the API has to tolerate versions of it you can no longer update.
Built to be handed over
We are not interested in lock-in. The code is yours, it lives in a repository you can access, and it runs on infrastructure you can reach. When the project ends you get the source, the deployment steps and a written note of what depends on what — enough for another developer to pick it up, or for you to carry on with us.
That also means choosing boring, well-supported tools over novel ones. A site or app that a small team can still understand in two years is more valuable than one that was clever on launch day.
Deployment and hosting
A website is only finished when it is live, monitored and recoverable. We deploy with Docker-based hosting, keep environments separate, put TLS and strict security headers in front of the app, and take backups that have been restored at least once rather than merely scheduled. If you already have a hosting setup, we will work with it; if you do not, we will run it for you. More on cloud and infrastructure.
Who this is for
Companies that need a serious web presence without a large agency, founders whose product already exists on mobile and now needs a web counterpart, and teams that have inherited a site nobody can safely change. If any of those sound familiar, tell us what is not working and we will tell you what it would take to fix it.