Skip to content

Software Engineering

Web Application Development

Not a brochure site. The dashboards, portals and internal systems your business runs on — architected by senior engineers to be maintained and evolved for years, not just launched.

Overview

There is a real difference between a website and a web application, and conflating the two is how projects go wrong. A website presents content — pages a visitor reads and leaves. A web application is a piece of software that runs in the browser: it holds state, enforces who can do what, moves data back and forth with a back end, and does real work on behalf of the person using it. A dashboard, an internal admin tool, a customer portal, a booking or claims or approvals system — these are applications. They justify a proper framework and genuine engineering in a way a five-page marketing site never does.

That distinction matters because it changes what the job actually is. The hard parts of a web application are rarely the screens you can see in a design file. They are the application’s state — what is loaded, what is stale, what is optimistic, what happens when two people edit the same record — and the authorisation rules that decide, on every request, whether this particular user is allowed to do this particular thing. Get those wrong and no amount of visual polish saves you. Most of our work on these systems is in that invisible layer.

We build the whole thing: a React and Next.js front end in TypeScript for the interface, a real back end and API behind it, and a database — usually PostgreSQL — underneath. But the stack is chosen for the problem, not the other way round. What does not change is the intent. These systems are not launched and abandoned; they are used every day, extended, corrected and grown for years. We architect them so that the version you have in three years is still one your own engineers can reason about and change safely — which is a decision made at the start, not a hope you have at the end.

Who it’s for — Organisations that need a genuine web application — stateful, multi-user, data-dense — rather than a marketing website, and who intend to run it for years.

What you get

  • A React and Next.js front end in TypeScript with a considered state model, not a pile of ad-hoc component state
  • A real back end and API — authenticated, authorised and validated at the boundary, not just in the UI
  • A relational schema (typically PostgreSQL) designed around your data and its invariants, with migrations from day one
  • Authentication and role-based access control enforced on the server, where it actually protects anything
  • Data-dense interfaces — tables, filters, forms and multi-step flows — that stay fast and usable as records grow into the millions
  • Automated tests, monitoring and error tracking shipped with the application, not promised later
  • Documentation and a codebase your own team can pick up and extend after handover

What Web Application Development does for you

  • Software shaped to your work

    A web application built around how your organisation actually operates — the workflows, roles and rules that off-the-shelf tools force you to work around.

  • Performance that survives real data

    Interfaces engineered to stay responsive as records grow from hundreds to millions, because the pagination, indexing and query design were considered up front rather than patched after the first slowdown.

  • A lower total cost over its life

    Most of what a long-lived application costs is spent after launch, changing it. A clean architecture and a real test suite make those changes cheap and safe, which is where the saving actually lives.

Why teams choose us for Web Application Development

  • Senior engineers architect and build the system — the people in your kickoff are the people on the commits, not juniors handed the work after the sale
  • We are candid about the website-versus-application distinction: if a simpler build genuinely serves you, we will say so rather than sell you a framework you do not need
  • The application ships in your accounts and repositories, with no proprietary layer you must keep paying us to operate
  • We build for the maintenance years, not just the launch — tests, migrations, monitoring and documentation are part of the deliverable, not extras

What Web Application Development includes

The concrete pieces of work this covers — scoped to what your problem actually needs.

  • Application state management

    Deciding what state lives where — server, client, URL, cache — and handling the awkward cases: stale data, optimistic updates, concurrent edits and keeping the interface honest about what is actually loaded.

  • Authentication and authorisation

    Sessions, roles and permissions enforced on the server. Role-based and, where needed, resource-level access control, so a user can only ever see and touch what they are entitled to.

  • Data-dense interfaces

    Tables, filters, search, bulk actions, forms with real validation and multi-step flows — the interfaces that carry actual work, built to stay fast and legible under load.

  • Back-end and API design

    The API and business logic behind the interface, with validation and authorisation at the boundary, designed so the front end is never the only thing standing between a user and your data.

  • Relational data modelling

    A PostgreSQL schema designed around your entities and their invariants, with constraints in the database, indexing for the queries you actually run, and migrations tracked from the first commit.

  • Real-time and multi-user features

    Live updates, notifications and collaborative behaviour where the product needs them — implemented deliberately, because real-time is a source of subtle bugs when it is bolted on late.

Where it fits

  • Internal operations tool

    Replacing the critical spreadsheet or ageing internal system a team depends on with a proper application — roles, audit trail, validation and the workflows the business actually runs, so the process stops living in one person’s head.

  • Customer or partner portal

    A secure, authenticated space where your customers or partners see their own data and act on it — accounts, permissions and a clean separation between what each party is allowed to reach.

  • Analytics and operations dashboard

    A data-dense dashboard pulling from your systems in near real time, with filtering, drill-down and performance that holds up when the underlying data is large and the questions are ad hoc.

  • Workflow and approvals system

    A multi-step, multi-role process — submissions moving through review, approval and action — with state that is always correct about where each item is and who may move it next.

