Dedicated product engineering teams

Fifteen years. One team. Three rewrites
of the same product — never a handover.

Some engagements aren't a project with an end date. This is the story of a sales & POS management platform we've owned as an embedded engineering pod since it ran on CGI — and still own today, running on AWS.

Talk to an engineer Read the full story

Earliest
CGI
Where the pod started
Rewrite
PHP
Rebuilt as the platform grew
Today
AWS
Cloud-native, same team
Constant
15 yrs
Zero re-tendering

The story

A product that outlived three
technology eras

Fifteen years ago, we took on engineering ownership of a sales and point-of-sale (POS) management platform for a client running on CGI — already dated technology at the time, but core to how the client ran daily retail operations.

"We didn't rotate the team out when the stack changed. We changed the stack, with the same team."

As transaction volume, store count, and feature demands grew, the same pod led a full rewrite onto PHP — not a separate migration vendor, not a handover to a new team that had to relearn the business logic from documentation. The people who understood why the system worked a certain way were the ones rebuilding it.

That pattern repeated when the client moved to the cloud: the same team re-platformed the product to be AWS-native, this time carrying forward fifteen years of institutional knowledge about edge cases, regional POS quirks, and business rules that were never written down anywhere except in the team's collective memory.

What the client bought fifteen years ago wasn't a project. It was continuity — an engineering team that has never had to be re-onboarded, because it never left.

Engagement type: Dedicated product engineering pod, embedded full-time
Domain: Retail sales & point-of-sale (POS) management
Technology arc: CGI → PHP rewrite → AWS-native, present day
Vendor changes in 15 years: Zero
Re-onboarding events: Zero — same core team across all three architectures

Why a pod, not a project

What you're actually buying

Feature	Project vendor	Dedicated pod
Knowledge after year 1	Leaves with the team when the contract ends	Compounds — same engineers own the product long-term
Major re-platform	Usually means a re-tender and a new vendor	Same team leads it — they already know why it works this way
Ramp-up on new work	Discovery phase, docs, handover meetings	Near-zero — context already lives with the team

Knowledge after year 1
Project vendor
Leaves with the team when the contract ends
Dedicated pod
Compounds — same engineers own the product long-term
Major re-platform
Project vendor
Usually means a re-tender and a new vendor
Dedicated pod
Same team leads it — they already know why it works this way
Ramp-up on new work
Project vendor
Discovery phase, docs, handover meetings
Dedicated pod
Near-zero — context already lives with the team

How we run pods

What this model is — and isn't

We Won't
pitch a dedicated pod as a way to avoid documenting decisions. Institutional knowledge in one team's heads is an asset until someone leaves — we still document architecture and business rules as we go, so continuity doesn't depend on any one person.
We Won't
promise the exact same individuals for fifteen years. People move roles. What stays constant is the pod structure and the client-specific knowledge base the team maintains together.
We Will
tell you honestly whether your engagement needs a pod or a project. If you need one well-scoped build with a clear end date, a dedicated team is the wrong shape — and costs more than it should.