Zudy VINYL Review

Very flexible, easy, and fast, but it has trouble handling large data sets


What is our primary use case?

We use VINYL when none of our other systems solves the business need that's being asked for. We've used it for a lot of different things. We've got an event management application, we have a compliance tracker, previously we used it for a work-request application. We use it for custom-reporting, and we've also been using it as a way to bring together a couple different systems which we call our "Customer 360," where we can go and get an idea of a customer and all their related entities.

How has it helped my organization?

Since we're still primarily on an AS/400-based system, any client-facing output has some limitations using output from that system. What has been a great process-improvement and improvement in business communications - giving us really good client-facing communication - is having our Zudy applications take information from our AS/400, consume that information, and make it look nice. It turns it into something that we're happy to send out to our customers, something that's a lot more contemporary. It enables us to use a little bit more graphic design and it looks new and fresh.

What needs improvement?

One of the troubles we have sometimes is the amount of data we're processing within the applications. That can really add a lot of "laggy-ness." That's an ongoing struggle we're going to have while we use it. It doesn't happen for all our applications, only some of them that are heavy on the reporting. 

And where we can get a more contemporary client-facing output and PDF version, it's still somewhat limited as to what we can do with those templates.

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

We don't really have any crashes, so that's always good. You can get an error if you're trying to do too much at once, before the system can catch up. That's understandable. 

If we do find anything that turns out to be a real error, it's super-quick to go in and figure out what the error is. You make a pretty simple change to correct it. The different layers within the platform for each application are pretty linear. You've got the same three layers: the cosmetic layer, the business-rules, and your data layer. It's always going to be somewhere in one of those layers that you find the issue or figure out where you need to make a change. You're not having to really go anywhere else to do that. It's pretty centralized.

What do I think about the scalability of the solution?

The greater the amount of data we're trying to use, the more bogged down the applications will get. It does reach a point where it's very noticeable how slow the application is moving because of the amount of data it's trying to use.

For example, sometimes it can be five minutes to refresh an application that's only producing some 75 PDFs. That seems a little slow. We've got another application that's producing about 230 reports - they're all pretty similar - and that can take upwards of ten to 15 minutes to process. One of the reports we have to access, it's our own fault that it takes so long to process because we've got so many data fields that we're aggregating together. But in general, the more data you're working with the slower it goes.

How is customer service and technical support?

We haven't really needed tech support. Because the maintenance is so small, when something goes wrong we've got our contracted developers who usually jump on it right away. They can find and fix the problem that same day.

How was the initial setup?

I wasn't part of the initial setup so I'm not sure what steps it took to get there but I think the complexity of the setup depends on what you're using it for. We've got a lot of different data sources coming together from a lot of places, so I imagine that getting that all together was a notable effort. We definitely had to work through permissions, allowing access on our server, allowing access on their server. There is a good amount of setup. I don't know how long it took.

What about the implementation team?

It was us with Zudy handling implementation of the platform.

What other advice do I have?

Definitely make sure that internal staff learn how applications are built. Zudy does provide free training and I highly recommend it so that you can bring all development back in-house, be a little bit more self-sufficient with it and not reliant on Zudy. From the very beginning, learn the platform as much as possible and learn from Zudy developers that you work with.

The entire time we've had VINYL, we've had Zudy developers contracted to our company, so it's actually Zudy employees who have been doing the development. I've never actually built one of our own solutions but I did attend a Zudy training session to learn how to build solutions. Our applications are so much more advanced than what we covered in the training but I can see how it all fits together. It's like breaking apart coding and development into an ultra-configuration tool.

I wouldn't say that it's relatively simple. You do have to have a developer mindset about bringing all the pieces together. I wouldn't say someone brand new could be given this tool and build an application. You do have to have some understanding of how the different layers in the VINYL platform work together. And even then, there are just so many more advanced features that you can use that really get into how we're using it. As far as anything really basic goes, even then you would need some level of training to be able to use the tool.

In terms of how many users are currently using VINYL in our organization, most of our applications have been targeted to very niche users. Originally, it probably wasn't more than 50 or so, but we've been working on soft-releases and rollout of one of our other applications for that "Customer 360" view and, eventually, the entire company will have access to that. We have close to 400 employees.

We're an insurance company so the roles of the VINYL users are anything and everything. For our event management, there's an underwriting tool and that's used in agency relations. We've got another tool used by underwriting. That department has been the primary user. We've got an application that simplifies calculations of insurance premiums for very very specific policy types. Our underwriting compliance team use it to track their filings. We have a deductible-billing application, which is one of the ones that is consuming information and putting it into a new, modern output. That's used by our finance department. There's another agency relations application we use that tracks progress of our top agents and it tracks extra commission that we can provide to those agents. And the "Customer 360" can be used by any department, mainly our underwriting and claims departments. It really is flexible.

Maintenance is very minimal. With our live production applications, they just don't break, which is great. We love that. There's zero-to-little maintenance required.

We've got quite a few applications in production now and we've got more in development. There are a few more on the list to go into development. We've still got a sizable backlog to work through.

Overall I would rate it a seven out of ten. I love how customizable it is, how easy it is, how fast it can be. The downside is that scalability and the troubles dealing with large data sets.

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Learn More about Zudy VINYL

No-Code Development - Stay Informed

1 Comment
UserUser

Thanks for the review. I'm curious what you are considering a large dataset as we could have the same issue. But I'm just talking about around 5 million records in our primary table. You may be dealing with tens of millions.

12 May 19
Guest
Sign Up with Email