CM Metrology: bilingual site and CMS

Short answer

CM Metrology is an industrial metrology and calibration company in Tangier, Morocco: 3D measurement and inspection, 3D digitisation and reverse engineering, calibration, and the consulting and training around them, for automotive, aerospace, rail and manufacturing customers. Cordytech designed and built its public website and the CMS behind it, and has hosted and maintained both since November 2025. It is a server-rendered Laravel and Inertia application in English and French, where every service, product, client logo, testimonial and interface string is a record their own team edits.

Most of what we run is email sending infrastructure. This one is the web-development practice, and it is a different kind of engagement: shorter to launch, longer to live with, and judged by whether the client can still change their own site a year later without calling us.

CM Metrology measures things for a living. Their laboratory runs coordinate measuring machines and 3D scanners against parts, assemblies, moulds and tooling, and reports whether the geometry matches the drawing. People who work to a tolerance are exacting customers for software, which is the best kind to build for.

01 What did Cordytech build for CM Metrology?

The site, the back office behind it, and the servers under both. The public side is a home page, an about page, four service pages, a product catalogue and a contact page, in English and French. The private side is where their team edits every one of those without opening a ticket.

Layer	What it is	Who touches it after launch
Public pages	A server-rendered Laravel and Inertia application	Nobody — it renders whatever the records say
Services, products, sliders, client logos, testimonials	CMS records with their own publish state and ordering	CM Metrology
English and French interface text	Translation records loaded into every page render	CM Metrology
Contact enquiries	Stored on submission, not only emailed	CM Metrology
Servers, TLS, deploys, backups, CDN	Hosting we run	Cordytech
New sections, fixes, the next thing	Continuing work	Cordytech

The middle rows are the deliverable. The top row is what people think they are buying.

02 Why is the CMS the real deliverable, not the homepage?

Because the homepage is finished on launch day and the business is not. A metrology laboratory adds a service, buys an instrument worth listing, wins a customer whose logo is worth showing, changes the phone number on the door. Every one of those is a five-second edit or a two-week wait, and which one it is was decided by whoever built the site.

We take a hard line on this. If a developer would be embarrassed to bill for a change, that change belongs in the CMS. A price, a phone number, the order of a list, a photograph, a testimonial, the text on a button — none of that is engineering, and any of it living in a repository is a design failure dressed up as a technical constraint. It is the same standard we hold on the web application development we do for other clients: the client owns the operating surface, we own the machinery.

03 How do you run one site in two languages without doubling the work?

By splitting the problem in half and refusing to solve both halves the same way. Interface text — buttons, labels, form errors — is a fixed set written once by whoever builds the site, so it lives in translation records loaded into every page render. Content — services, products, the about copy — is written by the client, changes constantly, and is routinely created in one language before it exists in the other, so language belongs to the record itself.

Conflate the two and you get the site everyone has seen: an English page with three services and a French page with two, because adding the French version meant editing a file nobody on the client's side can reach. The visitor does not read that as a content-management problem. They read it as a company that does not take their language seriously. There is more on how we wire this up in the full write-up of the build.

04 Why server-render a React front end?

Because everything that reads a site on a buyer's behalf reads HTML. Search crawlers, AI answer engines, the preview card generated when someone pastes the link into LinkedIn or WhatsApp — most of them do not execute JavaScript, and the ones that do are slower and less reliable about it than they are about markup.

So the front end is React, and it renders on the server. The service descriptions, the product entries and the page metadata are all in the initial response, in both languages, before a single script runs. The second reason is the plainer one: a buyer opening the site on a phone from an industrial estate should see content while the JavaScript is still arriving.

05 What changes when the people who built it also host it?

The site does not rot. Certificates renew, the runtime gets upgraded, backups are taken and occasionally restored to prove they work, and the CDN in front of it is configured by the people who know what is behind it. When something needs to change, the same team that wrote the code deploys it.

The alternative is the handover, and the handover is where most agency sites die: the build is signed off, the files go to whoever the client can reach, and eighteen months later the site is a version behind everything and nobody wants to touch it. It is the same position we take on the sending infrastructure we run for clients like EMG — the configuration lives with the people accountable for it, not in a folder someone inherited.

06 How does an engagement like this start?

With the thing you already have. CM Metrology started as a build, and it continues as maintenance and new work, because the site is not a project that finished in November — it is a surface the business uses.

If your site takes a developer to change a price, or your second language is quietly two services behind your first, that is the part worth fixing before any redesign. Tell us what you are running now and we will tell you which of it is a rebuild and which is an afternoon.