Gamefoundry was the starting point — a formal R&D programme with Fraunhofer Portugal, co-funded by QREN and FEDER, that gave the team a structured way to solve hard problems before they became production problems. It was an accelerator in the literal sense: it compressed learning that would otherwise take years into a focused project. The research paper from that period documents the architecture and what the data showed.
GFoundry is not Gamefoundry. The platform that runs today was rebuilt, extended, and rethought many times over a decade. What remained constant was the direction: an engagement platform for people at work, with gamification and data at the core.
What the platform actually does
GFoundry is an HR and people management platform built around gamification, AI, and personalised employee journeys. The premise is that engagement is not a metric you measure — it is something you engineer into the daily experience of work. Most HR platforms treat engagement as an output. GFoundry treats it as an input: a set of behavioural mechanics that, if designed correctly, change how people interact with their work, their team, and their development.
The platform covers learning and development, talent management, performance, onboarding, and internal communication. Each module connects to the same underlying data layer. That shared data layer is what makes personalisation possible — not personalisation as a marketing word, but as a concrete technical capability: different content, different challenges, different progression paths for different employees based on their role, history, and behaviour.
The virtual assistant — Gi — is the interface for that personalisation. It uses machine learning to surface what each employee needs, when they need it, and in a format that fits how they actually use the platform. The ambition is that the platform adapts to the employee, not the other way around.
Gamification as a mechanism, not a feature
The distinction matters. Most platforms that call themselves gamified have added points, badges, and leaderboards on top of an existing product. That is gamification as decoration. It rarely changes behaviour because it does not change the underlying structure of how people interact with the system.
GFoundry was designed from the start with gamification as the structural layer — the mechanism through which learning, performance, and development workflows are delivered. Challenges are not optional extras. Progression systems are not cosmetic. The data from the Gamefoundry R&D programme showed that behavioural mechanics, when properly integrated into the experience, produced measurable differences in completion rates and return engagement. That evidence is what justified building the product this way rather than adding mechanics after the fact.
Multi-container: what it means in practice
Enterprise clients are rarely monolithic. A large company typically operates multiple subsidiaries, business units, or brands — each with its own culture, its own HR processes, and in many cases its own identity. A platform that forces all of them into a single shared environment, with a single brand and a single configuration, does not work for that structure.
Multi-container architecture means each sub-company gets its own container: its own branding, its own user base, its own configuration, its own data scope. From the outside, each subsidiary has its own experience. From the inside, the platform is one system. The client’s IT team manages one integration. The HR team manages one contract. The data is isolated where it needs to be isolated and shared where sharing creates value.
This is technically harder to build than a single-tenant product, and harder to maintain than a flat multi-tenant one. It was a deliberate early decision. Building for it later, after the data model and permission system are already in production, is far more expensive than building for it first.
26 languages
Localisation in enterprise SaaS is usually an afterthought — something you add when a client in a new market asks for it. 26 languages is not an afterthought. It reflects a product decision made early: that engagement cannot be fully separated from language, and that language cannot be fully separated from culture.
An employee using a platform in their native language has a different experience from one navigating it in a second language — not just in comfort, but in how they process challenges, respond to feedback, and engage with content. At the scale of a large enterprise, that difference is not small.
Integration as connective tissue
GFoundry does not replace the systems of record that large enterprises already run. It connects to them. Employee data flows in from the HRIS. Performance data flows out to management reporting. Learning completions are recorded against the talent management system. In some deployments, GFoundry connects to CRM platforms to align sales team engagement with pipeline data.
That model — platform as connective tissue rather than platform as replacement — requires an API layer built to enterprise standards. It also requires a different kind of implementation relationship with clients: one that involves their IT teams, their data governance processes, and their existing vendor landscape. The integration work is invisible in the product. It is not invisible in the implementation.
The competitive context
SAP SuccessFactors and Workday are built around process efficiency and operational control — comprehensive platforms that cover HR, finance, and planning for large enterprises already inside their ecosystems. Cornerstone OnDemand has built its position around LMS and structured learning. Talentia focuses on HR administration. Factorial targets SMEs with simple workflows.
None of them put gamification, AI-driven personalisation, and multi-container architecture at the centre of the product. GFoundry competes in the same enterprise segment as platforms built by companies with teams many times larger than ours. The differentiation is not just feature-level — it is architectural. A full comparison is at gfoundry.com.
The decisions we’d unmake
Ten years is long enough to accumulate real opinions about what you got wrong. Not every decision compounds well. Some architectural choices that seemed pragmatic created drag. Some features built because clients asked for them added surface area without adding value. Some things deferred because they were hard stayed deferred too long.
We’ll write those up properly — with specific examples, not generalities. That is the kind of post this site exists for.