Web Development Services | Modern Web Applications | Nordbeam

We have opinions about how web applications should be built, and we're not afraid to share them.

React won. After building dozens of production applications, trying every framework that came along, we've settled on React as our default. Not because it's perfect—it has quirks and sharp edges—but because the ecosystem is mature, the talent pool is deep, and the framework is stable without being stagnant.

TypeScript is non-negotiable. Every project, no exceptions. The upfront investment in type safety pays dividends when you're maintaining the codebase two years later. We've never had a client regret using TypeScript.

And performance isn't optional. The web has gotten slower as JavaScript bundles have grown. We push against that—every application we build loads fast, scores well on Core Web Vitals, and doesn't make users wait.

The Framework Decision

The framework choice matters more than most teams realize. It affects performance, developer productivity, hiring, and long-term maintainability. Here's how we think about it:

Next.js for most applications. Server-side rendering for SEO and initial load performance. File-based routing that stays out of your way. Incremental adoption that lets you start simple and add complexity as needed. Server Components in React 19 are genuinely exciting and Next.js supports them well.

TanStack Start when you need more control. Next.js makes decisions for you—usually good decisions, but sometimes you need different ones. TanStack Start gives you the primitives without the opinions. We use it when clients have unusual requirements or existing infrastructure that doesn't fit the Next.js model.

Static site generators for content sites. If your site is primarily content—a blog, documentation, marketing pages—static generation is faster to build, cheaper to host, and more secure. We still use React for the components, but we don't need a server running.

The wrong choice isn't catastrophic, but the right choice saves months of fighting the framework.

What We Actually Build

SaaS Dashboards and Admin Panels

Complex data visualization, real-time updates, multi-tenant architecture. The applications that users spend hours in every day.

For a logistics company, we built a real-time fleet management dashboard. Thousands of data points updating every few seconds, complex filtering and search, export functionality, role-based access control. The challenge wasn't just making it work—it was making it work smoothly, without the interface lagging as data changed.

These applications need careful attention to state management, data fetching patterns, and perceived performance. A loading spinner that appears for 200ms every time you filter data breaks the flow. We optimize for the experience of heavy use, not just first impressions.

Customer-Facing Platforms

E-commerce sites, customer portals, self-service platforms. Applications where performance directly affects revenue.

When we rebuilt the frontend for HSE24, Germany's largest home shopping network, page load time was directly correlated with conversion. A faster site meant more sales. We reduced load times by 45% and saw a 28% increase in conversions—the investment paid for itself many times over.

These projects require understanding how real users behave. What pages do they hit first? Where do they drop off? What's the mobile experience like on 3G? We instrument everything and optimize based on real data.

Content and Documentation Sites

Blogs, documentation, marketing sites. The content-driven applications that don't need full application complexity but do need excellent performance and SEO.

For developer tools companies, we build documentation sites that are fast, searchable, and pleasant to use. For content businesses, we build publishing platforms that editors love and readers engage with.

The pattern: static generation for most pages, dynamic rendering only where needed, and an authoring experience that doesn't require engineering help for every update.

The Technology Stack

We're opinionated about technology, and we're happy to explain why.

React over Vue or Angular. The ecosystem is larger, the talent pool is deeper, and the framework is stable without being stagnant. Vue is fine. Angular has its place in enterprise. But React has the broadest community and the most mature tooling.

TypeScript everywhere. The productivity cost is minimal—mostly learning the type system if you haven't—and the bug prevention is substantial. When the codebase grows, when you're refactoring, when you're integrating with APIs, TypeScript catches errors before they reach production.

Tailwind for styling. Controversial take: CSS-in-JS was a mistake for most applications. Tailwind gives you the composability without the runtime cost. Yes, the HTML looks busy at first. You get used to it, and the result is consistent, maintainable styling without fighting specificity wars.

PostgreSQL by default. It handles 95% of use cases well. We reach for specialized databases when there's a specific need—Redis for caching, Elasticsearch for search, ClickHouse for analytics—but PostgreSQL is a remarkably capable default.

Performance as a Feature

We track Core Web Vitals on every project. Not as a checkbox, but as a core deliverable.

Largest Contentful Paint (LCP) should be under 2.5 seconds—we target under 1.5. This means optimizing images, fonts, and initial render paths. Server-side rendering helps here, but only if you're not blocking on slow API calls.

First Input Delay (FID) and Interaction to Next Paint (INP) measure responsiveness. Heavy JavaScript bundles kill this. We're aggressive about code splitting, lazy loading, and minimizing main-thread work.

Cumulative Layout Shift (CLS) catches the annoying experience of content jumping around as the page loads. We reserve space for images, fonts, and dynamic content to avoid shifts.

