Web Development
Web platforms that earn their keep.
Self-hosted, accessible, performant, and built to be owned by you — not rented from a SaaS. From marketing sites to client-facing platforms with auth, file collaboration, and real-time features.
Web platforms, not template sites. The distinction matters. A template site is a brochure with a publish button. A web platform has users, sessions, state, and consequences when something goes wrong. The architecture, the testing, and the operational posture are different.
We build both kinds — but the work is paid attention either way. A marketing site that loads fast on a slow connection still matters. A client portal with auth, file collaboration, and billing is what we are happiest doing.
You should not be renting your business from a SaaS that can change its terms next quarter. The platforms we build are yours to keep, written in code your team can read, deployed to infrastructure you control.
Six commitments that show up in every project.
You own the infrastructure.
Code, database, and deploy targets you control. No SaaS platform that can change its pricing, terms, or feature set on you next quarter.
Accessibility is the baseline.
WCAG AA on every shipped page. Keyboard navigation, screen-reader semantics, and color contrast are part of done — not a checklist at the end.
Performance is a feature, not a tuning pass.
Budgets set during architecture. LCP, bundle size, and render path measured continuously, not just before launch.
Type-safe end to end.
TypeScript everywhere — server actions, database queries, API contracts. Whole classes of runtime bugs become compile errors.
Documentation written for the next engineer.
Architecture decisions captured. Setup paths reproducible. The team that maintains the platform after launch should not need us in the room.
Security is upstream of features.
CSP headers, secret hygiene, input validation, audit logging. Built in early — not patched after a pentest.
Four phases. Each one is shippable.
Discovery
We start with the workflow, not the wireframe. Who uses the platform, what they do every day, where the existing tools fail them. Outputs are written and signed off before any code is written.
- Stakeholder interviews and workflow audit
- Technical risk register and constraint document
Architecture
A short, opinionated technical document that decides what the platform is, what it depends on, and how it scales. Database schema, auth model, deploy target, monitoring posture. The document is the contract.
- System architecture and data model
- Performance + accessibility budgets
- Hosting, CI/CD, and observability plan
Build
Sprints with shippable increments at the end of each. Continuous deployment to a staging environment from day one. Tests written alongside features, not after. The platform is reviewable in a real browser within the first week.
- Production code with type safety end to end
- Test suite covering critical user paths
- Live staging environment for review
Ship + Support
Launch, monitoring, and a 30-day window of close support. Runbooks for the routine, escalation paths for the not-routine. Optional retainer for ongoing work — the choice stays yours.
- Production deployment with monitoring + alerting
- Handover documentation + runbooks
- 30-day post-launch support window
A defensible stack, picked for ownership and maintainability.
- Framework
- Next.js (App Router) + React Server Components
- Language
- TypeScript, end to end
- Database
- Postgres (self-hosted or managed)
- Auth
- better-auth, session-based, no third-party identity required
- Styling
- Tailwind CSS v4 with design tokens
- Hosting
- Self-hosted (EC2, fly.io, or your infrastructure)
- CI/CD
- GitHub Actions with blocking quality gates
- Monitoring
- Sentry + self-hosted analytics (Umami)
Platform work, in production.
More platform case studies in production. SwiftFX, Noctiv Studio (this site), and several private engagements queued for publishing once their teams approve. Selected work is curated, not exhaustive — when something is ready to show, it shows up here.
Ready to discuss a web project?
Send a brief, a sketch, or a problem you have not been able to solve with off-the-shelf software. We will come back with how we would approach it.
Discuss a web project