Launch is the starting line.
Monitoring, security patching, dependency updates, and a steady stream of improvements — for products we built and products we inherit. Clear response times, a named team, and no ticket black hole.
You're probably here because…
These are the situations teams are usually in when they come to us about maintenance & support. If more than one lands, we should talk.
- The developer who built it has moved on, and nobody else knows the code.
- Dependencies are years out of date and upgrading feels risky.
- You find out the site is down when a customer tells you.
- There's a backlog of small improvements nobody owns.
- You need someone accountable for uptime, not a rotating queue of contractors.
The work, spelled out
No mystery line items. This is what we deliver and what you get to keep.
Proactive monitoring & alerting
Uptime, errors, and performance watched continuously — so problems reach us before they reach your customers.
Security patches & updates
Dependencies and platform versions kept current on a schedule, before an upgrade becomes a migration project.
Bug fixes with response times
Agreed severity levels and response windows, so you know what happens when something breaks and when.
Ongoing enhancements
A steady stream of improvements each month, so the product keeps moving instead of freezing at launch.
Performance tuning & audits
Regular reviews of speed, accessibility, and infrastructure cost, with the findings prioritised rather than filed.
Takeover & documentation
For inherited codebases: an audit, written documentation, and runbooks so the knowledge isn't ours alone.
How this looks in practice
Taking over work we didn't build
Most of what we're handed arrives without documentation, without tests, and without monitoring. We don't start by rewriting it — we start by understanding it. An audit tells you what's actually urgent versus what merely looks old, and gives you a prioritised plan you can decide on rather than a quote for a rebuild.
- Dependency, security, and architecture audit
- The risky areas identified and written down
- A prioritised plan, not an automatic rebuild pitch
- Documentation and runbooks produced as we go
What ongoing actually looks like
Not a retainer you pay to have a phone number. Every month: dependencies patched, monitoring reviewed, the enhancement queue worked through in priority order, and a short report on what changed. Products we maintain get measurably better over a year — that's the whole point of the engagement.
- Patching and monitoring handled without being asked
- An enhancement queue you prioritise
- Agreed response times for anything urgent
- A written summary of what changed each month
What we do differently here
The choices that decide whether this kind of work holds up a year later.
- 1
Audit before changing anything
On an inherited codebase, we learn it first. Dependencies, security, architecture, and the riskiest areas, written down.
- 2
Get monitoring in place
Before improvements, visibility. You can't maintain what you can't see, and most inherited systems arrive blind.
- 3
Patch and stabilise
Security and dependency debt first. It's the least glamorous work and the reason everything after it goes smoothly.
- 4
Settle into a cadence
Then a predictable monthly rhythm: patch, monitor, improve, report — so you always know what we did and what's next.
What we build it with
Every tool here earned its place. The point isn't the logos — it's the reasoning behind them.
Next.jsMost of what we maintain runs on it — including applications we didn't originally build.
TypeScriptOn an inherited codebase, types are how you change something safely without having written it.
Errors surface with the context to fix them, instead of arriving as 'the site is broken'.
Preview deployments per change, so an upgrade is reviewed before it reaches production.
PostgreSQLBackups, migrations, and query performance are a standing part of the maintenance work.
PrismaSchema changes stay reviewable and reversible — the migrations most inherited apps lack.
ResendAlerting and monthly reporting that lands with the people accountable for the product.
Work we've shipped
The same capability, already delivered for someone else.
Hip Haus Membership App
We built Hip Haus a single membership product that runs everywhere its community does. A web app and native iOS and Android apps with chat, video meetings, and live-streamed events built in.
360 Athletics Dealer Portal
We built 360 Athletics a custom dealer portal for their wholesale and distribution business, handling dealer pricing, backorders, purchase orders, and a full medical-device rental operation, all wired into their legacy ERP.
COREFX
A top-tier Canadian fitness-equipment brand, stocked in many of the country's best gyms that was given a custom Shopify storefront and theme worthy of the products.
Recovery Room
Canada's leading source for fitness and injury-recovery equipment, and the brand behind the cryotherapy rental products, on a custom Shopify store.
Three ways we take on the work
Which one fits depends on the project — we'll recommend a shape after a discovery conversation, not before.
Project-based
A defined scope, an agreed timeline, and a fixed quote. We scope it after discovery, so the number means something.
Best forA one-off audit, upgrade, or stabilisation pass.
Ongoing retainer
A recurring block of our time each month for continuous work — improvements, support, and whatever the roadmap needs next.
Best forThe default here — continuous care with agreed response times.
Time & materials
Billed for the time the work actually takes. Best when the scope will genuinely move as we learn.
Best forAd-hoc fixes on an inherited codebase.
Maintenance & Support, specifically
The questions teams ask us most about this kind of work.
The rest of what we do
Most projects touch more than one of these. We cover the whole build.
Need someone to own it?
We'll audit what you have and scope the ongoing work.