A solid platform for your business

Software architecture decides the cost of the years that follow

The first version of a platform costs what it costs. It is the following ones that make the total bill, and they depend on choices made at the start. A software architecture separating business rules from technology allows a database, a framework version or an interface to change without touching the core. The same application written as one block forces everything open again for a minor change. The initial extra cost is counted in days, the saving in weeks from the second year onward. This is not a matter of school of thought: it is the difference between a platform that evolves and one that eventually gets rewritten.

Scalability is prepared, not added

Handling load is not a button pushed the day traffic arrives. It is decided in how the application stores its data, handles long-running tasks and manages sessions. An application writing files to the server disk does not duplicate; the same one writing to shared storage duplicates with one command. An application computing an export inside the visitor's request blocks; the same one handing it to a queue holds. These decisions cost almost nothing up front and become unaffordable later. We make them even when expected traffic is modest, because their price lies in the choice, not in the work.

The database is the only component that cannot be thrown away

A server is replaced, a framework version is changed, an interface is redone. Data accumulates and cannot be recreated. That asymmetry justifies particular care on three points. The model first, because a structural mistake is paid on every query for years. Then indexes, which make the difference between a page answering in a tenth of a second and the same one taking five seconds on ten times the rows. Finally migrations, which must be repeatable and reversible: a schema change applied by hand in production is the most direct way to lose an evening, and sometimes data.

Continuous deployment removes the fear of shipping

When shipping is painful, you ship rarely, so you ship a lot at once, so every release is risky, so you ship even more rarely. The circle breaks by automating the chain: an approved change produces a version, that version deploys the same way every time, and rolling back is a planned operation rather than improvisation. The gain is not the time saved on the command, it is in frequency: shipping ten small changes is less risky than one big one, because if something breaks you know which one caused it.

Three environments, and one way of building them

Development is for writing, acceptance for validating, production for serving your users. The common mistake is letting them drift apart: a different PHP version here, a missing extension there, test data resembling nothing. The day a bug only appears in production, the time lost understanding why far exceeds the time it would have taken to align the three. Describing the environment in the repository, alongside the code, removes that entire class of problem. Acceptance then becomes a faithful copy, and what works there works afterwards.

Monitoring tells you what happens, not what you imagine

Without measurement, a slowdown is debated; with measurement, it is fixed. Three families of indicators are enough to start. Availability first, checked continuously by an automated tool that alerts as soon as a page stops answering. Then response times, page by page, because an acceptable average often hides one slow page nobody looks at. Finally errors, centralised and timestamped, so a broken form is not discovered through a visitor's message. These three measurements cost little and change the nature of the conversation: you discuss figures instead of impressions.

Performance is not an average, it is the worst case

A site is judged on its slowest page, not on the average of its pages. And it is judged on a mobile over 4G, not on the developer's fibre connection. The three most frequent causes of slowness can be identified without expensive tooling. Images, which often weigh more than everything else on the page, and whose fix is the modern format plus correct sizing. Database queries, whose count sometimes grows with the number of displayed items, a classic flaw invisible on a test dataset. Finally blocking JavaScript, which delays rendering without contributing anything before interaction.

Security is a checklist, not an intuition

The flaws that actually hit websites are not exotic, they are known and catalogued. Outdated dependencies come first: a library left un-updated for two years carries vulnerabilities that are published, documented and tooled. Then come forms trusting whatever is sent to them, access rights checked in the interface but not server-side, and secrets left in the repository. Each of these points can be verified, and the verification repeats. A secure platform is not a platform audited once, it is a platform whose dependencies are tracked.

Technical debt is repaid in small instalments

Every project accumulates shortcuts: a workaround to meet a date, code copied twice, a fix landed without a test. This is not a lack of rigour, it is how a moving project works. The problem is not the debt, it is never repaying it, because the interest is paid in development slowness. The method that works is reserving a fixed share of every iteration for repayment, rather than waiting for a general rewrite that never comes. An up-to-date list of accepted shortcuts, with their estimated cost, turns a vague unease into decisions that can be weighed.

Documentation is first for whoever takes over

A platform only one person knows how to deploy is a fragile platform, whoever that person is. Three documents are enough, kept in the repository rather than in a separate tool that goes stale. How to install the project on a fresh machine, in copyable commands. How to deploy it and how to roll back. Which architectural decisions were made and why, so that nobody undoes through ignorance a choice made for a reason. You remain the owner of the code and of its instructions: that is what leaves you free to change provider.

Taking over an existing platform, without rewriting everything

A platform in service is not replaced in one block, because downtime is unacceptable and the risk too concentrated. Taking over starts with an assessment: versions in place, unmaintained dependencies, areas where the code changes most, points that break most often. That survey ranks what deserves effort and what can stay as it is. The most exposed functions are then rewritten one by one, behind the same interface, which allows each step to be validated without service interruption. A full rebuild remains possible, but it must be a choice justified by a figure, not the default answer.

Microservices platforms: design and operation

