We read it before we touch it
A full security and structural pass first. You get findings ranked by risk, in plain language, and an exact price for putting them right.
Case Study — Platform Maintenance
O Lab Plus Taking over the platform an optical lab runs on
An independent optical laboratory in Brossard, Québec, serving eyecare clinics since 1987. We took charge of the business platform their orders run through and raised its security and stability — ongoing ownership, not a one-off build.
Client
O Lab Plus
Sector
Optical laboratory
Engagement
Safe launch → maintenance
Status
Ongoing mandate
1987
In business since
An established lab serving eyecare clinics — not a startup experiment.
Inherited
The codebase
We didn't write it. We took responsibility for it anyway.
Live
Where every change lands
No staging-only victories — the business is trading through it.
Ongoing
The mandate
Platform ownership with no end date, not a fixed-scope delivery.
The client
A business that lives inside one platform
O Lab Plus has been cutting and fitting lenses for eyecare clinics out of Brossard since 1987. The clinics that order from them don't see a laboratory — they see a platform.
Which makes that platform the business. It was already built, already in production, already carrying real orders when we arrived. The question was never what should we build. It was: who is responsible for this thing, and does anyone actually know what's in it?
- Business platform
- Already in production
- Existing codebase
- Daily operations
- Real customers
How we framed it
Taking over someone else's platform is a trust problem before it's a technical one. You earn the right to change it by reading it first.
What was actually at risk
Handovers rarely fail on skill
They fail on the unknown. A new team inherits a system nobody has fully read, starts changing it, and finds out what was load-bearing the hard way — in production, on a Tuesday morning.
The usual handover
How this one ran
The new team learns the system by breaking it.
A full security and structural read before anything was touched.
Findings arrive as a frightening PDF, and stop there.
Findings in plain language, ranked by risk, with a fix plan and a price.
Fixes ship in a batch and nobody checks the ones that matter.
One change at a time, each verified against what it was meant to do.
Six months later, the same holes are quietly back.
Every significant change reviewed before it lands, so it stays fixed.
“Ownership” means being called once it's already down.
Ownership means the platform is looked after between incidents.
How we took it over
Read it, fix it, harden it, then hold it
The same ladder we run on any platform we inherit: a Coherence & Security Audit, then Production-Safe fixes, then a Safe-Change Layer so it stays that way. Nothing after step one was priced or started before the client approved it.
-
Read the platform
Before any change- Full security read — access rules, exposed keys, auth and permission gaps
- Structural health of a codebase we didn't write
- What's untested, and what that puts at risk
- A prioritized findings report in plain language
-
Fix in order of risk
Highest risk first- Sequenced by what could hurt the business, not by what was easy
- Each change scoped and approved before work started
- Every change verified, not simply shipped
- A verification summary written for the business, not for developers
-
Harden for real use
The safe launch- Stability under real traffic, not demo traffic
- The failure paths nobody had ever exercised
- Access and permissions tightened to the roles that actually exist
- A clear way back out of anything risky
-
Take ownership
Ongoing, no end date- Every significant change reviewed before it becomes a problem
- No reopened security holes, no drift from what the system was meant to do
- A plain-language explanation of anything risky, with the fix attached
- A named team that already knows the system when something happens
What ownership looks like now
The rhythm that keeps a live platform boring
Boring is the goal. The system a business runs its orders through should be the least dramatic thing it owns — and that is a rhythm, not a heroic weekend.
01
A change comes in
A feature, a fix, a dependency that needs moving — whatever the business needs next.
02
Reviewed first
Checked against security and against intent before it goes anywhere near production.
03
Shipped and verified
It lands, and we confirm it does what it was supposed to — rather than assuming.
04
Still solid
No reopened holes, no quiet drift. The platform ends the week where it started.
Repeated every release — that's what maintenance actually means
The result
A platform the business stopped worrying about
Security and stability raised on a live platform an optical lab has run its operations through since 1987 — and an owner for it, release after release.
For the business
The platform their orders run through is held by a team that knows it — no scramble to find whoever touched it last.
For the platform
Security and stability raised deliberately, in order of risk, with each change verified rather than assumed.
For what comes next
New work lands on a solid base, and risky changes get caught in review instead of in an incident.
Your turn
Inherited a platform you're afraid to touch?
O Lab Plus is one case. The way it was taken over — read, fix, harden, hold — is how we take on any system that's already carrying a business.
Fixed in order of risk
Highest risk first, each change scoped and approved before it starts, and every one verified rather than assumed to have worked.
Then it stays fixed
Ongoing review of every significant change, so the holes we closed don't quietly reopen while you keep building.
Before you book
The questions owners ask us first
We didn't build it — can you still take it over?
That's the normal case, and it's exactly what happened here: we didn't write the O Lab Plus platform either. We start with a full read — security, structure, what's untested — and work from findings rather than assumptions. Inheriting a codebase is a reading problem before it's a coding problem.
How do you raise security without breaking a live system?
By sequencing it. Fixes are ordered by risk, scoped and approved one at a time, and each is verified against what it was supposed to do before the next one starts. Nothing goes out as a big-bang cutover on a platform a business is trading through.
Is this a project or a retainer?
Both, in sequence. There's a defined piece of work up front — the read, then the fixes, then hardening for real use. What follows is ongoing: we hold the platform and review every significant change. The Coherence & Security ladder sets out how each step is priced.
What does “maintenance” actually cover?
Every significant change reviewed before it becomes a problem, no reopened security holes, no drift from what the system was meant to do, and a plain-language explanation — with a ready-to-paste fix — for anything risky. It's ownership, not a dashboard someone might look at.
Can you work on a platform someone else keeps developing?
Yes, and that's the usual shape. Reviewing every significant change is precisely what lets your team — or another vendor — keep moving without quietly undoing the work.
Where does this start?
With the read. A Coherence & Security Audit tells you where the platform actually stands and what it would cost to make it solid. Everything after that is priced from what we find, and approved by you before it starts.
Ready when you are
Hand us the platform you inherited
Tell us what you're running and what worries you about it. We'll read it properly, tell you the truth plainly, and price the work from what's actually there.
01
A short call
You describe the platform, who depends on it, and the part of it you'd rather not think about.
02
We read it
A full security and structural pass, with findings ranked by risk and written in plain language.
03
You decide
A fix plan with an exact price. Nothing starts before you approve it.
Inherited a platform?We read it, fix it, and keep it solid.
Book a call