I fix the systems your game runs on.
Data, monetization, security, performance.

• Combat was completely dead. Every weapon, damage and door script waited on a folder in Workspace that had been dragged one level deeper during a cleanup. The scripts sat in an infinite yield forever. The tidier the workspace got, the more broken the game became.
• The server trusted the client for damage. Damage values, explosions and ammo count after reload all arrived straight from the player with zero validation. Anyone with a basic exploit had infinite ammo and one shot kills.
• Two separate player data systems were running at the same time, both writing to DataStore on every join and leave, storing arrest data in different places, never synced. The data could silently diverge depending on which one fired first.
• Two backdoors running third party code on the server, hidden inside toolbox models.
• Robux purchases that granted nothing. Players paid and got no item.

The performance cause. The physics thread was spending about 96% of every frame on unanchored parts. Weapon parts were live physics bodies, and every single bullet was a real Part with a BodyForce living up to five seconds, while the hit had already been resolved by a separate raycast. The physics body was pure waste.

How I worked. Static pass over the codebase first, then live profiling, then a written report before touching anything. The owner approved each stage and knew exactly what was going to change. Nothing got "refactored while I was in there".

• Server owns the loadout. The client sends a choice, the server checks the player's regiment and rank before handing anything over, so nobody equips gear they don't have access to.
• Per regiment uniforms and per rank weapon access, driven by config, not by hardcoded team names scattered through the scripts.
• Named loadouts saved to the player's data and restored on spawn.
• Live preview of the item before you take it.

• Persistent data with a save queue and session handling
• Monetization: gamepasses and developer products, purchases handled server side
• An AI entity that hunts players through the night forest and tracks them by their headlights
• Weather and day/night tied into a risk system that changes how dangerous the forest is
• Tycoon core: garage upgrades, passive income, bike collection and upgrades
• Progression: gem economy, loot drops with rarity tiers, crafting, skill tree, quests, daily rewards, race modes

Play it on Roblox →

Everything here is decided on the server. The client sends one thing, where it clicked.

• Player data. One service owns the DataStore and nothing else touches it. Session lock so two servers can never write the same profile, write queue with retry and backoff, autosave plus save on exit and on every purchase, BindToClose so a shutdown doesn't eat the last few minutes. If the store still refuses after every retry the player gets removed instead of an empty profile to spend from.
• Currency. Every balance change goes through one function with a reason string in the log. The client only draws the number.
• Shovels. Five tiers. Dig radius, depth per swing, cooldown and price all live in a config module, so rebalancing needs no code change.
• Excavation areas. Four dig sites, each gated behind money and a shovel requirement, bounds and loot tables from config.
• Ground depth. The map is a grid of cells and each cell keeps its own depth and layer. Depth belongs to the ground, not to the player, so a hole one player dug is still there for the next one. Cells only regrow when nobody is digging in them or standing on them.
• Digging. Ties shovel, area and depth together. Reach, cooldown, area bounds and every result are checked on the server before anything happens.

The whole problem in five lines:

DamageRemote.OnServerEvent:Connect(function(player, target, amount)
    target.Humanoid:TakeDamage(amount)
end)

The client picks both arguments. An exploiter sends any character and any number and kills anyone from anywhere. There is no obfuscation here, no loadstring, no foreign require. It is the developer's own code and it reads completely normal, which is exactly why every backdoor scanner walks straight past it.

What the plugin does. It reads server scripts, finds every OnServerEvent, OnServerInvoke and Knit client method, and for each client argument asks one question: does anything check this before it reaches something that matters. Damage, currency, DataStore writes, cloning, destroying, teleports, purchases. If the answer is no, you get the remote name, the file, the line, and one sentence on what is missing.

• Comments and strings are stripped first, byte for byte, so no finding can ever come from a line of commented out code. That single step is the difference between a tool people keep and one they uninstall.
• Checks are demanded by usage. A string argument is never accused of missing a numeric range it does not need.
• It follows the argument one level into local helpers, in both directions, so validation living in a helper counts for the caller and a thin wrapper is not blamed for its own helper's sink.
• A fully validated handler produces no row at all. Not a green line, nothing. The report is meant to be short enough to act on.

Run on Chaos Protocol Tycoon: 72 scripts, 75 handlers, 6 findings.

• A lasso item let any player ragdoll any other player, anywhere on the map.
• The same item could freeze a chosen player for 120 seconds from across the world.
• A class value written straight from the client with no type check.
• A purchase path with no rate limit around it.

Verified against two fixtures before it went anywhere near real code: six planted holes, all six found, and six correct handlers plus three traps with a remote handler hidden in a comment, a string and a long bracket block. Zero findings on that one.

The server owns the schedule and picks the weather. Clients only render it. No remote asks for a weather change and no client can push one, so two players standing next to each other are never in different storms.

• Thirty-seven presets across clear, rain, snow, fog and storms. Lighting, atmosphere, clouds, particles and layered ambient sound all belong to the preset.
• A deterministic seven day schedule. The same day and hour gives the same weather in every running server, so weather can be built into a game's events instead of being random noise on top of them.
• Everything tweens. Colour, density, wind, sound volume, all of it crosses over gradually. Nothing snaps, including when a player joins in the middle of a transition.
• Presets live in a config table. Adding your own weather is editing data, not touching the transition logic.
• Sound is built at runtime from one table and parented last, and the client waits for the group instead of assuming it exists, so a slow load is silence for a second rather than forty four dead references.

• One service owns DataStore. Nothing else touches it, ever.
• Server calculates, client displays. The client never sends a value, only intent: "I clicked", "I want to rebirth". The server validates and answers.
• Data layer: two DataStores, session lock, write queue, auto save, pcall around every store call.
• Anti cheat from day one: click rate capped server side, spending is atomic and balance checked, gamepass ownership checked on the server only.
• No leaks by construction: every connection disconnected on PlayerRemoving and CharacterRemoving.
• Luau types on every function, all tuning in one config module, nothing hardcoded twice.

• Step speed system for a keyboard obby. Run across a giant keyboard, every new key adds speed, momentum decays if you stand still. Speed and touch detection live on the server so it can't be faked, keys are picked up by tag so it works with any map including parts spawned at runtime, and all the tuning sits in one config module.
• Brought a dead progression system back. A published simulator wasn't saving or levelling: DataStoreService fails in an unpublished place, the data module died on load, and every system downstream of it died with it. Guarded it, XP and levels came back.
• Footstep system and a wake up cutscene for a horror game.
• Radio system, weapon rigging and grips across 27 weapons, in game shop with server side receipt handling.