When a team retypes the same information into three different tools, when clients start asking for access to their own documents, when the shared spreadsheet has become the backbone of the company, the subject is no longer the brochure site. It has become a question of tooling. This is a scoping article, not a catalog of technologies: it sets out the signals that announce the need, the cases where you should on no account build anything, and the method for framing a custom web application before you put a price on it.
The five signals that announce the need
- Recurring double entry. The same information is retyped from the form into the spreadsheet, then from the spreadsheet into the invoicing software. Put an honest number on it: four minutes per file, thirty files a week, and you are at two hours a week, close to thirteen working days a year, and as many chances to get it wrong.
- Repetitive client requests. “Where has my order got to?”, “could you resend my March invoice?”. If those two questions occupy one person for several hours a week, an online portal makes them all but disappear.
- The shared spreadsheet that has turned critical. It has no history, no serious access rights, no consistency checks. The day a formula breaks or a row is overwritten, nobody knows how to get back. Its fragility is proportional to the importance it has taken on.
- A business process you cannot buy off the shelf. The way you qualify a case, plan a round of visits or work out a discount fits no software on the market, and you spend your time working around the tool you pay for.
- A volume that makes manual tracking impossible. Past a few hundred active files, human memory and manual sorting are no longer enough, and what slips through costs more than the tool would.
For each of these signals, a single question settles it: how many hours a month does the status quo really cost? If the answer runs to hours, you optimize. If it runs to days, you build.
Before you build: the assemble-first reflex
Half of the needs described in a first meeting can be settled without writing a line of code. A form wired into a management tool, a sync between the shop and the accounts, an automation that creates a record with every order: these assemblies go up in a few days, adjust easily and create no technical debt.
Assembly shows its limits in four precise situations, and you need to recognize them before you shut yourself inside one:
- The per-user cost becomes prohibitive. Billing per user per month, multiplied by fifteen people and three tools, ends up well above a build written off over three years.
- Depending on an outside service becomes a risk. A change of pricing terms, a connector withdrawn, a service closed down: your business process stops and there is nothing you can do about it.
- The process is too specific to be modeled. You then spend more time working around the tool than working.
- Volumes go beyond the quotas. Automation platforms bill by the operation and cap the number of calls. Past a certain rate, the assembly turns both expensive and slow.
The three shapes a custom web application takes
The client portal
Documents, order or case tracking, invoices, messages. It is almost always the best ratio of value produced to technical complexity, and it makes an excellent first project: the scope is easy to draw, the benefit is measured in calls avoided from the first month, and the tool grafts onto the existing site without touching it.
The internal business tool
Modeling a process specific to the company: scheduling call-outs, tracking production, managing a fleet, qualifying cases. The gains are direct and countable in hours, but the scoping is more demanding, because you have to choose between the process as it is and the process as you wish it were.
The connected component
A module that links the site to the tools already in place: sales management, accounting, logistics, mail. The interface is secondary here; the real subject is integration, and this is by far the shape most underestimated in development time.
What React brings, and what it does not
An interface with a great deal of interaction in it gains from being built with a component library. React brings three concrete things: complex state handling that stays readable when the screen holds twenty interdependent elements, responsiveness with no page reload, and components you reuse from one screen to the next. For a filterable dashboard or a form with conditional steps, the difference in comfort is real, for the user and for the developer alike.
What it demands in return is just as concrete. A build and deployment chain to maintain. Automated tests, without which every change becomes a wager. Explicit attention to accessibility, because a homemade component is never accessible by default, unlike a native form field. And for any public part meant for search engines, server-side rendering, failing which the content risks being seen by nobody.
The conclusion is nearly always the same: a presentation page has no reason to be an application, and a client portal has no reason to be a static page. The choice of tool comes after the scoping, never before.
Integrations, where the real difficulty hides
A custom project rarely fails on its interface. It fails on the way data moves between systems. The hard points are always the same:
- Incompatible formats: dates, currencies, VAT rates, units, character encoding. The subject looks trivial until the first client whose name contains an apostrophe.
- The direction of the sync. Does it run one way, both ways, how often, and what happens if both sides change between two passes?
- Duplicates. Two records for the same client created three seconds apart: you need a matching key decided in advance, not a manual clean-up every month.
- Recovery after an incident. A third-party service unavailable for two hours must not cost you the operations of those two hours. That means a queue, repeated attempts and jobs you can replay without creating duplicates.
- Call limits. Most providers cap the number of requests per minute. A data migration of 20,000 rows has to be cut into pieces, or it fails a third of the way through.
- The security of access tokens. Stored server-side, rotation planned for, the narrowest possible scope of rights. France’s data protection authority sets out the data security requirements (page in French) that apply as soon as personal data is involved, and it almost always is.
One rule alone heads off most of the mess we see: for every piece of data, decide which application is the authority. The billing address comes from the accounts, the order status comes from the shop, the client record comes from the management software. Write it down in black and white before the first line of code, and synchronization conflicts settle themselves.
Scope before you price
A custom project is scoped in four moves, and it rarely takes more than a week.
- List the users and their tasks. Who logs in, to do what, how many times a week. Three profiles are often enough.
- Write the journeys as plain sentences. “A client logs in, sees their last three cases, downloads an invoice.” If the sentence will not write itself, the feature is not ripe.
- Separate the essential from the comfortable. Two columns, and one discipline: everything that is not essential moves to the next version.
- Write down what will not be built. It is the most useful part of the document, and the part nobody writes.
Then aim for a deliberately reduced first version, put into service quickly, rather than a full scope delivered in a year. A tool used by five people for six weeks teaches you more about the real need than six months of workshops. How long a web project really takes gives the orders of magnitude to hold on to when you build that schedule.
Our position: living with a custom application
Sales pages stop at delivery. That is precisely where the expensive part begins if nobody has planned for it. An application is updated, backed up, watched over, and it changes as the company changes. Front-end libraries age fast: a codebase left two years without updates is picked up again at a high price, whereas the same work spread out as it comes stays marginal.
Three requirements are not negotiable on our side, and they are fair to put to anyone. The code lives in a repository in your own name, which you have access to. The deployment procedure is documented, so that another team can take the work over. Backups and monitoring are in place from the day it goes live, not added after the first incident. These are the same questions worth asking when choosing a web agency, with more riding on the answers. Keeping it all running is then handled through ongoing support and application maintenance. When the need is mainly about the public front of a site that is already well administered, the question is a different one, and it belongs on the side of headless architecture.
Frequently asked questions
Do you have to rebuild the site to add a client portal?
No. The portal grafts onto the existing site, usually on a dedicated subdomain, with its own authentication. The brochure site carries on with its life untouched.
Custom build or off-the-shelf software?
Off the shelf first, every time. A custom build is justified when the process is a competitive advantage, when no vendor covers it, or when the per-user cost of an existing solution becomes unreasonable at your scale.
Who owns the code that gets written?
The client, with access to the repository and the deployment documentation. It belongs in the quote, not in a discovery at the end. We write it into ours, and it is a fair clause to ask of anyone.
Can you start small?
Yes, and we recommend it. A limited first version genuinely in service is worth more than a complete project never delivered. It validates the need, reveals the real hard points and pays for what comes next.
What to take away
A custom build is not a luxury, it is a trade-off: you build when the process is specific and the time lost runs to days a month. Before any quote, measure the cost of the status quo over two weeks, in hours actually spent. That figure will decide the project better than any pitch.
Also worth reading: brochure site or online shop, which one to choose
