One codebase or four instances: build-vs-buy is a count of configurations

Build-vs-buy for an SME is usually argued on features and licence cost. The more durable question is how many configurations you end up owning. Every separate deployment is a separate place to get response headers right, a separate access-control model, a separate log nobody reads. Count that surface before you count seats.

Count the deployments, not the features

A platform we built for a biomass boiler manufacturer runs four country domains (.lu, .be, .fr, .ch) from one codebase, serves 7 languages and publishes 8 SEO articles every day with 0 manual intervention. The bought alternative to that brief is usually four instances of something: four admin panels, four header configurations, four sets of access rules. The feature list can look identical. The surface you have to keep correct does not.

Misconfiguration moved up to second place

In the OWASP Top 10 for 2025, Security Misconfiguration moved up from #5 in 2021 to #2. Misconfiguration is not a coding mistake you can review away once; it is a state that drifts per environment. One codebase has one place where response behaviour is decided. Four purchased instances have four, and nothing forces them to agree with each other over time.

Headers are per response, not per site

A CSP should be delivered in the Content-Security-Policy response header, set on all responses to all requests, not just the main document. For script loading, recommended practice is nonce- or hash-based fetch directives, a strict CSP, and it can be deployed in report-only mode first so violations are reported without being enforced. Multiply that rollout by every instance you bought. Note too that a CSP is not an alternative to sanitising input.

Access control is the part nobody ships for you

Broken Access Control maintains its position at #1 as the most serious application security risk; contributed data indicates that, on average, 3.73% of applications tested had one or more of the 40 CWEs in that category. Buying does not move that risk off your books, because the rules about who sees which market, which language and which draft are yours to express. Four instances give you four chances to express them differently.

Logs are generous, alerts are not

Great logging with no alerting is of minimal value in identifying security incidents. Bought platforms tend to be generous with logs and quiet about who gets woken up, and each instance keeps its own. The 2025 list also adds Mishandling of Exceptional Conditions as a new category, which is what unreviewed failure paths turn into. One codebase gives you one place to decide what a failure does and who hears about it.

The numbers stay yours either way

Procurement does not transfer performance. LCP should occur within 2.5 seconds of when the page starts loading, INP should be 200 milliseconds or less, and a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop. Good TTFB values are 0.8 seconds or less. A showcase platform we built for an independent Belgian consulting firm reports time to first byte under 200 ms, hardened security headers and 0 technical SEO issues at launch.

What to count before you sign

List the configurations each option leaves you owning: how many places set response headers, how many express access rules, how many raise an alert when a request fails, how many get measured at the 75th percentile. If the bought option multiplies that count per market, the saving sits in procurement and the cost moves into operations. One codebase across four domains is not elegance; it is one surface to keep correct.

Sources

OWASP — Top 10:2025 Introduction — https://top10.owasp.org/2025/0x00_2025-Introduction/

MDN Web Docs — Content Security Policy (CSP) — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

web.dev (Google Chrome) — Web Vitals — https://web.dev/articles/vitals

web.dev (Google Chrome) — Time to First Byte (TTFB) — https://web.dev/articles/ttfb

Neurolinks case study — Four markets, one codebase — https://neurolinks.be/work/tatano-energy