Wartezeiten.APP: We almost quit — now we’re going full throttle

For almost 10 years, Wartezeiten.APP has shown you how long you’ll have to wait in line at theme parks across Europe. This year, though, we had to ask ourselves an uncomfortable question: Does this project even have a future? Here’s how we got there and what we decided — and why this goes far beyond our own site and matters to every theme park fan.

When we launched Wartezeiten.APP, we had one clear, simple goal: All the important data on your favorite parks should be quick and easy to find in a single place. We were a highly motivated team back then. We still are. As many of you know, we programmed our website entirely ourselves, over countless nights and with great attention to detail. We also run the connections to the individual parks completely on our own. We don’t use third-party data sources or external APIs such as themeparks.wiki or queue-times.com. We built every single interface to every single park ourselves, and we maintain them ourselves, too.

That’s why there is so much technology behind Wartezeiten.APP today. To handle our huge volumes of data, we now operate entire server farms, plus plenty of additional infrastructure that retrieves, checks and processes data around the clock. We work 24/7 to make sure you always get the most up-to-date data and that the interfaces run reliably. Sounds dry? Here’s what it means in practice: When a park switches over its app or its systems overnight, we often sit at our desks until the early morning hours. That’s the only way you can check wait times as usual the next day.

In principle, we welcome every site that covers theme parks. Competition is good for business, and in the end you as park fans benefit. Since the start of this year, however, we have been watching a development that worries us more and more. Countless new websites have launched that are very similar to ours, some even with similar names. Many of them were clearly built in no time with the help of AI to grow their reach as quickly as possible. That’s perfectly legitimate, at least at first. But honestly, this trend devalues the years of work and the heavy investment that go into real programming. A website created in a few hours with AI suddenly competes on equal footing in search engines with a project backed by 10 years of development.

What matters most to us, though, is a problem most users never even notice. We explicitly welcome public APIs from various providers; after all, we offer one ourselves. Projects such as themeparks.wiki and queue-times.com do valuable work for the community. What concerns us is how the landscape as a whole has developed. To find out more, we looked at 26 wait-time websites and apps. For 18 of them, the data source could be clearly identified. The result: 15 of those 18 services, or more than 80 percent, get their data from just three API providers, namely queue-times.com, themeparks.wiki and our own public API. Around three-quarters rely on queue-times.com or themeparks.wiki alone. Only three services demonstrably collect their data themselves.

For you, this has a very practical consequence. Many sites that seem independent and different at first glance show exactly the same data from exactly the same source behind the scenes; often only the design differs. That is precisely the dependency we consider dangerous. A single outage is enough: If one of the big providers goes down, numerous sites stop showing data all at once. If queue-times.com and themeparks.wiki were unreachable at the same time, our sample suggests that around three-quarters of all sites with an identifiable data source would be left without wait times. On top of that, errors multiply. If a central source delivers incorrect or outdated data, every connected site displays the same incorrect data, and there is no longer any way to compare or cross-check.

What’s more, someone else makes the rules: If an API provider changes its terms of use, introduces fees or shuts down its service, all dependent sites face the end at the same time, and their operators have no say whatsoever. And in the end, real diversity is lost. If collecting your own data no longer pays off financially because AI sites with borrowed data are siphoning off the reach, eventually no one will build their own interfaces anymore. What’s left is a monoculture with many facades and a single foundation. This pattern is by no means limited to theme parks: In many corners of the internet, hundreds of seemingly different services are springing up right now, all living off the same few sources.

Of course, we could take the easy way out and go all in on AI. But we’re convinced that AI can help with development — it just shouldn’t be doing everything on its own, not by a long shot. Many operators don’t really know what the AI has programmed for them, and the code is nevertheless adopted and published without review. That can lead to security vulnerabilities, faulty data and sites that nobody truly understands or can maintain. When something then breaks, the know-how to fix it is often missing. We, on the other hand, want to keep knowing what happens in our code, and we want to stand behind it.

We don’t want to complain, but we do want to be honest with you: All these developments have left their mark. Our user numbers have dropped noticeably this year. At the same time, the costs of servers and infrastructure keep rising, and the countless hours of work have long since stopped being covered. So we reached a point where we had to seriously ask ourselves whether to keep going. Yes, we thought about quitting, and it was not an easy decision. We love our “baby,” but love alone doesn’t pay the server bills.

Still, our answer is clear: We’re not giving up, we’re going full throttle! We know we have an incredibly loyal community, and many of you have been with us for years. That’s exactly why we decided to keep going, and to do it properly, more than ever. For months, our developers have been working not only on our iOS app but also on a complete rebuild of our back end. The huge database behind the scenes is being modernized and restructured from the ground up, with new technologies and new interfaces. At the same time, Wartezeiten.APP is getting a comprehensive redesign with many new features, such as comparisons of different time periods and direct comparisons between parks. Handy for anyone planning their next park visit. We are putting many hundreds of hours of work into the new database and the redesign.

And that’s far from the end of it. After the switch, we will add new features step by step and fill in missing data on our parks. These include show times, dining information and wait times after park closing, meaning for cases when the park has officially closed but individual attractions are still open. That last one should especially please everyone who likes to squeeze in one more ride right up to the end of a long park day.

You won’t have to wait much longer: The new database and the revamped website will go live shortly. We are in the final round of testing and can’t wait to hear your reactions. After that, we will keep a close eye on how everything develops. We hope this will also win back many users who may have lost track of us recently.

Now it’s your turn, because we can’t do it without you. Tell your friends, your family and your park community about Wartezeiten.APP, share us in forums, groups and on social networks, and get in touch if you’d like new features, if something isn’t working or if you simply want to share feedback. Every recommendation and every visit helps us keep this project alive. Show us that real, independent, handmade work still pays off in 2026.

We’re here. We’re staying. We’re continuing to invest. Thank you for being with us!

Your Wartezeiten.APP team