We've been working with some clients since 2003. These long-term relationships include one lasting over 20 years and another that ran for more than a decade. Both worked the same way - we acted as their remote tech team, always on behalf of their interests.
It turns out there's a name for this now: ‘fractional product teams’.
These relationships worked in different ways. One was completely open. They knew exactly who we were, we collaborated directly with their team and it was a strategic partnership all the way through.
The other was invisible. We acted as a hidden partner for a London communications agency and had their email addresses. Their clients thought we were employees. We'd meet in coffee shops near their Soho office to go over strategy for upcoming client meetings. Then we'd sit in the actual meetings and present work under their brand.
These two different approaches had the same fundamentals and both lasted decades.
Long-Term Product Partnerships Since 2003
We've maintained sustained relationships across two models. An enterprise equity research platform serving financial analysts globally, continuously evolved since 2003 using PHP and MySQL. Simultaneously operated as white-label development team for a London communications agency, delivering projects including a major Olympic Park visitor attraction site. Built operational systems like the Wagtail UK Border Force application for dog handlers at UK ports. These partnerships existed decades before the term "fractional product team" entered the market.
Learn more: Fractional Product Team
The White-Label Work
The London communications agency relationship evolved naturally over time. It started with their own website and over time they came back for client work. At some point the arrangement shifted. We weren't being introduced as external partners. We were just their development team with email addresses on their domain. We took that role seriously as their reputation was completely in our hands.
Client meetings required some care. One stands out for a visitor attraction site at the Olympic Park. It was a major project with complex requirements. We sat alongside their account managers presenting the technical approach.
The tricky part wasn't the technical presentation; it was managing scope. The client would ask "Could you also add..." and we'd need to respond carefully. Not overcommit our own client to work outside the brief. Not undermine their relationship by saying no too directly. Find the middle ground of "That's possible as an enhancement phase" or "We'd need to assess the technical implications."
The client had no idea we weren't actually employees and that was the point. We delivered somewhere between 10 and 20 websites through that partnership. Financial services work with proper compliance requirements. Each one under their brand whilst we handled the technical work.
This model worked because the trust was genuine. They gave us their email addresses and complete access to represent them to their clients.
Twenty-Plus Years Continuous
The other relationship was completely different in structure but lasted even longer. Started in 2003 for a financial services company producing equity research for investors. They needed an enterprise publishing platform involving complex financial data, multi-user workflows, analyst tools. We built it in PHP and MySQL. Then we just kept working with them.
There wasn't a break where we handed over and they came back later. It was continuous as the platform needed ongoing work as technology changed and their business evolved.
SQL Injection Was Actually a Thing
Early 2000s, SQL injection was emerging as a serious threat. Not everyone understood it yet. We did security audits on the platform and found vulnerabilities. Database queries that concatenated user input directly.
Classic stuff now. Potentially catastrophic then. Someone could have manipulated URLs to access other users' financial data. For an equity research platform handling sensitive market information, that would have been disastrous.
We fixed it. Parameterised queries throughout. Input validation. This was just part of thinking long-term about their platform security.
When Systems Get Larger
ID management evolved as the system scaled. Early versions used simple auto-increment integers exposed in URLs. Fine when you've got a few hundred users. Problems emerged as they grew.
Predictable IDs meant people could guess other records. Sequential numbers revealed business information - "ID 1543 means we've got about 1500 reports." Automated scraping became easier.
We migrated to UUIDs for public-facing identifiers. Kept integers internally for database efficiency but never exposed them. Added proper access control layers. The platform could scale without leaking information through its URL structure.
This wasn't a crisis fix. Just strategic evolution based on understanding where they were headed.
Documentation Debt Is Worse Than Technical Debt
We learned something important about long-term relationships around year five. The biggest risk wasn't the code. It was lost knowledge.
Systems grow over time and staff move on. Someone makes a decision in 2005 that seems obvious at the time. By 2012 nobody remembers why it was done that way. Then, when a new developer looks at the code and thinks "This is weird, I'll refactor it." They break something that depended on that decision.
We hit this problem ourselves first. One of our developers left. Six months later we needed to modify something they'd built. The code worked fine but we couldn't figure out why certain constraints existed. Was it a technical limitation? A business requirement? We didn't know. It took us three times longer to make the change than it should have because we were reverse-engineering our own decisions.
That's when we got serious about documentation. Not the usual "here's how to install it" documentation, but context documentation about why decisions were made and what alternatives we considered.
For the equity research platform, this became critical. Twenty years of accumulated decisions. Financial regulations that changed over time. Workflow requirements that made sense in 2005 but looked strange in 2020. Without proper documentation, we'd have been constantly fighting our own history.
The clients benefited too. When their teams changed or new stakeholders came in, they could understand why their platform worked in certain ways. That institutional knowledge became an asset, not a mystery.
Most people worry about technical debt, but we learned that documentation debt is worse.
What Twenty Years Actually Looks Like
Between 2005 and 2010 web publishing technology was changing rapidly. Our role became advising them on where technology could genuinely help and where it wouldn't. They'd consult us on strategic questions, not just feature requests. That's what happens when a relationship runs for 20-plus years. You become internal technical leadership, not a vendor.
It turns out that everyone's now calling this fractional product teams, and we'd been doing it for 22 years without knowing it had a name.
Why They Lasted
Neither partnership had a planned end date. They just kept working. Same pattern with Wagtail UK and Border Force. We designed, built and still maintain their application for dog handlers at UK ports. Different scale but same fundamentals - build it properly, maintain it over time, keep it working as requirements change.
What Fractional Actually Means
The equity research company got strategic technical capability across two decades without building a large internal team. The communications agency offered comprehensive technical services without becoming a technical business.
That's what fractional means when you strip away the trend language. Long-term relationships that work because both sides commit to making them work.
Two Decades Before the Term
We had their company email addresses for over a decade, and met in Soho coffee shops to plan client meetings. Presented work under their brand so their clients thought we were employees.
We worked continuously with a financial services company for 20-plus years. Fixed SQL injection vulnerabilities when that was still an emerging threat. Evolved ID management as the platform scaled. Learned that documentation debt is worse than technical debt. Watched infrastructure move from physical servers to cloud hosting.
Two clients, two different models, all done before "fractional product team" was something people said.
The market's finally got a name for it. Companies still need sustained technical expertise without the overhead of hiring full teams. We've been doing this since 2003 and can now call it 'fractional product teams'.
Need an app or website?
Get in touch to discuss how we can help create an app of your own or find out how our Fractional Product Team can support your development journey from MVP through to scale.