We design microservices platforms, meaning platforms split into autonomous services that deploy, are monitored and scale separately. That know-how covers the whole chain, not only the splitting of the code. Defining the boundaries between services, separating what changes at a different pace or carries a different load. Choosing the mode of dialogue, a direct call when the answer is expected immediately, a message queue when the processing can wait and must survive a restart. Holding data consistency when each service owns its own, which is the real difficulty of the exercise and is handled through event exchanges rather than shared transactions. Making the whole thing observable, with centralised logs and a correlation identifier allowing one request to be followed from service to service. Finally automating deployments, because an eight-service platform is not shipped by hand. We also know how to arbitrate the scope, and that is what makes the architecture sustainable over time. A service is pulled out when it has its own rate of change or its own load constraint, not when it has a different name. Applied from the scoping stage, that arbitration yields a platform where every service has a reason to exist. It is reinforced unit by unit instead of being rebuilt, and its busiest parts duplicate without touching the rest.

Containers and cloud: the point is reproducibility

A Docker container describes the runtime environment in a versioned file: language version, extensions, web server, everything is written down. The benefit is not fashion, it is that the same description produces the same environment on the developer machine, in acceptance and in production. On cloud hosting, that description also becomes the condition for duplication: two identical instances behind a load balancer, because they are built from the same file. The mistake to avoid is adopting the tool without the automation that goes with it. A container built by hand loses its main purpose, which is making the environment reproducible without intervention.

Backups and recovery: the question is the delay, not the existence

Almost all hosting providers take backups. Far fewer projects can answer two precise questions: how long does it take to bring the service back online, and how much data is lost in the operation. Those two figures are decided before the incident and determine the setup. A daily backup restored by hand and continuous replication do not cost the same and do not provide the same service. The point that really matters: a backup never restored is not a backup, it is an assumption. One restoration drill, run once on an acceptance environment, turns that assumption into a certainty and often reveals a missing piece.

High availability is paid for in architecture, not in promises

A platform stays reachable for your users without interruption when none of its components is single. Two application servers behind a balancer, a database with a replica ready to take over, file storage separated from the machines: every duplicated element removes a failure point. That setup has a hosting cost and a design cost, and it is not justified for every project. The question to settle is simple and quantifiable: what does one hour of downtime cost your business. A booking site on a Saturday evening and a corporate site do not have the same answer, therefore not the same architecture.

Integrations are where platforms break

A platform rarely works alone: payment, invoicing, logistics, management tool, messaging. Each of those links is an external service, therefore something that will go down one day without warning. Three precautions avoid most of the damage. Treating every outgoing call as liable to fail, with a retry and a trace, rather than letting the error reach the visitor. Isolating integration code behind a clean interface, so that an API change at the provider does not spread through the whole application. Recording the exchanges, because a billing discrepancy is settled on timestamped data, not on recollections. On the exposed interface side, a REST API remains the format easiest for a third party to consume, because everyone can read an address and a return code. In exchange it demands version discipline: a change that breaks existing callers goes through a new route, never through a retouch of the old one. And as soon as two instances of the application run behind a load balancer, the API must do without local memory.

What you receive at every step

A platform project is steered on visible deliveries, not on a completion percentage. At every iteration, a version is deployed to an environment you can open, with the list of what changed. You see for yourself instead of being told, which makes course corrections possible during the project rather than at the end. At the end of the engagement, you get the code in a repository you own, the installation and deployment documents, and the hosting credentials. That handover is not a closing formality: it is what makes the difference between a platform you own and a platform whose use you rent.

Automated tests buy the right to change things

On a small application, checking by hand is enough. Past a certain volume of features, manual checking becomes too long to redo on every change, so it stops being redone in full, so regressions get through. An automated test is not a quality badge in itself, it is a net that makes a change low-risk. The order of priority is always the same: cover first the journeys whose failure costs money, a payment, a sign-up, a contact form. Then business calculations, and only afterwards the rest. A suite run automatically on every change tells you within minutes whether the last fix broke something else, which no amount of re-reading does reliably.

Why the price range of a web platform is wide

The same project label can cover very different budgets, and that is not a matter of margin. Four variables create the gap. The number of user roles, because each role adds screens and permission rules to verify. External integrations, each of which has to be negotiated, tested and maintained. The expected availability level, which decides whether hosting is duplicated or not. Finally data migration, often underestimated, because recovering a poorly structured history takes longer than writing the feature that uses it. Serious scoping puts figures on those four points before announcing an amount, and that is what the first conversation is for. Our pricing grids give the orders of magnitude by project type.

Web hosting is chosen after the architecture, never before

Shared hosting for a few euros suits a content site and quickly hits a ceiling on an application platform, for lack of control over versions, scheduled tasks and available memory. A dedicated server or a cloud instance lifts those limits but requires administration that cannot be guessed. The right order is therefore to decide first what the platform must handle, then take the matching hosting. The reverse, which is common, ends in working around the provider's limits for months to save a few euros a month.

These points form the grid of a web platform scoping exercise, and they are taken one by one on a real project. To discuss your own case, the first conversation costs nothing and the quote is free.