Skip to main content
A new merchant calls. They just switched accounting software and want their JTL-Wawi (also known as ERP) orders to flow into it automatically. You know exactly what they need, because you’ve built it four times already.So you do what you always do. You copy the last project, adjust the field mappings, and book a day to install it on their server. You set up remote access, test it, hand it over, and add a fifth deployment to your maintenance list.It works. It pays. But somewhere around install number five, it’s worth asking a different question: what if this build was an install instead of a project?That’s what Cloud Apps make possible. In this article, I’ll walk through how to take an integration you keep rebuilding and turn it into an app you build once and install for every client. That includes the parts that stay the same, the parts that change, and the honest trade-offs.If you’re new to Cloud Apps, start with What are JTL Cloud Apps? first. This article assumes you know the basics.

What Per-client Integrations Really Cost

Custom integrations are a perfectly sensible way to build a business. A client has a specific problem; you solve it, charge for the work, and support the solution afterward. The problem starts when you solve the same problem over and over again.Per-client integration workflow: one deployment per clientEvery installation is its own maintenance window. Five clients running your accounting export means five places where something can break, each with its own server, Windows updates, and security software.Every JTL-Wawi upgrade is a small project. A client moves to a new version, and someone on your team has to check that the integration still works as expected. Then you do it again for the next client, and again with the next release.Support starts with access. A good part of a support call can disappear before you even look at the problem. You need VPN access, remote desktop access, or someone at the merchant to give you access to the right system. Sometimes, the person who knows the admin credentials is the one person who happens to be on holiday.Knowledge stays with people. The developer who built the original integration often knows the details that never made it into the documentation. They know why one client has a different mapping or why a particular workflow works the way it does. When that developer leaves, that context can leave with them.Revenue is tied to hours. If you want to grow revenue from the same integration, you often need more implementations, more custom work, or more support. The integration can be valuable, but your ability to scale it is still tied to the people maintaining it.None of this means the model is broken. It has built a lot of good businesses, maybe including yours. But it has a ceiling, and most agencies hit it without noticing.

You may Already have a Cloud App

You do not need to invent something new from scratch. Start with your existing projects. Take your last 20 JTL projects and group them by the problem they solved, rather than the client they were built for.You’re looking for four signals:
  • The same request keeps coming back. Three or more clients asked for roughly the same thing.
  • The logic stays the same and only the configuration changes. Different field mappings or thresholds, same core process.
  • The problem isn’t tied to one merchant’s quirks. It’s something any merchant in that situation would need.
  • Clients would buy it without a meeting. If a merchant saw it in a store, they’d understand what it does and why they need it.
For example, you might find that your agency has repeatedly built:
  • accounting exports
  • shipping and label workflows
  • custom reporting dashboards
  • marketplace-specific data preparation
  • stock and purchasing alerts
If a group in your list ticks all four boxes, you’ve found a product. You’ve just been selling it as a service.

Your Clients Keep Using JTL-Wawi

One of the first questions you may have is: Does moving the integration to the cloud mean my client has to change their ERP?No.JTL-Wawi stays where it is. The merchant continues using Wawi as their ERP, while JTL Cloud provides the connection that allows a Cloud App to work with it. JTL describes this as a hybrid setup: Wawi continues to run locally, while cloud services and apps connect to it through JTL Cloud.Connecting takes two steps on the merchant’s side:
  1. Connect Wawi to JTL Cloud. In the Admin menu, under JTL Cloud, they click Connect and sign in with their JTL ID.
  2. Start the JTL-Wawi API with the cloud connection switched on. They do this in the JTL Administrator.
The only requirement is JTL-Wawi 2.2.0 or higher. The connection guide covers the full steps. For an agency, this is good news twice over. Your existing clients are already the right audience. And helping them get connected is onboarding work you can offer as part of your service.What stays and what changesMoving from client-specific integrations to a Cloud App is less of a rewrite than it might sound. Much of what you have already built and learned still applies.The biggest change is the packaging. Instead of maintaining a separate integration for every customer, you build one application that can serve multiple merchants.Cloud App workflow serving multiple clientsThe access model changes too. Cloud Apps use defined API scopes, so you specify which JTL resources the app needs to access. Client-specific permissions and configuration can then be handled without changing the core application.So the value is not in throwing away your existing integration. Your JTL knowledge, business logic, and understanding of merchant workflows are still the foundation. The Cloud App gives you a way to package that work for more than one customer.

The Path: Start with One Client

You do not need to turn your whole business into a product overnight. A practical way to start is with one client you already know well.Step 1: Start with a willing client. Pick an existing client whose integration you understand and who is comfortable connecting their Wawi to JTL Cloud.Step 2: Turn their integration into a private app. Private apps can be shared with specific merchants using activation codes, without going through the public App Store reviews. The client’s workflow can stay largely the same while you move the integration into the Cloud App model.Step 3: Add a second client. This is where you find out which parts of the integration are genuinely reusable. Differences that once lived in custom code now need to become configuration. That is the step where a client project starts becoming a product.Step 4: Publish to the App Store. Once the app works across different merchant setups, you can submit it for review and make it available to a wider audience.The important part is that you do not have to stop doing client work along the way. Your existing projects can give you the use cases, feedback, and revenue you need to build the product.

How your Business Changes

The shift is not from services to products. It is from building the same solution repeatedly to getting more value from something you have already built.With a client-specific integration, most of the revenue comes from implementation and ongoing support. With a Cloud App, the same solution can be installed by multiple merchants. For App Store apps, JTL handles the merchant billing, while you manage your payouts through Stripe connect.Your services business still has a role. It can move toward work where your expertise adds more value:
  • Onboarding: helping merchants connect Wawi and configure the app.
  • Customisation: handling requirements that fall outside the standard product.
  • Consulting: helping merchants improve their workflows around the app.
There is also a useful side effect: an app can become another way for potential clients to discover your agency. Someone may install the product for a specific problem and later need help with a larger project.

The Trade-offs

A Cloud App also comes with responsibilities that you may not have had with a one-off integration.You own the application. Hosting, uptime, monitoring, and maintenance become part of the product. Managed hosting and basic monitoring can take care of much of the operational work.You build for multiple merchants. Your app needs to keep each merchant’s data and configuration separate. The JTL tenant becomes an important part of how you map a merchant to your own application data, so it is worth getting that model right early.Public apps go through review. App Store distribution adds a review step. Starting with a private app lets you validate the product with real merchants before taking it public.The merchant still depends on JTL-Wawi. Your Cloud App can only work with JTL-Wawi data when the required JTL-Wawi API connection is running. Make this part of onboarding and your support process so merchants know what to check if their connection stops working.These are not unusual problems for a product business. They are simply the responsibilities that come with moving from maintaining individual integrations to maintaining an application that serves multiple merchants.

Where to Start

If you’ve read this far, you probably already have an integration in mind. Here’s how to take the first step:
  • Read What are JTL Cloud Apps? if you skipped it, to see what the platform can do.
  • Follow the connection guide to connect a test Wawi to JTL Cloud.
  • Work through the quickstart to get a first app running inside the Cloud ERP.
  • Pick one client and plan their integration as a private app.
And if you’re coming to JTL Connect, bring the integration you’ve built most often. We’ll sketch it out as a Cloud App with you.