Web and application development

Brochure site, business application, shop: three needs the word "site" conflates

In short: A brochure site publishes information, an application moves work forward, a shop takes payment and handles everything that follows an order. The number of pages says nothing about the difficulty: what counts is how much state the software has to hold and how many rules it has to enforce.

The word "site" is used indifferently for objects whose only common ground is an address and a browser. They are poorly told apart because they are compared by appearance, whereas what separates them is invisible. A page presenting a business only has to be displayed: it says the same thing to everyone and remembers nothing. A booking form, by contrast, has to know what is already taken, refuse what is no longer available, keep a record of what was decided, and behave correctly when two people click at the same instant. The second case contains state that changes, and therefore possible conflicts, access rights, history and consistency rules. That is where the effort and the defects live, not in the number of pages or the richness of the graphic design.

The brochure site publishes. Its purpose is to be found, understood, and to make contact possible; it changes almost nothing and its value lies in the clarity of what it says. Its difficulties are therefore editorial first: stating what is on offer, to whom, and how it differs from something else. Three technical requirements come with it, often neglected because they do not show on a mock-up. Display speed on an ordinary device and an average connection, which decides how many people stay. The structure of the content, which lets a search engine — and now the systems that compose answers from web pages — identify what each page deals with and quote it correctly. And the company’s ability to change a sentence without depending on anyone: a brochure site nobody can correct goes stale quickly and ends up working against its owner.

The business application does not publish, it gets work done. It carries accounts and roles, data that changes state — a file moves from received to processed, a request is approved and then closed — rules that decide what is permitted and to whom, and a trace of who did what. Its complexity cannot be read off the screens: it lies in the exceptions of the trade, that is, in the cases the official procedure does not describe and that people currently handle from memory. An application that handles the nominal case well and the exceptions badly is perceived as unusable, because it is precisely the exceptions that consume the time of the people using it. This is also the category where questions of access, confidentiality and retention genuinely arise, since the data handled is the data of the business and sometimes that of third parties.

The shop adds money, and with it a chain of obligations that does not stop at payment. The catalogue, the basket and the checkout are the visible part; behind them come actual availability of items, delivery and tax rules that vary with the nature of the product and the status of the buyer, the invoice, cancellation, refund, return, dispute, and synchronisation with whatever holds stock or accounts. A shop is an order management system disguised as a catalogue. The practical consequence deserves to be stated at scoping time: it is judged after the sale at least as much as before. An impeccable purchase path that leads to vague order tracking creates extra work for the company and mistrust in the buyer, which costs more than going live brought in.

Many real projects hold all three at once: a brochure site with a customer area, a shop backed by an internal order-preparation tool. Nothing forbids that mixture, provided everyone knows which part is which, because each imposes its own discipline. The useful question to ask from the outset is therefore not "how many pages" but "what changes when someone uses it". Nothing at all, and you are in publishing. Something is recorded and will have to be retrieved, corrected, disputed, and you are in application territory. That answer governs everything else: how to scope, how to check before going live, what hosting is needed, what maintenance load to expect, and whether an existing product already does the job. It is settled before any conversation about technologies, which are only a means of obtaining what was decided there.

Front end, back end, hosting, database: what each word covers

In short: The front end runs on the user’s machine and can never be trusted; the back end decides and records; the database outlives the code; hosting is where all of it runs, and above all the question of who looks after it.

The front end is what runs in the browser of the person visiting. Three languages share the work there: a structural language, which declares what the elements are (a heading, a list, a field, a button); a presentation language, which decides appearance and adaptation to screen sizes; and a programming language, which adds behaviour. That division is not an aesthetic convention. It is the structure, and it alone, that lets an assistive technology announce that an element is a button, lets a search engine understand the hierarchy of a page, and lets the browser make the interface keyboard-operable without anything being programmed. A button made out of some arbitrary element looks like a button without being one, and most accessibility defects come from exactly that. Two properties of the front end are worth retaining: it runs on a device you do not choose, which makes the diversity of browsers, screens and connections a real constraint; and it is entirely visible and modifiable by whoever displays it.