These metrics correlate with business outcomes. Faster sites convert better. They rank higher. Users engage more. The investment in performance pays off.

Accessibility Is Not Optional

We build applications that work for everyone. Not as an afterthought, not as a checkbox for compliance, but as a core part of how we develop.

WCAG 2.1 AA compliance is our baseline. Semantic HTML. Keyboard navigation. Screen reader compatibility. Sufficient color contrast. Proper focus management. These things are easier to build in from the start than to retrofit later.

The accessibility audit shouldn't be the first time someone tests your application with a screen reader. We test throughout development, catch issues early, and build accessible patterns into our component libraries.

How We Work

We Don't Do Handoffs

You talk directly to the engineers building your application. Not to project managers who relay messages, not to account executives who promise things the team can't deliver. The person you meet in the first call is the person writing your code.

This matters because software development is fundamentally about understanding problems, and understanding degrades with every handoff.

We Push Back

If you ask us to build something we think is wrong, we'll tell you. Not because we're difficult—because you're paying us for our expertise, not just our keyboards.

We've built enough applications to recognize patterns: the feature that sounds essential but users will ignore, the architecture that seems simpler but will break at scale, the shortcut that saves a week now but costs a month later.

We Stay Until It's Working

Launch isn't the finish line. The first week after launch teaches you more about your application than the three months before it. Users find edge cases you didn't anticipate. Performance issues emerge at real scale. Monitoring reveals problems your test environment hid.

We stick around for this phase—because getting software stable in production is as important as building it in the first place.

Development Patterns That Work

Component Architecture

We build design systems, not page-by-page implementations. A library of reusable components—buttons, forms, cards, modals—that ensures consistency and speeds development.

Each component is tested in isolation. Props are typed with TypeScript. Variants are documented in Storybook. When the design team updates a button style, it updates everywhere the button is used.

The initial investment in component architecture pays off quickly. After the first few pages, development accelerates because you're composing existing components rather than building from scratch. And consistency comes automatically rather than requiring manual enforcement.

State Management Philosophy

State management in React has been overcomplicated. We've used Redux, MobX, Zustand, Jotai, and others. Here's what we've learned:

Server state belongs in TanStack Query (or similar). Data fetched from APIs, cached responses, optimistic updates—this is a solved problem. Don't reinvent it.

Local UI state belongs in React state. Whether a modal is open, which tab is selected, what the user is typing—useState and useReducer handle this fine.

Global application state—the data that doesn't fit in either category—is rarer than you'd think. Zustand handles it simply when you need it.

The mistake is reaching for heavy state management frameworks before you've proven you need them. Start simple. Add complexity only when simpler solutions fail.

Data Fetching Patterns

Data fetching is where many applications get complicated. Caching, refetching, loading states, error handling, pagination, optimistic updates—each adds complexity.

TanStack Query solves most of these problems out of the box. We use it on every project with server data. The cache invalidation model is sensible. The stale-while-revalidate pattern provides good UX. The devtools help debugging.

For static data, we prefer building at build-time. The content doesn't change often enough to justify server requests. Pages load faster when content is already there.

For real-time data, we use WebSockets or Server-Sent Events depending on the use case. WebSockets for bidirectional communication. SSE when you only need server-to-client updates—it's simpler and works better with HTTP/2.

Form Handling

Forms are the most common UI pattern and the easiest to get wrong. Validation, error handling, submission, loading states—each form reimplements the same patterns.

We use react-hook-form for most forms. It's performant (doesn't re-render on every keystroke), integrates well with Zod for validation, and handles the edge cases (array fields, dependent validation, file uploads).

For simple forms, native form handling with server actions is increasingly viable. Next.js server actions and progressive enhancement work well for forms that don't need client-side interactivity.

The goal is consistent form behavior across the application. Every form should handle errors the same way, show loading states the same way, and validate in the same patterns.

Testing Strategy

What We Test

We're pragmatic about testing. Testing everything isn't valuable. Testing nothing isn't wise. We focus effort where it matters.

Critical business logic gets comprehensive unit tests. The function that calculates pricing, the validation that determines user permissions—these can't be wrong.

Integration tests cover user flows. Can a user sign up, complete onboarding, and accomplish the core task? If these tests pass, the application works.

Visual regression testing catches unintended UI changes. Screenshot comparisons flag when components look different than expected.

End-to-end tests are expensive to maintain. We use them sparingly—for the most critical flows, run against staging before production deploys.

What We Skip

We don't test implementation details. A test that verifies a function was called with specific arguments breaks when you refactor, even if behavior is unchanged. We test behavior, not implementation.

We don't aim for 100% coverage. Past a certain point, additional coverage tests things that don't matter while making the test suite slower and harder to maintain.

