Web Application Development That Ships Something Useful

What is the difference between a website and a web application?

A website presents content. A web application performs work — it holds state, enforces rules, and has to stay correct when several people use it at once. The visual difference can be nothing; the engineering difference is substantial.

The practical test is whether the system has to remember things and protect them. A brochure site with a contact form does not. A portal where customers log in, see their own data and take actions that change records does — and that brings authentication, permissions, validation, error handling and data integrity, none of which a content site needs.

This matters commercially because the two are priced and built completely differently. Scoping an application as though it were a large website is the most common reason these projects run over.

Should we build custom software or buy something off the shelf?

Buy, unless your process is genuinely a competitive differentiator or no product fits it. Custom software is expensive to build and expensive forever after, because maintenance never stops.

The honest test is whether the way you do this specific thing is part of why customers choose you. If it is, custom may be worth it. If you are building a CRM, a project tracker or an invoicing tool because existing ones are "not quite right", the fit gap is almost always cheaper than a build plus years of maintenance.

The middle path is often best and gets overlooked: buy the general system, build the narrow piece that is genuinely yours, and integrate them. That gets the differentiation without owning an entire platform.

We would rather tell you this before a project than after one.

Why do application projects go over budget?

Scope discovered during the build, not scope agreed at the start. The requirements written before anyone has used working software are, unavoidably, guesses — and some of them turn out to be wrong once there is something real to react to.

The second cause is edge cases. The main workflow is usually a modest fraction of the work. What happens when a payment fails halfway, two people edit the same record, an integration times out, or a user has permissions nobody anticipated — that is where the time goes, and it rarely appears in an initial estimate.

The mitigation is not better estimating. It is smaller first releases. Build the core workflow, put it in front of real users, and let what they actually do determine the next phase. A specification that survives contact with users is rare; a small release that teaches you what to build next is reliable.

Do web applications need SEO?

The application itself usually does not — content behind a login cannot be indexed and should not be. The marketing pages around it very much do.

The distinction matters architecturally. Public marketing pages need to be server-rendered or prerendered so search engines get full content and metadata in the initial response. The authenticated application can be a client-side app without any SEO cost at all.

Where this goes wrong is building both as one client-side application, so the marketing pages inherit rendering problems they never needed. That is a technical SEO issue created by an architecture decision, and it is much cheaper to avoid than to fix.

How is an application kept secure?

By treating every input as hostile and every permission as something to prove rather than assume. Most breaches of ordinary business applications are not sophisticated; they are missing checks.

Authorization is where the common failure lives. Authentication asks who you are and is usually handled well. Authorization asks what you are allowed to reach, and it has to be enforced on every request on the server — not by hiding a button in the interface.

The specific test worth insisting on is whether a logged-in user can see someone else's record by changing a number in a URL. It is trivial to check, it is checked before every launch we do, and it is found more often than anyone would like.

Beyond that: dependencies updated on a schedule, secrets kept out of the repository, rate limiting on anything that can be automated, and logging that captures enough to investigate without capturing personal data that should not be stored.

What does scaling actually mean here?

Almost never what people expect. Business applications rarely fail from traffic volume; they fail from one slow query, one unbounded list, or one report that loads everything into memory.

The first thing that breaks is usually a page that was fine with a hundred records and is unusable at fifty thousand. Pagination, sensible defaults and indexes handle most of it, and all three are cheaper to design in than to retrofit.

The second is background work being done in the request. Sending an email, generating a document or calling a third party while the user waits makes every one of those a way to make the application feel broken. Moving them to a queue is routine, and skipping it is a common source of complaints.

Real scaling — more servers, sharding, distributed anything — is a problem most business applications never reach. Building for it up front usually buys complexity you pay for daily against a problem you may never have.

How do you handle data you did not create?

Carefully, and with the assumption that it is messier than described. Applications almost always import something — a customer list, historical records, an export from the system being replaced.

Validation happens at the boundary, before anything enters your database. Records that fail get reported with the reason rather than dropped silently, because a migration that quietly discards five percent of the data is worse than one that fails loudly.

Duplicates are the recurring problem. The same customer under three spellings, the same product with different identifiers. There is no automatic answer; there is a matching rule someone from your side has to agree to, and a review list for the cases the rule cannot decide.

We keep the original import intact and separate from the working data, so that a bad transformation is recoverable. It costs a little storage and saves entire weeks when a rule turns out to have been wrong.

What does support look like afterwards?

Defined before launch, because an application in daily use has needs a brochure site does not. If people depend on it to work, someone has to be responsible when it does not.

The parts worth agreeing explicitly: what counts as urgent, how it is reported, what response you can expect, and who has access to fix it. Vague arrangements become expensive precisely when something is already going wrong.

Monitoring is what makes support possible. Errors reported automatically, with enough context to diagnose them, mean problems are found before a user reports them. Without it, your first signal is a frustrated phone call and no information.

Then the ordinary work — dependency updates, certificate renewals, third-party API changes — which is covered under maintenance and support where you would rather not staff it internally.

How do you decide what to build first?

By finding the workflow with the most manual effort attached and building that end to end, rather than building a shallow version of everything.

The reason is evidence. One complete workflow in real use produces information that no amount of specification does — where people hesitate, what they expected, what they do that nobody mentioned in discovery. A broad, shallow first release produces opinions instead.

It also protects the budget. If the project stops after the first release, you have something genuinely useful rather than a partial version of several things. That is a much better position to be in, and it happens more often than anyone plans for.

The selection criterion we use is simple: which task currently consumes the most person-hours, and is the most consistent? Consistency matters as much as volume, because a high-volume task that varies wildly is the hardest thing to automate well and the wrong place to start.

What makes an internal tool actually get used?

Being faster than the thing it replaces, for the person doing the work, on the task they do most often. Every other consideration is secondary to that.

Internal tools are adopted or abandoned on a comparison the user makes in the first week: is this quicker than my spreadsheet? If the answer is no for their most common task, they will keep the spreadsheet, and the two will diverge until neither is trustworthy.

This is why keyboard efficiency matters more in internal tools than in customer-facing products. Someone entering forty records a day will notice every unnecessary click, and will notice a form that cannot be completed without reaching for the mouse.

The other half is trust. A tool that loses work, times out mid-entry or silently fails to save will be abandoned regardless of how good it is otherwise. Reliability is the feature; everything else is built on top of it.