The back end runs on a machine you control. It is what verifies the identity of the user, decides what they are allowed to see and do, applies the business rules, records and re-reads the data. The second property of the front end stated above has a consequence here that no serious project ignores: a check performed only in the browser is not a check, since all it takes to bypass it is not going through the interface. Any verification that commits something — a price applied, an access right, an available quantity, whether a document belongs to the person requesting it — must be redone on the server, even when it is already done in the browser for the sake of comfort. The two halves communicate through a programming interface, commonly called an API: a set of addresses that accept precise requests and return answers in an agreed format. That boundary has a lasting virtue, namely that the interface can be rebuilt without touching the rules, or another tool fed later with the same data.

The database is where information persists. You first describe a structure there: which entities exist, what attributes they carry, how they relate, and which constraints must remain true whatever happens — an order belongs to an existing customer, the same address does not appear twice, a quantity does not go negative. Entrusting those guarantees to the database rather than to the code alone pays off in peace of mind, because the database enforces them even when part of the program gets things wrong. Two families are commonly met: relational databases, organised into linked tables, suited to data with a regular shape and strong relationships; and document databases, more flexible about shape, suited when every record differs from its neighbours. Two points matter more than that choice. Migration first: the structure will evolve, and making it evolve once it already holds data is an exercise that is prepared rather than improvised. Restoration next: a backup nobody has ever verified as restorable is not a backup. Data outlives code — you rewrite an application, you do not reinvent the order history.

Hosting is where the program runs and where the files are served from. The offers differ less by their commercial name than by how responsibilities are shared: who updates the operating system, who watches the service, who steps in when traffic rises sharply, who restores after an incident. A shared server hands a great deal to the host and leaves little latitude; a virtual machine gives full control and the obligation that comes with it; a managed platform takes charge of execution and deployment while imposing its conventions; a site made of already-computed files, complemented by a handful of functions called on demand, sharply reduces the surface to maintain when the need allows it. Three items accompany hosting and, when forgotten, cause outages without a single line of code having changed: the domain name, which is a registration that has to be renewed; the configuration that points that name at a server; and the certificate that allows the encrypted connection. Finally, a serious project has separate environments — one to develop on, one to check on, one for production — failing which every fix is attempted in front of the users.

What remains is the connective tissue, which appears on no mock-up. The source code lives in a version-controlled repository, which keeps the history of changes, allows a return to an earlier state, and makes work by several people possible without one overwriting another. Deployment is the procedure that turns that code into a live site; automated, it becomes reproducible and stops depending on one person’s memory. Logs record what the program did and are the only way to understand an incident afterwards; monitoring warns that a service has stopped answering before a customer reports it. These items pass for developer comfort; in reality they decide the ability to repair. A site ultimately comes down to three things that must be held together for it to be yours: the code, the data and the configuration — the last of these including the credentials for third-party services. Owning two out of three is not enough.

How a project unfolds, from scoping to maintenance

In short: Describe real journeys before drawing, draw before coding, deliver in usable slices, have the result checked by the people who will use it, treat going live as an operation in its own right, then look after what has been built.

Functional scoping describes what the software must make possible, for whom, and how success will be recognised. A list of features does not suffice, because it enumerates means without saying what they serve. What is described instead is journeys: a person arrives with an intention, performs a sequence of actions, obtains a result. Three elements are systematically forgotten and systematically expensive. Abnormal cases: what happens when information is missing, when a payment fails, when an attachment is unreadable, when the same operation is attempted twice. Business rules written down in black and white: who may see what, what happens on cancellation, what is kept and for what use. And what is out of scope, stated explicitly, which protects both parties far better than a list of inclusions. Scoping finally serves to sort what must exist at opening from what can come later: a sorted scope can be built in slices, an unsorted one is built whole or not at all.

