max gerlach · systems engineering student · student pilot
I turn requirements into systems that people actually use.
I study systems engineering in the netherlands, train as a student pilot, and ship software in public. I run Probably Labs, my one-person studio, where a TikTok effect reached 2 million people.
how i work
Engineering is mostly deciding what not to build. I work the same loop on everything — pilot training taught me that.
- 01
Define
Write the requirement in one sentence. If I can't, the project isn't scoped yet.
- 02
Design
Break it into interfaces, then decide which parts I build versus reuse. Reuse is a decision, not a shortcut.
- 03
Integrate
Wire the pieces together and make them observable. Integration is where systems fail, so it's where I test hardest.
- 04
Verify
Test against the requirement, not against my code. Real users are the final verification step — 2M of them found bugs I never would have.
- 05
Iterate
Ship, watch what happens, change it. Repeat until the requirement is met, then move on.
case studies
-
TikTok effect · 2M users, 80M views
Requirement: build an effect that strangers use more than once.
- problem
- Most effects get opened once and dropped. Retention, not reach, was the actual target.
- what i did
- Built it in Effect House, tested iterations on my own account first, and rewrote the trigger twice based on where people bailed. Kept it simple enough to run on a mid-range phone.
- verification
- Watched behaviour in analytics rather than trusting a feeling. 2M unique users, 80M views — and the numbers drove every change.
- what i'd change
- Version it from the start. Post-hoc iteration on a shipped effect is slow, and I lost time re-rolling out changes.
-
Probably Labs
Requirement: ship a Roblox game as a one-person studio, without publishers or a budget.
- problem
- Solo means no QA team, no art budget, no second opinion. Every defect ships straight to players.
- what i did
- Own the whole lifecycle in Luau: scripting, map design, playtesting. I run short cycles and treat player reports as free verification.
- verification
- Playtest with real players early, on purpose. It's the fastest way to find the requirement I failed to write down.
- what i'd change
- Write test cases before features. I currently discover requirements through bugs, which works but costs more.
-
Small websites
Requirement: fast, accessible pages that work without a build step.
- problem
- Most small sites ship with a framework, a bundler and a hundred dependencies for a page with three sections.
- what i did
- Hand-written semantic HTML, CSS and vanilla JS. This site is the example: no framework, no build, deploys from a git push.
- verification
- Checked in DevTools, on a phone viewport, at 1920px, plus keyboard and reduced-motion passes. Layout adapts rather than breaking.
- what i'd change
- Add automated checks so I catch regressions instead of spotting them by hand.
student pilot
I'm training toward my student pilot licence. Flying is the strictest systems thinking course I could get: defined procedures, checklists, brief-and-confirm discipline, and decisions made with incomplete information.
That maps directly onto engineering work. I run checklists before releases, I brief requirements before building, and I debrief after shipping — same loop, higher stakes.
- disciplineprocedure first, then speed
- under uncertaintydecide, document, revisit
- checklistsused before every release
- debriefswhat changed and why
github / live, newest first
all repos ↗loading repositories…
tools
languages & tools
github activity
contact
Looking for a 2026 systems engineering internship, or just want to talk about systems? Email is best.
mgerlach0168@gmail.com