Magic xpa Application Platform Reviews

We use this solution to develop ERP software for our clients. We have a portfolio of more than 100 clients, from small companies to big ones. I have several enterprise clients, and all of them are running the xpa ERP system. We use xpa to build for the Financial Department, Sales Department, HR, Salaries Department, and so on.

xpa gives us a fast development speed. The most important thing is that it is oriented toward user functionalities.

First, in my personal opinion, being a developer myself and working with web and mobile technologies, I think they're trying to cover all the sectors, and that's the problem. They want to be one toolbox for everything, but primarily, we are using xpa to develop desktop applications, and in that area they're lacking functionalities, flexibility, and modern stuff.

MSC is marketing xpa as a .NET-based solution, but their .NET integration is lousy. For example, in Visual Studio, you put a control, you right click, and you set everything. In xpa, they're using Visual Studio as a basis of the development tool, but you cannot do what I just described. There's also poor integration of third-party tools because, for example, to put something together using the very popular .NET framework and components framework, it takes me at least three times longer than it should. 

We started using this solution because it was fairly easy, and 10 years ago, the speed of development was incomparable to any other tools. My employees can develop and deploy something in a matter of hours. My clients buy from me because we can do everything very fast, but the applications we are currently developing with xpa are kind of outdated. Not the functionalities, because we can do almost everything, but the UI and UX and the mechanics of the application are outdated. The problem is that their grid functionalities are very bad in general. For example, in order to have the ribbon bar like the one you have in Word or Excel, we have to do all kinds of gimmicks and purchase external libraries. That's one of the problems, and that's something I would really like to change. 

I really don't care about the web integration with xpa. I don't need it to be a tool for the API, for the backend, for the frontend, or for mobile applications. I want xpa to be a very powerful tool for desktop applications.

I started using one of the first versions of Magic almost 30 years ago. They've evolved since then, and xpa is the latest iteration. 

This is a stable product.

The solution is scalable. 

The online documentation is okay. The community is not that big because not many users are using xpa because of the pricing, but somehow, it's easier to find the solution online by yourself than it is to communicate with xpa support. The first and second levels of support are not that good or helpful. When you get to some very serious level-three support and up, you can solve everything and they will really help you. However, you pay for this level of support, and sometimes it's just easier to find a way around.

I would still rate the support as a four out of five, because if you pay for it, then it's okay. 

When it comes to development, it's okay. When you master it, it's straightforward. Of course, it takes some time for a junior developer to understand what should go where and how, but it's nice. 

I would give the setup process a five out of five.

They have, in general, two types of licensing. They have a runtime license and a development license. I use the development license for the development process, and in order to have customers, I have to purchase deployment licenses. Those licenses can be per server, per user, per computer, or something else. There are all kinds of combinations. 

The problem is that I put time and effort into it and pay for the development license, and then I can't sell it to my client as is. They have to purchase additional licenses in order to use what I built. It's not a fair approach. Let me buy the development suite or a pack of licenses. There is no need for them to put the burden on the clients to pay for the licenses.

Even worse is how to explain that to a client. Many times I get a response from a client saying, "Your software is good, but why do I have to pay additionally? I'm paying for the software, but the prices for those licenses are quite expensive." If a company has 100 users, that'll easily add a few thousand dollars to the invoice. 

I'm trying to position myself on the market as affordable, but then I go to the client, and they say, "Actually, we have 150 users, not 70." I have to say, "Oh, okay. That means my price is not this one, the price is higher." For example, I might tell my clients, "Okay, the new seat for my application is $30 per user." Then, they have to pay $120 for the xpa license, so it's $150 instead of $30. That's a lot. They are pretty much forced to pay for the license or they cannot use the application. 

In certain cases, for example, whenever I have something simple with many users, I will go with something else and not use xpa. I would rate the pricing as a two out of five, especially if you combine the complexity of developing something modern and up-to-date with the licensing model and overall pricing. It's not possible to develop very modern Windows-based applications because of the technical limitations, and then we have the very bad and highly-priced end user licensing model.

I would recommend this solution, but my advice is to lower your expectations and focus on the pure functionalities. If you just care about the functionalities and robust environment and stability, try this solution. If you want something with a nice modern look and feel, then maybe you should consider others.

I would rate this solution as an eight out of ten.