Mock-ups exist so that people argue about a drawing rather than about a program, because a drawing can be thrown away without regret. Functional wireframes, deliberately grey and styleless, settle what is shown, in what order and in what place; visual mock-ups then fix the appearance. Mixing the two makes people discuss colours when they should be discussing organisation, and comments then land on what is easy to change rather than on what is expensive. Two requirements make this stage useful rather than decorative. Working with real content first: the real labels, the real names, the real photographs and the actual volumes, because a mock-up filled with placeholder text and three well-chosen items lies about what the screen will be once full. Drawing the uncomfortable states next: the empty list of the first day, the error message, the wait during processing, the text that overflows, the lost connection. Those states account for a considerable share of the development work and almost never appear in a presentation. Behaviour on small screens is settled at the same moment, and it is settled first rather than last: the constraint of a narrow screen forces a hierarchy of information, from which the wide version then benefits.

Development progresses better in vertical slices than in successive layers. A vertical slice is a complete feature, from the screen down to the database: it works, so it can be shown, so it can be discussed. Building the whole database first, then the whole back end, then all the screens pushes to the very end the moment when someone sees something — that is, the moment when misunderstandings surface. Each iteration ends with a demonstration to people from the trade, and that demonstration corrects the scope: use reveals cases nobody was able to formulate in the abstract. Two practices make that rhythm sustainable. Code review by another person, which catches defects but above all spreads knowledge, so that the project does not rest on a single head. And automated tests, aimed first at the rules whose breakage would be costly — calculations, access rights, state transitions — because they then allow the program to be modified without fear of quietly breaking what used to work.

Acceptance testing is the verification, by the person who ordered the work, that what is delivered does what was asked. It is not the same thing as the developer’s tests, which verify that the program does what its author believes he wrote; nobody usefully reviews their own work with the eyes that produced it. It calls for three conditions: an environment separate from production, realistic data rather than hand-picked examples, and scenarios written in advance — ideally those of the scoping phase, which gives that phase a second use. What is sought is what breaks, not what works. The defects raised are then sorted by severity, and above all by a distinction the project must establish before it needs it: what does not work is a fix, what works differently from what was hoped is a change. Confusing the two is a source of conflict at the end of a project. Acceptance ends with an explicit written decision covering what is accepted, what remains to be corrected and what is deferred.

Going live is an operation in its own right, not the flick of a switch. It involves steps that have nothing to do with code: migrating existing data, with a decision for each set on what moves across, what stays readable only as an archive and what disappears; redirecting old addresses to new ones when one site replaces another, failing which the accumulated links and the pages already known to search engines stop leading anywhere; switching the domain name and checking the certificate; removing the instructions that prevented indexing during construction, an omission so classic that it deserves a line in the procedure; switching on audience measurement and consent collection. You also plan what to do if something goes wrong: returning to the previous state must be a known and rehearsed operation, not an improvisation under pressure. Finally, the people who will answer users’ questions are told before the users themselves.

What is called maintenance covers three activities better named separately, because they do not obey the same logic. Corrective work deals with what does not function. Evolution adds what use has revealed, and it is a sign that a tool is alive rather than an admission that scoping failed. Keeping the thing running is the least visible and the most neglected: updating the components the site depends on when a vulnerability is published in them, following the versions of the language and the system, renewing certificates, checking that backups genuinely restore, verifying that the third-party services in use have not changed their interfaces. Software that is not touched does not stay identical: its environment moves around it, and standing still produces a deferred breakdown. Three questions are therefore settled before the end of the project rather than after: who holds the credentials, where the deployment procedure is written down, and whom you turn to when something breaks.

The mistakes that cost the most in a web project

In short: Committing before describing, delivering without having anything checked, depending on a supplier for want of owning your own tool, treating performance and accessibility as finishing touches, and discovering at go-live that the content does not exist.

