03 · Technology
Applications in the browser, built as software.
Your customers or staff need to do something on your site, not just read it: get a quote, work out how much they need, check an order or manage an account. A brochure site can survive being thrown together; a web application cannot. Once there are user accounts, data that has to stay consistent and interactions that should feel instant, building it like a website shows up as bugs, slowness and a codebase nobody wants to touch. We build web applications as software from day one, with performance budgets and accessibility designed in. This service covers the application people use in the browser. When the job is a whole platform, a SaaS product or the backend behind it, see software development.
What you walk away with
- A state and data architecture that keeps the interface consistent and predictable as it grows.
- Authentication, roles and permissions done correctly.
- A typed, versioned, documented API layer between the interface and your data.
- A performance budget enforced in the build, not hoped for.
- Keyboard, screen-reader and contrast correctness built in during development.
- Error tracking and logging, so you find problems before your users report them.
What it covers
- State and data architecture
- Client and server state designed deliberately, so the interface stays consistent instead of drifting into a tangle of edge cases.
- Auth, roles and multi-tenancy
- Authentication and authorization done correctly: the part that is invisible when it works and catastrophic when it does not.
- Designed APIs
- Typed, versioned, documented API layers: the contract between your interface and your data, engineered as software rather than improvised endpoint by endpoint.
- Performance budgets
- Core Web Vitals and interaction latency treated as build-time constraints, so interactions stay instant as features accumulate.
- Accessibility, engineered in
- Semantics, keyboard support, screen-reader behavior and contrast built during development, not retrofitted after a compliance scare.
- Calculators, estimators and quote builders
- Self-serve tools that answer the question a customer would otherwise phone in, built and unit-tested like any other software so the numbers stay right.
- Installable and offline-capable
- Progressive web app features, such as installing to a home screen and an offline page, for tools customers come back to.
- Observability
- Error tracking, logging and the instrumentation that catches regressions early.
Proof you can inspect
Roseville Landscape Material Supply is the clearest public example. Its site runs a materials calculator in the browser, with rectangle, triangle and circle modes that return cubic yards, square feet and tonnage. Alongside it, a Material Estimator adds a waste buffer and checks the price, and an Order Builder turns a multi-material job into a materials list the customer sends to the yard as a request, with no payment online. Calculate, estimate, then ask: each step answers a question that used to arrive by phone.
Roseville Star Ready Mix, a ready-mix concrete delivery company, is the other. When we refactored its Astro site, its concrete calculator was kept and put under unit tests, and the site became an installable progressive web app with an offline page. Removing React cut client-side JavaScript from about 230 KB to 5.5 KB, per our build report, without losing the tool customers use.
The rule we work by: if a tool changes what a customer does next, it is software, and it gets tested like software.
How the work runs
Every engagement moves through the same five stages, with one team throughout.
Understand
A first conversation and a look at what already exists: your position, your customers’ path, your traffic and your technology.
Define
Positioning, scope and architecture decided deliberately and written down, so everyone knows what is being built and why.
Design
Brand, content and interface designed together, against those decisions rather than the fashion of the month.
Build
Built with speed, accessibility and security as requirements, and reviewed on a staging site before anything goes live.
Improve
Launch is the start. We measure what matters, fix what drifts and report in plain language.
Further reading
- Astro vs Next.js: Which Framework for a Marketing Site in 2026?Astro vs Next.js for a content or marketing site: how they differ on performance, complexity and cost, and a clear rule for choosing between them.
- INP Optimization: How to Fix Interaction to Next PaintWhat a good Interaction to Next Paint score is, why sites fail it, and the concrete fixes that bring INP under 200 milliseconds for real users.
- B2B SaaS Marketing Infrastructure on WordPressHow B2B software teams can run marketing on headless WordPress: one domain, a content workflow marketers own, and attribution that survives to the CRM.
- Website Accessibility: A Plain-English WCAG & ADA GuideWhat web accessibility requires, where the law stands in late 2026, and the WCAG 2.2 AA failures worth fixing first, explained without jargon.
Web applications: common questions
What's the difference between a website and a web application?
A website presents content; a web application does work: real state, accounts, data that must stay consistent and interactions that have to feel instant. We engineer the second category as software, because building it like a website is exactly where teams get hurt. If your project is mostly pages people read, website development is the better fit.
How is this different from your software development service?
This service is about the application people use in the browser: its state, its accessibility, its speed and the API it talks to. Software development covers the whole system behind it, including internal platforms, SaaS products, integrations and backends. Plenty of projects need both, and the same team does both.
Do you use React for everything?
No. We add interactivity where it earns its place and keep the rest static and fast. Astro lets us ship mostly static pages with islands of rich interactivity, which is often the right architecture for a fast web app. We choose per surface, not per dogma.
How do you keep web apps fast as they grow?
Performance budgets enforced in the build, careful state and data architecture, and instrumentation so regressions are caught early. Staying fast is a discipline maintained over time, not a one-time tuning pass.
Can you take over an existing web app?
Yes. When we inherit an application that has become slow or fragile, we stabilize it first and then move it forward. You get a written assessment of whether to refactor or rebuild before either of us commits. Tell us what you're building and what is going wrong with it.