AVAILABLE FOR WORK

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

Roblox scripter. I get called in when a game is live and something is broken, slow, or quietly losing money. You get a written report of what I found, not just a patched file.

3 → 63FPS on a live game, root caused with the profiler
2backdoors found and removed from a client's server
2881 → 104ms worst frame, same game
4 moon that game, from a broken build to a stable one
Case 01 · Rescue

A live military RP game at 3 FPS

The owner hired me for lag. The lag was real, but it was not the biggest thing wrong with the game.

What I found

PerformanceSecurityDataMonetization
  • 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.

MeasuredBeforeAfter
Client FPS2.963.3
Worst frame2881 ms104 ms
Server physics steps/s0.3259.9
MicroProfiler capture before the fix
MicroProfiler, before. Every frame is solid orange, and one physics callback is eating 92.6 ms of a 97.7 ms frame. This is what "the game feels laggy" actually looked like.
Developer console full of infinite yield errors
The console on join: infinite yields and stack traces from the combat framework, every one of them from the same missing folder.
Memory graph climbing while idle
Lua heap climbing about 7.5 MB per minute on an idle server with no combat. Connections that were never disconnected.

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".

Case 02 · Ten days

A killer vs survivors horror game, made playable

The owner had maps, killers and art, but rounds didn't start and half the systems a previous scripter left behind were dead. Ten days later it ran start to finish for the beta.

Round flow, killers, music, lighting

GameplayRound systemAudioBug fixing
Killer intro on a black fade, then the Last Man Standing banner when one survivor is left.
BeforeAfter
Rounds never started, the player counter was brokenRounds start and end on their own
No generators4 of 8 spawn points per round, different every time
Lighting block from the last scripter did nothingOwn lighting per map, lobby light restored after
Killer leaves, round runs empty to the timerRound ends, 4 scenarios tested
Beta blocker: nobody got a role or healthAll 14 skins get their role
Beta blocker: generator repair cancelled instantly4/4 generators flat on the floor, both maps
  • Chase music by distance. Layers swap as the killer gets closer and lock in during a chase, with a crossfade between 80, 60, 30 and 15 stud bands. Every killer and skin has its own theme. One killer's theme is four layers kept in sync within 0.1 s.
  • Last Man Standing. Banner, a 1:15 timer, the survivor healed to full, other music muted. Tested down from 3 survivors to 0. The owner's words: "works literally perfect".
  • Killer kits. A pirate admiral with a flintlock and boarding party minions, and a beast with a roar, a gouge and a stalk into pounce.
  • Spectate, killer intros, XP and gems with saving, a leaderboard with killer chance, every teleport on a black fade.
  • Other people's bugs. Invisibility that didn't restore transparency, effects that stopped stacking after a revive, a curse that set speed to zero forever, a spectate button off screen above 900 px.
Killer ability bar with cooldowns and leaderboard
Ability cooldowns, a status effect card and the killer chance leaderboard.
Admiral killer mid round with abilities on cooldown
The admiral mid round, flintlock and boarding party on cooldown.
Generator with interact prompt and numbered spawn points
Generator spawn points, numbered for testing, with the repair prompt.
Spectate menu with arrows
Spectate: who you're watching and which character they play.

About 3,270 lines across 20 modules, written inside the owner's existing codebase rather than around it.

Case 03 · UI

Menus for a medieval fantasy war game

Team select and main menu, built in Studio and wired up in code. Two directions for the same screen, because the client wanted to see both.

Team select, main menu

UIAnimationTweening
The shipped version, whole flow. Main menu, team select with a live player count per team, hover states, transitions in and out.
The first direction, dark and gold, with a confirm screen after you pick a side.
Team selection screen, dark and gold
Team select, first direction.
Main menu with sword logo
Main menu: play, teams, class selection, shop, settings.
Straight with you: I build the screens, the layout, the animation and the code behind them. I don't paint the art: backgrounds and crests in the shipped version are the client's, the frames are CC0. If you need illustrations drawn, that's an artist, not me.
Case 04 · Build

Loadout and locker system

Same military RP client as Case 01, later job. Players pick a weapon, uniform and tools, save it as a named loadout, and get it back on every spawn.

  • 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.
Locker UI, weapons tab
Weapons tab, with preview and named loadouts.
Locker UI, uniforms tab
Uniforms, filtered by the player's regiment.
Locker UI, tools tab
Tools tab: handcuffs, medkit, binoculars, sabre.
Locker room in game
The locker room it runs in.
Case 05 · Shipped solo

Chaos Protocol Tycoon

