Custom web development, measured in milliseconds.
A full-stack web development company where performance is a contract, not a promise. Published Core Web Vitals targets, honest stack picks by problem, and code we show you before you sign.
A fintech dashboard, taken apart.
Most web development pages open with "we build websites." Here's the actual architecture we'd propose for a hypothetical 20-person fintech team needing a client dashboard, showing every decision and why. This is how we think. Stack of record: Next.js, React, TypeScript, Vercel, Cloudflare.
Frontend
Next.js 16 · TypeScript
State + data
React Query · Zustand
API
tRPC · Hono on Node
Database
Postgres · Drizzle
Auth + billing
Clerk · Stripe
Infra + deploys
Vercel · GitHub Actions
Observability
Sentry · PostHog · Axiom
Every decision above is defensible. Every one has at least one alternative we rejected for a named reason. That's the conversation you get on day one.
- Stack-of-record: Next.js + React + TypeScript on Vercel, with Postgres + Drizzle, tRPC, Clerk, Stripe, Sentry, PostHog.
- Frameworks chosen by problem, not favourite: Astro for content, Next.js for SaaS, Remix for forms, Hydrogen for Shopify headless.
- Core Web Vitals shipped as contract: LCP under 2.5s, INP under 200ms, CLS under 0.1, verified via PSI field data.
- We refuse five common anti-patterns: micro-frontends at small scale, GraphQL by default, custom CMS for 20 pages, NoSQL without reason, Redux in 2026.
- Four engagement shapes: a 2-week performance rescue, a 2-4 week single-page build, a 6-8 week marketing or product site, or a 10-20 week custom web application. Contact for a 48-hour scoped quote.
We don't pick a favorite. We pick the right one.
Every framework is good at something and bad at something else. We map problem to pick: Astro for content-heavy editorial, Next.js for marketing-plus-product, Remix for form-heavy workflow, Hydrogen for headless Shopify, SvelteKit for tiny teams, Astro Starlight for docs portals. The decision isn't "best in 2026", it's "best for your problem."
| If your site is… | Our pick |
|---|---|
| Content-heavy blog / editorial | Astro |
| Marketing site + some interactivity | Next.js 16 |
| SaaS product with dashboards | Next.js 16 |
| Form-heavy workflow tool | Remix |
| Shopify storefront (headless) | Hydrogen |
| Small team, fast author velocity | SvelteKit |
| Regulated / government / healthcare | Next.js + AWS |
| Documentation + docs portal | Astro (Starlight) |
| Real-time + collaborative | Next.js + Partykit |
We'll argue against our own pick if your situation warrants it. The call happens on the Discover week, not in the contract.
Core Web Vitals, in writing.
Every engagement ships a Core Web Vitals contract: LCP under 2.5s, INP under 200ms, CLS under 0.1, verified at the 75th percentile of real users via PSI field data. Miss any threshold at launch, the launch sprint is refunded. No discovery-deck wiggle language.
The largest visible element renders within 2.5 seconds on a throttled Moto G4 over 4G. Verified via PageSpeed Insights field data. Mobile and desktop both.
The slowest interaction responds within 200 milliseconds. This replaced First Input Delay in March 2024. We ship under it at the 75th percentile of real users.
No layout shift above 0.1 in the page's lifetime. Images sized, fonts preloaded, ads and embeds reserve their space. The page doesn't jump under your finger.
Field data, not lab
PSI field data on mobile, 75th percentile, 28-day rolling window. Lab scores are nice; field data is the actual user experience.
Real user monitoring
web-vitals package reports every user's LCP, INP, CLS to our Axiom instance. We see regressions the same day, not the same quarter.
CI gates
Lighthouse CI runs on every PR. A score below threshold blocks the merge. Bundle-size guard does the same.
Not everything should be custom.
Most "custom" web dev is reinventing infrastructure that a hosted product already does better. Buy auth (Clerk, Auth0), CMS (Sanity, Contentful, Payload), billing (Stripe, Paddle), search (Algolia, Typesense), email (Resend, Postmark), analytics (PostHog). Build the workflow that's your product's moat. Reference: MDN web platform docs.
- ✓The workflow is your product's competitive moat — the thing customers pay you for
- ✓You've tried three SaaS options and each one hits a wall your users complain about
- ✓Data sensitivity or compliance forbids routing through a third party
- ✓Performance requirements (latency, throughput, edge) exceed what any SaaS offers
- ✓Volume makes SaaS per-seat pricing uneconomical at 18+ months
- ϵYou need auth. Buy Clerk or Auth0. We will not build auth.
- ϵYou need CMS. Buy Sanity, Contentful, or Payload. Don't build an admin panel.
- ϵYou need billing. Buy Stripe. Buy Paddle for tax-handled SaaS.
- ϵYou need search. Buy Algolia or Typesense. Don't write regex in production.
- ϵYou need email. Buy Resend or Postmark. Don't configure SMTP servers.
- ϵYou need analytics. Buy PostHog. Don't roll your own event pipeline.
The rule: buy the infrastructure. Build the thing only you can build.
Here's what our code looks like.
A 17-line Next.js server component that fetches a user and renders their dashboard, typed from the database all the way to JSX. Authenticated, type-safe via Drizzle, graceful not-found, zero client JavaScript for the data fetch, zero loading spinner. No frameworks-within-frameworks, no state machines for a loading spinner.
import { auth } from '@/lib/auth';
import { db } from '@/lib/db';
import { notFound } from 'next/navigation';
import { DashboardView } from './_components/dashboard-view';
export default async function DashboardPage() {
// Runs on the server. Never ships to the client.
const session = await auth();
if (!session) return notFound();
const user = await db.query.users.findFirst({
where: (u, { eq }) => eq(u.id, session.userId),
with: { accounts: true },
});
if (!user) return notFound();
return <DashboardView user={user} />;
}
17 lines. Authenticated. Type-safe database query via Drizzle. Graceful not-found. Zero client JavaScript for the data fetch. Zero loading spinner because Server Components don't need one. This is the baseline — not a highlight reel.
Five anti-patterns we refuse.
Five briefs we push back on: micro-frontends on a single product, GraphQL when REST or tRPC would do, custom CMS for a 20-page marketing site, NoSQL without a reason (Postgres handles 99% of web-app workloads), and Redux in 2026. These appear in briefs from smart teams regularly; we'll talk through each one against the agent-ready references on GitHub's developer docs before scoping anything.
-
1.
Micro-frontends on a single product.
You have 20 engineers and one product. Module Federation adds weeks of infrastructure for a decoupling benefit you won't feel until you hit 200. Build a monorepo with clean module boundaries; we'll tell you when micro-frontends start paying.
-
2.
GraphQL when REST or tRPC would do.
GraphQL pays for itself when the client and server teams are separate and data needs differ wildly across consumers. If it's one frontend hitting one backend, tRPC ships end-to-end types with a tenth of the ceremony. We'll stand up GraphQL if it's genuinely warranted; we'll tell you when it's not.
-
3.
Custom CMS for a 20-page marketing site.
Sanity, Contentful, and Payload solve the problem in a week. A custom admin panel solves the same problem in three months and then requires ongoing engineering to keep alive. If your content team is two people, buy the CMS.
-
4.
NoSQL without a reason.
MongoDB is not a default. Postgres handles 99% of web-app workloads, gives you SQL, transactions, real joins, row-level security, and a hiring pool twenty times deeper. Pick NoSQL when the access pattern genuinely demands it — rarely.
-
5.
Redux in 2026.
React Query handles server state. Zustand handles the tiny slice of client state you actually have. Redux was a reasonable answer in 2017 to problems the ecosystem has since solved better. If we inherit a codebase with Redux, we don't rip it out — but we don't add to it either.
Four shapes of engagement.
Four engagement shapes, each with a fixed scope: a 2-week performance rescue (CWV remediation), a 2-4 week single-page build, a 6-8 week marketing or product site (5-15 pages with CMS), or a 10-20 week custom web app on Vercel or AWS. We send a fixed-price quote within 48 hours of the intro call. Scope moves price; discovery doesn't.
Performance rescue
2-week Core Web Vitals remediation. Audit, bundle tuning, image pipeline, server optimization, rendering strategy review. Fixed fee.
Single-page build
Conversion-focused landing or single-page. Next.js or Astro, TypeScript, analytics, full CWV contract. 2–4 weeks.
Marketing or product site
5–15 pages. Headless CMS, design system wiring, i18n, schema, editorial workflows. 6–8 weeks.
Custom web app
Auth, dashboards, workflows, integrations, real-time, billing. Next.js + Node or full-stack TypeScript. 10–20 weeks.
Every engagement is scoped to a fixed price before kickoff. Scope changes get re-quoted before they happen, not after.
Six answers.
Direct answers on what a web development company does, pricing, framework choice, CWV targets, rebuilds, and embedded-team shapes. For agent-readable structure see schema.org WebPage.
What does a web development company actually do?
A custom web development company engineers sites and web applications end-to-end: architecture, backend APIs, database schema, frontend framework, rendering, auth, integrations, CI/CD, deployment, and post-launch optimization. At Digital Heroes, every engagement commits to a Core Web Vitals contract (LCP < 2.5s, INP < 200ms, CLS < 0.1) before the first invoice. Miss the target, the launch sprint is refunded.
How much does custom web development cost?
Cost tracks scope, not a list price. The variables are page count, whether it's a marketing site or a custom application (auth, dashboards, real-time, billing), CMS depth, integrations, and hosting target. A performance rescue is a 2-week engagement, a single-page build runs 2-4 weeks, a marketing or product site runs 6-8 weeks, and a custom web app runs 10-20 weeks. We scope your specific build on a 30-minute intro call and send a fixed-price, week-by-week quote within 48 hours. Scope moves price; discovery doesn't.
Which web framework should I use in 2026?
Follow the problem, not a favorite. Next.js 16 for content-plus-app sites. Astro for content-heavy where JS should be zero. Remix for form-heavy data-forward apps. SvelteKit for small teams valuing ergonomics. See the decision matrix in § 02 above.
Do you publish Core Web Vitals targets?
Yes, and contractual. LCP < 2.5s, INP < 200ms, CLS < 0.1, verified on throttled Moto G4 via PageSpeed Insights field data. If the launch build misses any of the three, the launch sprint is refunded at the client's option.
Can you rebuild our existing site?
Yes. Rebuild starts with a technical audit (dependencies, rendering strategy, bundle size, queries, CMS friction, CI/CD maturity). We publish the audit before we touch code. Rebuilds typically run 6–12 weeks with preserved URLs, 301 redirects, and Search Console address change. Rankings are almost always preserved.
Will you work with our existing engineering team?
Yes. Three shapes: white-label (we ship, your team brands), embedded (our engineers in your sprints, 3-month minimum), handoff (we build, you maintain). Code quality and documentation are the same across all three — we assume your team will read every line.
What changed in the React stack.
Four shifts pulled the web development floor up in 2026: Next.js 15 plus React 19 made React Server Components the default mental model, Edge runtimes moved from experimental to production for most workloads, the bundler conversation split into three credible camps (Turbopack, Rspack, Vite), and INP enforcement made client-bundle weight a CWV problem, not just a developer-experience one.
The two specs that anchor a credible 2026 build are public. Next.js's Server Components docs walk the streaming, suspense, and data-fetching model that ships under 50 KB of JavaScript to most pages; React's Server Components reference documents the boundary between server and client work in plain terms. A 2026 stack pick that does not at least defend its position against RSC is working from a 2022 architecture.
Edge runtimes matured fast. Vercel's edge region map and the runtime caveats (no Node-API, smaller bundle, region-pinned data) are now mainstream knowledge; on the edtech course platform build, moving auth and the marketing pages to the edge dropped TTFB by 60 percent for users outside North America, with no change to the data layer. The trade-off is real (Node-only libraries do not run on edge) and the call is now per-route, not per-app.
What this means for your project: in 2026, default to Next.js 15 plus React Server Components for content-driven sites and SaaS marketing surfaces, keep Remix and Astro on the shortlist for content-heavy and largely-static work, and budget client-bundle weight as a hard constraint, not a nice-to-have. INP is now part of the contract.
Related reading + work: See our React versus Next.js for SaaS breakdown, the Shopify image optimization playbook (CWV-applicable to any stack), the edtech course platform case, and our SaaS development and Shopify development pages for adjacent work.
Start with a metric.
Tell us the number that's broken — conversion, TTFB, bounce rate, user-reported latency. We'll come back with an architecture, a stack, a performance contract, and a price. Within 24 hours. No discovery calls.
Published · Last updated .