Before Digital Nomads, There Were Distributed Tiger Teams

When people speak today about digital nomadism, they usually imagine laptops on café tables, co-working spaces, and remote work as a lifestyle choice.

That is not what happened here.

The early JUBAP.Net lineage was shaped by a much more demanding form of distributed work: high-technology information management, mobile infrastructure, remote expert coordination and operational continuity across borders, long before remote work became normalised.

The founder, Iván Abril Palma, had previously worked as Information Manager in Nokia’s distributed R&D environment in Barcelona. This was not simply about carrying a laptop. It involved the information, infrastructure and coordination logic required to support advanced research and development teams working across mobility, communications and distributed technical environments at the edge of what was possible at the time.

That experience became one of the foundations of the JUBAP.Net method.

What later appeared as digital nomadism was, in reality, an early form of distributed operational intelligence: the ability to keep technical work, expert collaboration and delivery continuity alive across countries, networks, servers, forums and unstable infrastructure.

From Nokia Distributed Intelligence to Practice Networks

After Nokia, the founder did not simply leave a corporate role and begin working remotely as an individual consultant.

He continued to operate through networks of experts, technical forums and distributed communities where specialised knowledge could be found, tested and integrated into real work. These were not casual online conversations. Around those forums, relationships gradually became working structures, then project teams, then continuity-based practice nodes.

This was one of the early roots of JUBAP.Net’s later operating model: finding capability wherever it existed, integrating it into disciplined work, and coordinating it across distance without losing operational responsibility.

In the United States and Canada, where part of the work was delivered, this was already advanced for the time. The same was true in frontier and transitional environments such as Cuba and the Bahamas, where infrastructure constraints made distributed coordination not only innovative, but necessary.

The result was not a remote lifestyle. It was the slow creation of a distributed practice network.

Virtual Servers Before the Cloud Became Normal

As the work matured, the distributed model became more technical.

The teams began integrating remote infrastructure, virtual servers, shared environments and secure coordination mechanisms that allowed people in different locations to work on systems with continuity. This was before cloud platforms, SaaS ecosystems, collaboration suites and remote-first delivery became standard business vocabulary.

Yes, it was possible.

But it required technical discipline, improvisation under control, and a strong understanding of how information, infrastructure and people had to remain aligned even when the physical team was not in the same place.

This capability later became essential for GEPLAN.

GEPLAN was not built only by people sitting in one office. It required field observation, remote development, distributed support, infrastructure adaptation, operational feedback loops and continuous contact between developers, consultants, field teams and decision-makers.

This was the origin of what JUBAP.Net would later recognise as its early agile tiger teams.

Early Agile Tiger Teams Before Agile Became Corporate Language

At the time, the team did not call this “agile” in the current corporate sense.

The closest formal reference was extreme programming. But the JUBAP.Net practice went beyond programming. It combined short delivery cycles, direct field observation, remote technical coordination, rapid prototyping, operational reengineering and intense proximity to the users who actually carried the process.

It was distributed work with maximum operational closeness.

That combination became distinctive: mobile teams, remote specialists, local operators, consultants and developers working as a single adaptive unit around the problem, not around a rigid project plan.

These early agile tiger teams were not created for speed alone. They were created to survive complexity.

They could enter an unstable environment, understand the real operating constraints, identify hidden behaviours, adapt the system quickly, reengineer processes, train users and keep the operation running while the transformation was still being built.

This is a central JUBAP.Net pattern: distributed intelligence combined with field intimacy.

Building JUBAP.Net From Motion

The company that would later create the GEPLAN suite emerged from this remote-first and border-crossing practice: Corbera Networks as an engineering and consulting vehicle, and The Integral Management Society as the broader framework to align technology with whole-enterprise management.

Those years were not glamorous. They involved moving between countries, carrying equipment, connecting through unstable networks, building trust through forums and expert circles, and calculating each trip with precision. The work depended on transport, connectivity, servers, cash flow and human reliability.

That discipline later translated directly into GEPLAN’s operational rigor.

In GEPLAN, every module had to justify itself in the field: fuel saved, inventories stabilised, trips scheduled, trucks kept available, maintenance anticipated, reports trusted and operational decisions improved.

The same logic that had sustained distributed work across countries was now applied to industrial operations under pressure.

Nomadism Applied to Industrial Ground

What makes the JUBAP.Net story unusual is that this early mobility did not remain in the virtual world.

It ended anchored in one of the least “nomadic” contexts imaginable: the dense, high-pressure industrial ecosystem around PEMEX in northern Veracruz.

From there, the founder and the wider team began to design what would become the JUBAP.Net GEPLAN suite: an industrial operating environment for logistics, maintenance, fleet control, volumetric fuel management, warehouse control, procurement, administration and decision support.

GEPLAN was built in Delphi and later partially in .NET, with MySQL and PostgreSQL databases, at a time when neither SaaS, IoT platforms nor commercial APIs were standard tools.

To connect fleets, fuel dispensers, telemetry devices, workshops and administrative processes, the team relied on reverse engineering, custom integrations and RPA-style automation long before RPA became a recognised category.

The method was not to design from abstraction.

Engineers and consultants sat in dispatch centres, workshops and field bases to observe how operations actually behaved before encoding them into software. At the same time, distributed contributors and remote technical support allowed the system to evolve continuously.

This was the core paradox: the team moved, connected and adapted so that the industrial system could finally become stable.

A Suite That Travelled With the Organisation

Although JUBAP.Net GEPLAN was technically installed on-premise, its delivery felt remarkably close to what would later be recognised as SaaS.

It was modular, configurable and always deployed together with organisational consulting. Each client engagement began with job-profile mapping and process discovery, then moved into reengineering and, frequently, ISO 9001 certification as a baseline for disciplined operations.

The software “travelled” conceptually with each organisation’s maturity level, adapting to real processes instead of imposing a rigid ERP shell.

Commitments to clients were framed not around feature lists, but around business KPIs: reducing inventory losses, improving scheduled trip efficiency, tightening fuel control and stabilising fleet availability.

In practice, the real contract was with the value created in the field, not with the interface.

From Distributed Teams to Stationary Intelligence

Today, JUBAP.Net describes itself as a complex systems intelligence center specialised in Operational AI Integrity and early warning regime change detection.

That capability did not appear suddenly with modern AI.

It emerged from years of working with distributed teams, unstable infrastructure, remote experts, local operators, field constraints and mission-critical industrial systems where every error had operational consequences.

The capability to sense emerging systemic shifts, identify hidden patterns and anticipate structural breaks is not an abstract academic exercise. It is the distilled result of working inside volatile environments where logistics, energy, communities, infrastructure and institutions intersected.

In that sense, JUBAP.Net’s early mobility was never about escaping into a lifestyle brand.

It was about gathering, coordinating and operationalising distributed intelligence until it could be engineered into systems that remained stable under pressure.

The people moved.

The teams connected across distance.

The infrastructure adapted.

And the industrial brain became stationary enough to support operations that could not afford to stop.

This is the origin of the JUBAP.Net early agile tiger team model: distributed intelligence, maximum field proximity, rapid adaptation and operational accountability under real conditions.