From 3 Business Days to 90 Seconds: How ayedo Fully Automated the Demo Process of an ERP Provider

Product demos are a necessary sales component for many SaaS companies. For Signalwerk, they were the central growth driver—and simultaneously the biggest operational bottleneck.

Signalwerk develops a modular ERP solution for medium-sized manufacturing companies. Production planning, inventory management, quality management—complex processes that cannot be explained on a PowerPoint slide. The product needs to be experienced.

And this is where the problem began.

Initial Situation: A Sales System Dependent on the Development Team

Signalwerk conducted between ten and fifteen live demos weekly. Each required its own environment to simulate realistic customer scenarios.

The technical reality behind this was anything but scalable.

Two dedicated virtual servers served as demo infrastructure. New instances were set up manually: copy the database, adjust the configuration, create a DNS entry, import test data. Ideally, this took about 45 minutes—provided no other demos were blocking resources.

The system had several structural weaknesses.

Firstly, parallelism was severely limited. More than six instances at the same time were not possible. During campaigns, trade shows, or increased sales activities, this regularly led to delays. Prospects waited days for a demo—in a market where speed determines whether a deal is closed or lost.

Secondly, the demo data was often outdated. The test database was updated irregularly. It happened that new features in the product were already live but not available in the demo system. Sales presented a version that was two releases behind.

Even more problematic was the lack of isolation. Multiple pre-sales employees worked in parallel on the same servers. Changes in one demo sometimes affected another. In some cases, this led to unexpected effects during live appointments.

And finally, there was the organizational dependency: Each new demo request was submitted as a ticket to development. The average lead time was three business days. Around 20% of a senior developer’s working time was spent maintaining demo environments—a task without direct product value.

What started as a side issue developed into a strategic problem. The sales manager estimated the lost revenue due to postponed or canceled demos at several hundred thousand euros annually.

The Turning Point: Thinking of Demo Infrastructure as Part of the Product

For us, it was clear: The problem was not a lack of hardware. It was a lack of platform logic.

A demo environment is essentially nothing more than a short-lived, isolated product instance with a defined lifecycle. This is exactly what Kubernetes is designed for—if used consistently.

Our goal was not just automation. Our goal was self-service.

The Solution: GitOps-Based Demo Platform on ayedo Managed Kubernetes

We built a fully automated demo platform for Signalwerk—operated on the ayedo Managed Kubernetes infrastructure.

The central idea: Each demo is declaratively described. No manual steps, no SSH sessions, no individual configuration.

GitLab as a Self-Service Interface

The definition of a demo environment is stored as a manifest in the GitLab repository. Namespace, application, database, ingress, subdomain, module configuration—everything is declaratively described.

Sales triggers the creation via a simple pipeline. A form asks for the customer name, desired modules, and duration. Technical knowledge is not required.

With the trigger, a new manifest is automatically generated and versioned.

ArgoCD as Deployment Engine

ArgoCD monitors the repository. As soon as a new manifest appears, the complete demo environment is automatically deployed in the Kubernetes cluster.

Within about 90 seconds, a fully functional instance is created—including the latest product version, isolated PostgreSQL database, and individually generated subdomain.

No human intervention is required.

Namespaces for True Isolation

Each demo runs in its own Kubernetes namespace with defined resource limits.

No mutual influence. No configuration collisions. No shared databases.

This also means: During a trade show, 40 or more instances can run in parallel without affecting workloads.

Automatic Lifecycle Management

Each environment is given a defined lifespan upon creation—typically 72 hours. After expiration, the namespace is automatically deleted, including the database and DNS entry.

This prevents zombie instances and ensures clear resource usage.

Authentik for Access Control

Sales staff log in via SSO. External prospects receive temporary, time-limited access.

This makes the platform not only functional but also securely protected.

The Strategic Effect: Sales Becomes Independent

The biggest difference was not the speed. It was the decoupling.

Sales can now independently create, reset, or extend demo environments—without a ticket, without waiting, without coordination with development.

This relief had an immediate effect.

Expansion: “Test Now” as an Automated Lead Channel

After the internal demo platform was stable, we made the same mechanism available for the website.

Prospects can now independently provision a personal test instance. The platform automatically generates an isolated environment with current test data and time-limited access.

This fundamentally changes the sales process: Leads no longer come with just interest, but with product experience.

Result: A Bottleneck Disappears—and Growth Becomes Scalable

The provisioning time decreased from an average of three business days to about 90 seconds.

Parallelism is virtually unlimited. During trade shows, over 40 instances ran simultaneously without performance issues.

Each new demo is automatically based on the latest product version. Sales always shows the latest state—including new modules and features.

The development department was completely relieved from demo operations. The previously tied-up senior developer now works exclusively on product features.

And most importantly: The sales process is no longer dependent on infrastructure. Demo availability is no longer a risk but a competitive advantage.

Why This Approach Works

Many companies view demo environments as a side system. In truth, they are part of the product.

Those who operate demos manually scale linearly with personnel. Those who operate demos as declarative workloads on Kubernetes scale with infrastructure.

GitOps makes the difference: Each environment is reproducible, versioned, and automatically deployable. This creates speed without loss of control.

Result in One Sentence

With the ayedo Managed Kubernetes platform, Signalwerk transformed its demo process from a manual bottleneck with several days’ lead time to a fully automated self-service system—simultaneously increasing sales speed, conversion rate, and developer productivity.

Call to Action

If you conduct demos week after week and your sales team still has to wait for environments, it’s not a “small ops problem.” It’s a revenue lever stuck in manual labor. Every postponed demo extends the sales cycle, every outdated demo version costs credibility, every dependency on the engineering team eats up feature capacity.

With a GitOps-based demo platform on ayedo Managed Kubernetes, you can eliminate this bottleneck from the process—and make demos a scalable self-service:

Sales starts isolated instances in minutes or seconds, each demo runs on the current version, expired environments clean themselves up automatically, and “Test Now” turns from a nice website button into a real lead channel.

If you want to decouple your demo process from the ticket system, talk to us. We’ll show you in a short workshop how a demo platform for your product can look—including architecture, security/SSO, lifecycle management, and clean GitOps integration.