A motorcycle tycoon with a horror layer. Built alone, start to finish, and published.

Chaos Protocol Tycoon menu
Night forest, dynamic weather and time of day, live currency HUD.
  • 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
Straight with you: this is a small beta with a few hundred visits. I link it as proof that I can carry a whole game alone, from data layer to monetization to publishing. Not as a hit game. If you need someone to make a game blow up, that's a marketer, not me.

Play it on Roblox →

Case 06 · Speed

Six core systems for a dig simulator, in one day

A commission for a digging and museum game. Eleven systems were scoped out of an eighteen system spec. These six were built, wired together and running in a single day.

All six running, one take

DataEconomyGameplayConfig driven
56 seconds, no cuts: buy a shovel, dig, unlock the next site, hit a site you can't afford yet.

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.
Shovel shop with five tiers, one equipped, two locked
Five shovel tiers. Prices, dig radius, depth per swing and cooldown all come from config, not from code.
Player standing in a hole dug several layers deep
Depth is stored per grid cell on the server. The hole stays after you walk away.
Forgotten Temple unlocked notification
Site unlocked. The server checks money and shovel tier, the client just gets told.
Royal Tomb, not enough money
And refuses when you can't afford it, whatever the client claims.
One bug worth showing. Only the first area could be dug. The area slabs had been moved by hand in Studio, but the config the server checks against still held the old coordinates, so clicks on visible ground landed outside the server's idea of the area and were refused with nothing on screen to explain it. I aligned the config to the world and added a boot time warning that fires whenever a slab and its config drift apart, so the same silence can't happen twice.
Case 07 · Tooling

A scanner for the exploit nobody scans for

Backdoor scanners look for someone else's code. This one looks for missing checks in yours. I wrote it, ran it on my own published game, and it found two real holes I had shipped.

Remote Audit

SecurityStatic analysisStudio pluginFree

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.
Straight with you: the first working version found ten things and four of them were noise, so I cut those categories out entirely. They were not wrong, they were just things nobody would ever go fix, and they buried the three that mattered. Everything the tool reports is worded as an observation, not a verdict. It is lexical analysis, so metatables and dynamic indexing are outside what it can see, and a check written after the dangerous line still counts as a check. Both are deliberate trades in favour of staying quiet.

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.

Case 08 · Atmosphere

Weather that every server agrees on

Built as a standalone system and dropped into a blank place, so it can be judged on its own. Thirty-seven presets, one schedule, no client ever deciding what the sky looks like.

Dynamic Weather System

Server authorityDeterministicConfig drivenSound
Clear into rain into a storm and out to snow, with the active preset named on screen.

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.
Why it's here. Most of my work lives in other people's games and can only be shown as video. This one I built from scratch in an empty place specifically so the whole thing, running, is something you can watch end to end before hiring me.
Case 09 · How I build

A simulator I'm building now

In development. It's here because it shows how I structure a project when nobody hands me ten years of legacy code.

  • 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.
Also shipped

Smaller jobs

  • 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.
Pricing

What things cost

Fixed price, agreed in writing before I start. If the job turns out smaller than I quoted, you pay the smaller number.

Bug fixOne clear bug, reproduced and fixed
from $15
UI systemMenus, HUD, shop and inventory screens
from $25
MonetizationGamepasses, developer products, receipt handling
from $30
Data and savingProfileService or custom, session locks, migrations
from $40
Gameplay systemCombat, progression, tycoon loop, NPC behaviour
from $40
Performance audit and fixProfiled properly, with a written report
from $55
Security auditBackdoors, exploits, remote validation, written report
from $60
Full buildScoped per project after we talk
from $120
Process

How working with me goes

  1. You tell me what's wrong or what you want. I ask two or three questions.
  2. I give you an honest read: small fix, big job, or "you don't need to pay anyone for this". That part is free.
  3. Fixed price and scope in writing before anything starts.
  4. Small jobs paid up front, bigger ones half up front. The rest before I hand the files over.
  5. I build it, you get a video of it working, then you get the files.
  6. Tweaks to what I built are on me. New features are a separate job.
Contact

Tell me what's broken

Send me the problem and a link to your game. I'll tell you straight whether it's a small fix or a real job, before you commit to anything.

Discordaleksandr.yrch
Emailsashauruchko@icloud.com
RobloxW_Katana
Payment. Per task, paid as each one ships, up front on small jobs. PayPal, card through Payoneer, crypto, or bank transfer. Robux is fine at my rate. Happy to use a middleman for a first job. No rev share, no "pay after launch".