How we approach Web Application Development

We decide the architecture before we build the screens, because in an application the screens are the cheap part. The costly, hard-to-reverse decisions are the data model, the authorisation model and how the application manages state — and those get designed, written down and defended in the first couple of weeks, before there is a pile of feature code that assumes them. This is the opposite of starting with a component library and discovering the data model by accident.

From there we build in short, reviewable cycles against working software, so you steer off the real application rather than a specification of it. Every cycle ships something you can click. And every cycle carries its own tests and observability, because in a system people depend on daily, "it works on my machine" is not a state you can hand over.

How we build it

We open with a short, deliberate design phase that settles the decisions that are expensive to change: the data model, the authorisation model, the boundaries between front end and back end, and how the application will manage state. These get written down and agreed before feature work starts, because retrofitting a data model into an application that already assumes the wrong one is one of the most costly mistakes in this kind of work.

Delivery then runs in short cycles against working software. Each cycle takes a real slice of the application — a screen and the API and schema behind it — through to something you can use and review, rather than delivering a front end that is waiting on a back end that never quite arrives. You see progress in the product and can redirect while it is still cheap to.

Every cycle ships with its own tests, error tracking and monitoring, and every schema change is a tracked migration. At handover you receive not just a running application but the means to keep running it: documentation, a test suite that tells you when something breaks, and a codebase written to be read by whoever maintains it next — which may well be you.

Architecture: the app tier, the data tier and state

A web application has three concerns worth naming separately. The app tier is the front end and the API it talks to — the React and Next.js interface and the server-side logic behind it. The data tier is the database and how the application reads and writes it. And cutting across both is state: the single hardest thing to get right, because it is the question of what is true, where that truth lives, and how the interface stays consistent with it while several people act at once.

In the app tier we are deliberate about where each piece of state belongs. Server state — data that lives in the database and is merely borrowed by the browser — is treated differently from genuine client state like what a user has typed but not yet saved. Conflating the two is the root of a large share of application bugs: interfaces that show stale data, that lose edits, or that disagree with the database about what actually happened. We keep that boundary clear so the interface can always be trusted.

The data tier is a relational database, usually PostgreSQL, with the schema modelled around your real entities and the rules that must always hold true — enforced with constraints in the database itself, not merely hoped for in application code. Indexes are chosen for the queries the application genuinely runs, and heavy analytical work is kept off the path that serves interactive users. The stack is chosen per problem, but the principle does not move: the database is the system of record, and it should protect its own integrity rather than depend on every caller to behave.

Security: authentication, access control and business data

In an application the security question is not "is the site up to date" but "can this specific user do this specific thing to this specific record". That is authorisation, and it has to be answered on the server, on every request. A permission check that lives only in the front end — a hidden button, a greyed-out menu — protects nothing, because the API is reachable directly. We enforce access control at the API boundary, where it is the actual gate, and treat the UI’s version of it as a convenience rather than a defence.

Authentication establishes who someone is: sessions handled properly, credentials never stored in a form we would be embarrassed by, and sensible defaults around session lifetime and revocation. Authorisation then decides what that identity may do — role-based access as a baseline, and resource-level checks where a user should only reach their own records and not a neighbour’s. These rules are written once, centrally, so they cannot drift apart across dozens of endpoints.

The rest is the discipline that keeps business data safe under real use: input validated and queries parameterised so untrusted data cannot become a command, output handled so it cannot become script in someone else’s browser, secrets kept out of the codebase, and dependencies watched for known vulnerabilities. Sensitive actions leave an audit trail. None of this is bolted on before a review — it is how the application is built from the first endpoint, because security added late only ever protects the flaws you already shipped.

Signs it’s time

  • You are being quoted for a "website" but what you actually need holds logins, roles and live data — it is an application in disguise
  • A tool your team relies on lives in a sprawling spreadsheet that has hit its limit and become dangerous to change
  • An existing web app has grown slow, buggy or frightening to touch, and every new feature breaks two old ones
  • You need real-time or multi-user behaviour — dashboards, notifications, collaborative editing — that a static site cannot provide

How we work with you

We work in the open, embedded in your tooling — your repository, your issue tracker, your review process — so the application’s progress is something you watch rather than something you are told about in a status meeting. Short cycles end in working software you can click through, which is a far better basis for a decision than a written specification of what the software might one day do.

Because these systems are long-lived, we optimise for the engineer who comes after us — often your own team. That means a codebase written to be read, a data model that is documented and defensible, and the honest conversation about trade-offs as they come up: what we are choosing, what it costs, and what we are deliberately not doing yet. You should never inherit a system whose decisions nobody can explain.

Technologies we build it with

Chosen per problem, not per fashion — this is the stack we most often reach for on this work.

How we deliver

  1. 01

    Discover

    We map the system, the constraints and the business it serves — including the parts nobody documented.

    Architecture brief

  2. 02

    Architect

    Decisions get made, written down and defended before a line of production code exists.

    Decision records

  3. 03

    Build

    Short cycles against working software. You see progress in the product, not in a status deck.

    Shipping increments

  4. 04

    Operate

    Monitoring, incident response and iteration. The system is alive, so the engagement is too.

    Runbooks & SLOs