The first mistake is to reverse the order of commitment and description. An agreement reached on a scope summarised in a few lines does not make uncertainty disappear, it displaces it: the vague areas will have to be settled eventually, and they will be settled later, under pressure, by whichever of the two parties has more to lose from stopping. The project then ends either with features trimmed at the last moment or with a string of arguments about what was and was not included. A phrase heard everywhere illustrates the problem: asking for "the same thing as that site" describes an appearance, not rules, and two sites that look alike can differ entirely in what they do with the information they receive. The remedy is not to freeze everything, which is impossible in a living project, but to make the description of the need precede the commitment and to name explicitly what is not in it. A scope holds all the better for stating its exclusions; that is also what makes a request for an addition discussable calmly, as an addition, rather than as something owed.

The second is to treat delivery as the end of the work. Without acceptance testing, the first real use happens in production, with real data and people who cannot afford to fail. The defects acceptance testing catches are always the same and never appear in a demonstration: accents and apostrophes in proper names, fields left empty, text longer than the screen expected, files rejected without explanation, two people editing the same record at the same moment, the browser’s back button, the session that expired in the middle of a form, an order submitted twice. You find them by trying to break things, not by trying to show them off. The decisive point is that acceptance is prepared during scoping and not on the eve of delivery: writing down in advance what will count as proof of correct behaviour forces the need to be made precise, and the same document serves once to specify and once to verify.

The third is unintended dependence on a supplier. It almost never sets in through bad intent, but by default, because nobody asked the question at the start. The domain name is registered in the supplier’s name, the code repository is theirs, the hosting is opened on their account, the deployment procedure exists only in their memory, the database has never been exported, the credentials for third-party services are theirs. Taken separately, each of those points looks harmless; together, they mean a company can no longer change partner, nor carry on alone, nor sometimes even correct a line of text. The questions to ask before starting are not a sign of mistrust, they are operational questions: who holds the domain name, where the source code lives and on what terms it can be used, how a complete copy of the data is obtained and in what format, who can deploy, what another team would need in order to take the work over. One practical sign is worth an inventory: if changing a sentence means writing to someone, the dependency is already in place.

The fourth is treating performance and accessibility as finishing touches. Neither is an option switched on at the end; both follow from decisions taken early. Display speed depends on the weight of images and the format they are served in, on the number of files to download before the page becomes usable, on server response time and the queries made to the database, on the amount of code executed in the browser, and on the choice of computing pages in advance, on demand on the server, or on the user’s machine. Those decisions are structural: revisiting them afterwards often means redoing the work. Accessibility obeys the same logic. It consists in using elements for what they are meant to do, making every interaction operable by keyboard, associating a label with every field, guaranteeing legible contrast, never carrying information by colour alone, keeping the focused element visible, and not trapping the user in a window they cannot leave. Taken up at the end, it means rebuilding components; built in from the design stage, it changes almost nothing in the workload. Two arguments are rarely heard together and deserve to be: this work serves far beyond situations of disability, since an unstable connection, a screen in bright sunlight or one occupied hand create the same needs; and depending on the activity and status of the organisation, accessibility obligations may apply, which is worth checking at scoping rather than on delivery.

The fifth is less technical and yet blocks many projects: the content does not exist. Text, photographs, product descriptions, mandatory notices, translations — all of it has to be produced, proofread and decided, and none of it makes itself while development moves ahead. A project whose content has no owner waits, and it waits at the costliest moment, when everything else is ready and attention has scattered elsewhere. The same void shows up on the decision side: when several people issue contradictory opinions and none of them settles the matter, the back and forth multiplies, responsibility for the delay becomes impossible to untangle, and the quality of the result drops, because a screen designed to satisfy everyone serves precisely nobody. Two appointments made at the start are enough to avoid both problems: someone who produces and approves the content, someone who arbitrates. These are roles, not titles, and naming them costs one sentence.

