Software
Web applications
Web software built to be used every day — fast, accessible, and maintainable by someone who did not write it.
What this is
The work, described plainly
A web application is not a website with a login. It has state, permissions, background work, and a data model that will be wrong in places you cannot predict, so it has to be built to change.
We build with server rendering by default, because a page that arrives complete is faster, more reliable, and legible to search engines and language models without a workaround. Interactivity is added where it earns its weight rather than applied uniformly.
Accessibility is treated as correctness, not as a phase. Keyboard operation, focus management, and contrast are part of the build, because retrofitting them means rewriting the components.
What you get
What is actually handed over
Concrete deliverables, not phases on a timeline.
Product engineering
Database, server, and interface, built as one system rather than assembled from three teams.
Authentication and roles
Enforced server-side on every route, with the interface reflecting permissions rather than defining them.
Deployment and CI
Automated checks and a deployment path that does not depend on one person’s laptop.
Documentation
Architecture, decisions, and the reasoning behind them, kept in the repository.
Is this you
Signals this is the right fit
- You need software your team uses all day, not a brochure.
- You have outgrown a no-code tool.
- A previous build is slow, fragile, or nobody can maintain it.
- You need it to work on the connections your users actually have.
Typical stack
Chosen per project against your constraints, not applied by default. This is what the work usually involves.
- Next.js and React
- TypeScript
- MySQL or PostgreSQL with Prisma
- Tailwind CSS
- Playwright
FAQ
Questions people actually ask
Do you work with an existing codebase?
Yes. We start with a written assessment of what is there before proposing changes, because inheriting a system and rewriting it are very different projects with very different costs.
What about hosting?
We deploy to whatever suits your constraints, including managed Node hosting rather than assuming a cloud platform. Hosting choice follows your budget and data rules, not our preference.
Will it work on slow connections?
That is a design constraint from the start. Server-rendered pages, restrained JavaScript, and assets sized for real networks rather than office broadband.
Start here
Tell us what is slow, manual, or breaking.
Answer a few questions and get a written brief back — scope, proposed architecture, and what it would take to build.