What changes

  • State you can trust

    An application whose data on screen is correct, current and consistent — even with many users acting at once.

  • Access properly enforced

    Roles and permissions checked on the server on every request, so business data is protected where it counts.

  • Maintainable for years

    A codebase and architecture your own engineers can extend safely long after we have handed it over.

Industries we serve

Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.

How pricing works

  • Cost is driven far more by the complexity of the application than by the number of screens. The real drivers are how intricate the workflows and permission rules are, how much the state has to do (real-time, collaboration, offline behaviour all cost more), and how many other systems the application must integrate with.
  • The state of your data matters too. A clean, well-understood data model is quick to build on; migrating messy or scattered data into a coherent schema, or reverse-engineering an undocumented existing system, is real work that has to be scoped honestly rather than assumed away.
  • We can work to a fixed scope for a well-defined build, or on a time-and-materials basis where the roadmap is genuinely open and you want to steer as it takes shape. Either way we would rather agree a smaller, clearly-defined first phase and prove the working relationship than quote a large fixed number against requirements neither of us fully understands yet.
  • Whichever model fits, the application is built in your accounts and belongs to you. There is no ongoing licence to us baked into the price — any continuing arrangement is a support choice you make, not a dependency we design in.

Typical timeline

  1. 01

    Architecture and design

    A short, intensive phase settling the data model, authorisation model, state strategy and system boundaries — the decisions that are cheap now and expensive later. Typically one to three weeks depending on complexity.

  2. 02

    First working slice

    A thin but complete vertical — a real screen with its API and schema behind it, authentication working — so the architecture is proven end to end early rather than assembled all at once at the finish.

  3. 03

    Iterative build

    The bulk of delivery, feature by feature in reviewable cycles, each shipping with its tests and monitoring. You steer against working software throughout and can reprioritise as the picture sharpens.

  4. 04

    Hardening and handover

    Performance under realistic data, security review, documentation and a clean handover — so your team inherits an application they can operate and extend, not a black box.

Why teams choose us for Web Application Development

  • We operate what we build

    We build these applications knowing we may run them, which changes the decisions — towards observability, sane migrations and code that can be debugged at three in the morning rather than towards whatever demos fastest.

  • Senior engineers, throughout

    The architecture of a stateful application is where seniority actually pays. You get engineers who have maintained systems like this for years and know where they rot, not a senior pitch followed by a junior build.

  • Honest about what you need

    If your problem is really a website and not an application, we will tell you and save you the cost of engineering you do not need. We only reach for the heavier tools when the problem earns them.

  • Built for the long run

    We treat the maintenance years as the point, not an afterthought — because an application you cannot safely change in three years has failed, however good its launch looked.

How to engage us

Three ways to work with us on this — chosen to fit the problem, not our margin.

Related services

Part of Custom Software Development. Other work we do alongside this.

Common questions

What is the difference between a web application and a website, and why does it change the price?

A website presents content you read; a web application is software that holds state, enforces who can do what, and does real work through a back end and database. The application is far more engineering — authorisation, data modelling, state management, testing — which is why it costs more and why it justifies a proper framework. If your need is genuinely a content site, we will say so rather than sell you an application you do not need.

Can you take over an existing web application that has become slow or fragile?

Yes, and a good share of our work is exactly this. We start by making the system legible — understanding the data model, the state handling and where the fragility actually lives — before changing anything. From there we stabilise and improve deliberately, usually in place while the application keeps running, rather than proposing a risky big-bang rewrite as the reflex answer.

Which technology stack do you use?

Typically React and Next.js in TypeScript on the front end, a real back-end API, and PostgreSQL for data — but the stack is chosen for the problem, not applied as a default. What does not vary is the intent behind it: a considered state model, authorisation enforced on the server, a data model that protects its own integrity, and a codebase written to be maintained for years.

How do you make sure the application stays fast as our data grows?

Performance is designed in, not patched after the first slowdown. That means pagination and filtering that never load more than they need, database indexes chosen for the queries the application actually runs, heavy analytical work kept off the interactive path, and testing against realistic data volumes rather than the handful of rows that exist on day one. Interfaces that are fast with a hundred records and unusable with a million are a design failure, not bad luck.

What happens after launch — are we locked into you to maintain it?

No. The application is built in your accounts and repositories and belongs to you, and we hand over documentation, a test suite and a codebase written to be read, so your own engineers can extend it. If you want us to keep maintaining or evolving it, that is a support arrangement you choose because it suits you — not a dependency we engineer into the system to keep you paying.

Let’s talk about Web Application Development.

Tell us what you’re building or fixing. A senior engineer reads every enquiry and replies within a business day.

Prefer to book a call?Or email support@yarqat.com

Two fields required. We reply to real enquiries — no list, no sequence.