// web_applications
Custom Web Application Development
Production web applications engineered off the happy path. Auth, data integrity, permissions, and failure states are built from the first slice — because real traffic finds every gap the demo skipped.
Norseson builds custom web applications that do not rely on the happy path. Most web apps work in the demo. The difference shows up later: the double-click that charges twice, the URL that exposes another user’s data, the deploy that eats a table.
One lab, one protocol. Scope is mapped before code is written, the build ships in small auditable slices, and every irreversible action gets a failure test before launch.
// what_we_build
What We Build
Operational views over live data: metrics, queues, alerts. Built to stay correct when the data is late, partial, or wrong.
Platforms your customers log into. Session handling, permissions, and tenant boundaries are tested before anyone outside the lab touches them.
Multi-tenant products from first commit to paying users. Billing, roles, and data isolation are architecture decisions, not a later milestone.
Flows where money moves and double-charges are unacceptable. Idempotent by design and reconciled against the payment provider, never trusting the client.
The high-privilege surface where one wrong click matters. Every destructive action is logged, confirmed, and reversible where physics allows.
Mobile-first apps that capture input on flaky networks. Writes queue locally and sync with conflict handling, so field data survives the dead zone.
// how_web_apps_fail
How Web Apps Fail
These are the defects that surface after launch, in production, with real users. Each one has a defense that is designed in from the start — none can be bolted on after the incident.
DUPLICATE_SUBMISSION
A user double-clicks submit, or a flaky network retries the request. Two orders, two charges, two records.
Counter: Every mutating endpoint accepts an idempotency key. The disabled button is a courtesy; the server-side dedupe is the defense.
STALE_CLIENT_STATE
The browser renders data that changed minutes ago. The user edits it, and the write lands on top of someone else’s.
Counter: Writes carry a version. The server rejects updates against stale state instead of silently overwriting, and the client revalidates on focus.
BROKEN_PAYMENT_FLOW
The charge succeeds but the order never saves. The customer paid and holds nothing.
Counter: Provider webhooks are the source of truth, not the redirect. A reconciliation job compares charges to records and flags any orphan within minutes.
PERMISSION_LEAK
A regular user constructs a URL and reaches an admin mutation. The framework allowed it because only the menu was hidden.
Counter: Authorization is enforced at the data layer — row-level security plus route guards — and every role-endpoint pair has a test that tries to break in.
DATA_LOSS_ON_DEPLOY
A deploy runs a migration that drops or rewrites live rows. The backup exists; the restore has never been run.
Counter: Migrations follow expand-and-contract, destructive steps ship separately from code, and restores are rehearsed before launch — not during the incident.
UNHANDLED_FAILURE_STATE
A fetch fails and the page renders blank. The user retries blind, or leaves.
Counter: Loading, empty, and error states are designed in the prototype phase. Every remote call has a defined failure rendering and a retry path.
These are not edge cases. They are the default behavior of web applications that were only tested on the happy path.
// build_protocol
Build Protocol
Discovery & Risk Mapping
Define the product, users, data, permissions, and irreversible actions. Output is scope and a failure map.
Prototype & Architecture
Core UX, database shape, API boundaries, deployment plan. Tradeoffs are decided here, on paper, where they are cheap.
Build & Verify
Small auditable slices. Permissions, persistence, edge cases, and failure states are tested as they ship, not at the end.
Launch & Harden
Production deploy, monitoring, recovery runbooks, security boundaries tightened against real traffic.
Iterate
Real usage drives the roadmap: fixes, hardening, new capability. Most clients keep a monthly retainer here.
// stack
Stack
frontend
Next.js, React, TypeScript
App Router, server components, typed end to end.
backend
Node
Server actions and API routes. Explicit contracts at every boundary.
data
PostgreSQL / Supabase
Row-level security, migrations under version control, tested restores.
infra
Vercel / managed infra
Monitoring and alerting from launch day, not after the first incident.
Constraint:
The stack is deliberately boring. Proven tools fail in documented ways; novel infrastructure fails during your incident. New technology enters a build when it removes risk, not when it is interesting.
// evidence
Evidence
lab_build
Client Portal
A customer-facing portal build: tenant isolation, magic-link auth, scoped document access.
view build→
field_note
What a Custom Web Application Costs
Where the money actually goes, and the bands most builds land in.
read note→
field_note
MVP Scope Absorption
How small changes silently double an MVP, and the protocol that stops it.
read note→
// faq
Questions
How much does a custom web application cost?
How long does a custom web application take to build?
Do you work with existing codebases?
Who owns the code?
What stack do you use?
Do you offer retainers after launch?
Scope, risks, and cost are defined in Discovery — before any code is written. The first step is a conversation about your system.