The developers behind icScripts
Origin
We started as the customer.
icScripts grew out of building and running our own FiveM server, not out of a plan to open another FiveM script store.
When development began in March 2023, we were buying the same resources as every other server owner — trying to fit different scripts together, working around compatibility problems and changing systems that did not quite fit what we were trying to build.
That process pushed Sug from configuration and server editing into development. By the end of 2023, the server was reaching more than 100 concurrent players with nightly queues. The community around it went on to grow to more than 4,000 Discord members.
That experience still shapes how we build today: start with a real problem, understand what the player or server owner needs, then build the system around it.
The developers
Two developers. Two routes into FiveM.
Sug
Sug started playing FiveM in 2021 and began developing in March 2023 while building and running his own server.
Across more than 12,000 hours in FiveM, he has experienced resources from almost every side: player, server owner, community manager and developer. He ran the server, managed the community, streamed it, played it and built for it.
That experience shapes the gameplay side of icScripts — what players actually understand, what keeps an activity interesting and what server owners need once a resource is running every day.
Sheen
Sheen began developing software in 2014 and has been developing in FiveM since 2018.
Sug first came across Sheen through one of his open-source resources. After Sheen helped adapt it with functionality the server needed, he joined the development team in 2024.
Since 2024, they have built and maintained systems together, combining Sheen's deeper engineering experience with Sug's perspective from developing and running a live server.
Between us, we've experienced FiveM as players, server operators and developers building the systems underneath.
Systems
Build the loop, not just the mechanic.
A mechanic can work perfectly and still feel empty. We design the activity around what happens before, during and after the interaction.
A reason to start
An activity needs a clear way in: somewhere to begin, context for what is happening and a reason for the player to want to take part.
Depth while you're there
Decisions, variation, risk and reward — and an interface built around the mechanic — are what turn a basic interaction into gameplay.
A reason to return
Where it suits the activity, progression, changing outcomes, statistics, an economy or repeatable objectives give it longevity.
The individual mechanics are there to strengthen the loop, not to make the feature list longer.
Compatibility
We remember the support tickets.
Some of the most frustrating parts of running a server happened after buying third-party resources.
We'd buy a script only to find that it did not work cleanly with something already in the server. Sometimes the integration point we needed was inaccessible; other times we were waiting days or weeks on a support ticket for a compatibility change before the resource could be used properly.
That experience is why compatibility is designed into our own resources rather than treated as an afterthought. They ship with bridges for the common frameworks and integrations for popular inventory and target resources. They create the database tables they need automatically, and configuration focuses on the choices specific to your server, such as locations and economy.
The goal is for a server owner to spend their time configuring the system for their economy and world, not rebuilding the resource around the rest of their stack.
The resource
Built for players. Built for live servers.
The interface is part of the resource.
Diving, Arenas, Money Wash and Pawnshop are very different activities, and their interfaces should feel that way too. The interface should make the activity easier to understand, not make the player learn the script.
Behind that interface, we try to run only the code the resource actually needs to behave as intended. Optimisation is part of development because these resources have to coexist with everything else on a live server, and every resource we release ends up on somebody else's.
It needs to work for them as well as it worked for us.
The store
A release isn't the end of development.
We intend to keep releasing new systems, but not at the expense of the ones people already rely on.
Arenas has already moved through major revisions, with further development planned, and Money Wash continues to evolve as well. We'd rather improve successful systems as FiveM changes than build a catalogue so large that keeping every resource current becomes unrealistic.
After purchase, our job is to help customers get the resource running cleanly on their server. Where the wider FiveM ecosystem changes or a supported integration needs adapting, compatibility is part of the work we continue to maintain.
Build the system properly. Support it. Keep improving it.