Independent games, software, media, experimental systems, mods, simulations and strange ideas built through practical testing instead of endless meetings.
Games, mods, software, simulators and tools moving through the Lab, and what has already shipped.
Residential cleaning in Northern Utah and Southern Idaho. Weekly, bi-weekly, monthly, deep, move-in, move-out and construction cleans, priced by the room.
A heavily expanded Schedule I mod project focused on progression, systems, characters, businesses and controlled chaos.
TestingPractical software projects, operational tools and custom systems designed around actual workflow problems.
ActiveExperimental simulator concepts built around physical interaction, progression loops and systems that make players want one more run.
ResearchAn original game in development in the Game Dev Lab. Code name only for now. Details stay classified until there is something worth showing.
In DevelopmentEight labs. Four are running, four are queued. A lab goes online when it has someone sitting in it, not when it has a name.
Sound effects, score, mixing and voice, plus 3D assets and visual effects for games, media and experiments.
OnlineMod engineering against live game builds. Progression, systems, characters, businesses and controlled chaos.
OnlineSites designed, built and deployed end to end. Client work and the Labs’ own front door, this page included.
OnlineOriginal games and simulators built from the ground up instead of bolted onto somebody else’s. First project in the pipeline: MRS.
OnlinePractical systems and operational tooling built around workflow problems that actually exist.
QueuedCustom software for real jobs. The kind that replaces a spreadsheet somebody has quietly hated for years.
QueuedTools, overlays and production systems for people who make things in front of an audience.
QueuedThe ideas with no obvious home. Tried anyway, documented honestly, kept only if they survive contact.
QueuedBuild logs, project stories, experiments, failures, shorts and the occasional historical crime scene.
The actual chronology of how a modding conversation somehow grew domains, ledgers, specialists, rituals and a graveyard.
QueuedPractical clips showing the gap between a good idea, a working build and a runtime pass.
In ProgressQuick experiments, disasters, breakthroughs, character moments and the occasional digital workplace fatality.
IncomingReal decisions, useful mistakes and the weird parts usually edited out of company stories.
OnlineBuild updates, experiments and the occasional disaster, posted as they happen. Click to follow on Facebook (Facebook will open in a different tab).
Malfunction Labs™ is an independent creative and technical studio exploring games, software, media, simulation, automation and unusual ideas.
The goal is simple: let useful ideas survive long enough to become real things.
Industrial mechanic, systems builder, modder, designer and habitual asker of: “Why the fuck are we doing it that way?”
Malfunction Labs did not begin with a pitch deck. It grew out of years spent around machines, production floors, maintenance problems, workflows, games, mods and people doing complicated work with systems that could have been simpler.
The common thread is practical: look at what is actually happening, fix the thing that is actually wrong, and leave the system better than you found it. That mindset came from manufacturing and maintenance long before it ever touched code. Centerlines, tracking, preventive maintenance, process improvement and troubleshooting all teach the same lesson: the machine does not care what the meeting said it should do. It only cares what the system actually does.
The Lab applies that thinking everywhere. A mod can become a systems-design problem. A maintenance headache can become software. A simulator can become research. A ridiculous conversation can become a company operating principle if it keeps proving useful under pressure.
AI is part of the toolchain here, but not the excuse. Specialists can research, organize, prototype, test, model, route, document and argue with each other. UserSubmit remains the final runtime authority. Access is not authority, approval is not a trigger, and a build passing is not the same thing as the thing actually working.
We do not need every idea to work. We need to test it honestly, learn something useful, preserve what mattered, adjust the design, and move forward.
WE ARE CHAOS. CHAOS IS US.
Trial. Document. Adjust. Launch.
Chaos is allowed. Organizational amnesia is not.
If the requirement says sheep, deliver a fucking sheep.
Malfunction Labs is still in the build stage, so communication is intentionally simple. Pick the route that matches what you are trying to do. Everything currently lands in the same monitored system while dedicated infrastructure waits until it is actually needed.
Messages are logged and routed on arrival. You will get a reference number the moment it lands. Do not buy the sheep while the sheet is still doing the fucking job.