We don't test what frameworks already test. React's event handling works. TypeScript's type checking works. We don't need to verify this.

Security Practices

Authentication and Authorization

Authentication—verifying identity—uses battle-tested libraries (Auth.js, Clerk) rather than custom implementations. Session management, token refresh, multi-factor authentication—these have subtle security implications that specialized tools handle better.

Authorization—controlling access—needs careful implementation. Role-based access control as a baseline. Row-level security in the database for multi-tenant applications. Consistent authorization checks on every endpoint, not just the obvious ones.

Input Validation

All input is untrusted. User input, API responses, URL parameters—validated before use. Zod schemas define what's expected. Invalid input is rejected rather than coerced.

SQL injection, XSS, CSRF—these attacks still work on applications that don't validate. Modern frameworks help, but they're not automatic. We validate explicitly.

Dependency Security

npm packages introduce risk. We audit dependencies with npm audit and Snyk. Unused packages get removed. Major dependencies are monitored for vulnerabilities.

Updates happen regularly, not when something breaks. Security patches applied promptly. Major version updates evaluated and scheduled. The alternative—running years-old dependencies—is how breaches happen.

Deployment and Infrastructure

Web applications need infrastructure that's reliable, fast, and cost-effective. We've deployed to every major platform and have opinions about when each makes sense.

Vercel for Next.js

Vercel is built for Next.js—unsurprising since they make both. Deployment is push-to-deploy. Preview environments for every pull request. Edge functions for personalization. The developer experience is excellent.

For most Next.js applications, Vercel is the right choice. The cost scales reasonably for moderate traffic. The infrastructure handles spikes automatically. We focus on building features rather than managing servers.

The limitations appear at scale or for unusual requirements. Very high traffic gets expensive. Custom infrastructure needs (GPUs, persistent storage) aren't supported. Some enterprises have procurement restrictions.

Cloudflare Workers

For edge-first applications, Cloudflare Workers offer remarkable performance. Code runs in 300+ locations worldwide, eliminating geographic latency. Cold starts are milliseconds, not seconds.

We use Workers for applications where global performance matters: marketing sites serving international audiences, APIs that need low latency everywhere, applications doing real-time personalization at the edge.

Workers have constraints: limited runtime features, no native database access, execution time limits. We design for these constraints, keeping edge code lean and delegating heavy operations to backend services.

AWS and Traditional Infrastructure

For complex applications—those with background processing, specific compliance requirements, or unusual infrastructure needs—AWS or GCP provide full control.

We deploy with infrastructure as code (Terraform, Pulumi) so everything is reproducible. Staging environments mirror production. Disaster recovery is tested, not theoretical. The infrastructure complexity matches the application complexity—we don't build AWS architectures for applications that belong on Vercel.

CDN and Caching Strategy

Static assets belong on CDNs. Images, JavaScript bundles, fonts—these should load from servers close to users. We configure CDN caching aggressively for immutable assets, carefully for dynamic content.

Dynamic caching is trickier. What can be cached? For how long? How do you invalidate? We design caching strategies that improve performance without serving stale data. Edge caching for personalized content requires careful implementation.

Monitoring and Observability

Production applications need visibility. What's happening right now? Is performance degrading? Are users experiencing errors?

We implement observability from day one: application performance monitoring (APM), error tracking, log aggregation, and custom metrics. Alerts notify us of problems before users report them. Dashboards show system health at a glance.

Post-incident analysis drives improvement. When something goes wrong, we understand why and implement prevention. The goal is that each incident type happens once, not repeatedly.

International and Localization

Web applications serving multiple markets need thoughtful internationalization architecture.

Content Localization

Translating strings is the obvious part. But localization extends further: date formats, number formats, currency display, address formats. RTL support for Arabic and Hebrew. Pluralization rules that differ by language.

We use established i18n libraries (react-intl, next-intl) rather than building custom solutions. These handle the edge cases—Arabic pluralization has six forms, not two—that custom implementations miss.

URL Structure for SEO

Search engines prefer hreflang tags and proper URL structures for multi-language content. /en/products and /de/products, with hreflang links connecting them. Getting this wrong means competing with yourself in search results.

We implement language routing at the framework level, ensuring consistent URL patterns and proper SEO metadata. Language detection on first visit with user preference persistence.

Performance Across Regions

Users in Australia shouldn't wait 500ms for JavaScript bundles from US servers. CDN distribution helps for static assets. For dynamic content, we consider regional API endpoints or edge computing.

Real User Monitoring (RUM) by geography reveals where performance problems hide. An application fast in Europe might be slow in Asia. We measure and optimize for actual user distribution.

Frequently Asked Questions

Related Services