When bespoke development is not the right answer

In short: When a configured off-the-shelf product already does the job, when the need is not stable, when nobody will be able to maintain the result, when the problem is not a software problem, and when a rebuild has no motive beyond weariness.

The first case is the standard need. Publishing pages, running a news feed, selling items in an ordinary way, taking appointments, collecting registrations: those problems have long been solved by widely distributed products that a community or a vendor maintains continuously. Choosing bespoke development in those conditions means taking on work that others are already doing: fixing published vulnerabilities, following browser changes, adapting when a payment service alters its interface, absorbing changes to invoicing rules. That work never stops and stays invisible as long as it is done. Bespoke development is justified when the way of working is itself distinctive — a sequence, a method of calculation, a trade constraint no product knows how to express — or when adopting a product would mean distorting an activity that works well. Between the two lies the answer that is most often right and least spectacular: start from an existing base and develop specifically only at the precise point where the organisation differs. Bespoke development is an advantage when it covers what makes you different, and a handicap when it covers what makes you like everyone else.

The second case is the need that is not yet stable. Writing a program means freezing decisions: every coded rule becomes an assumption set into the structure, and changing an assumption costs all the more as the rest of the code leans on it. When an organisation is in the middle of inventing its way of working — a new service, a process whose shape still changes with every attempt — coding too early fixes a provisional state and turns learning into rework. A manual procedure, a shared spreadsheet or a configured tool takes that transitional role very well: they allow trying, getting it wrong and correcting without breaking anything, and they produce along the way the description of the need that development will later require. Development becomes relevant once the way of working is known and repeated, and what costs is no longer defining it but carrying it out.

The third case concerns what comes after delivery. Bespoke software creates a lasting obligation: someone will have to install security updates for the components used, follow the changes in the language and the hosting, answer users, arbitrate requests for evolution and fund all of it. An organisation with neither that skill in-house nor the intention of entrusting it to someone on a lasting basis will end up with a tool that works at first and degrades afterwards — faster than an off-the-shelf product, not more slowly, because nothing updates itself and no vendor takes care of it on your behalf. The question to ask before starting is therefore not only "who builds it", but "who looks after it afterwards, and with what means". When the honest answer is "nobody", a configured product, less closely fitted to the need but maintained by others, is objectively the better choice; stating that before committing spares everyone an abandoned tool.

The fourth case covers the situations where the software is not at fault. A site does not bring an audience by itself: it turns a visit into understanding and then into contact, but someone has to come first. When visits are rare, the cause lies upstream — visibility, reputation, the channels used, the clarity of the offer — and rebuilding the tool does not correct it. The symmetrical case exists too: when enquiries arrive and go unanswered or untracked, the problem is one of internal organisation, and a better-designed form will only speed up the arrival of enquiries that will be left pending. Telling those situations apart means looking at what happens before and after the site rather than at the site itself: where visitors come from, what they were looking for, what becomes of the messages received, who handles them and in how many exchanges. That examination is conducted without writing a line of code and sometimes spares an entire project.

The fifth case is the rebuild with no identified motive. A working site, familiar to its users and which search engines have learned to place, represents accumulated value that a reconstruction puts back into play: addresses change, habits are lost, pages already indexed have to be found again, and defects patiently corrected sometimes come back in through the window. That value is invisible, which explains how easily it is sacrificed in the name of an appearance judged dated. When the annoyance is identifiable — navigation that loses people, a form abandoned halfway through, an observed slowness, content that has become false — repairing it is easier to judge and quicker to verify than a full reconstruction. A rebuild is justified when the defects are structural: an organisation of information that no longer matches the business, a technical base that no longer receives security fixes, an inability to add what the company now needs. A rebuild decided out of weariness, by contrast, spends what has been accumulated in exchange for an impression of novelty that wears off, whereas a targeted repair can be observed.