ABOUT / DEANA ALI

Curiosity has
root access.

I’m a CPA in Washington, DC. I also build multiplayer games, turn recipe collections into networks, and make bots argue over board-game strategy.

The connection? I like figuring out how the pieces fit—and making something work well enough to use.

Try thinking through a build with me
DATA → DISCOVERY231,000 recipesturned into an explorable ingredient network ↗STATE → SHARED PLAYOne room. Many secrets.phones in sync, hidden roles on the server ↗RULES → EXPERIMENTSStrategies that face off.bots test the moves instead of debating them ↗

HOW MY BRAIN GETS HERE

The little problem
is usually the good one.

Picking a trip. Finding dinner. Keeping a game moving. I start with something I want to use, then follow it down to the data, rules, and moving parts.

01 / FIND THE FRICTION

“Why is this still annoying?”

The group chat can’t settle on a destination. The freezer has food but no plan. A good project starts with a specific problem.

02 / MAKE THE PIECES TALK

The interface is only the beginning.

A button might touch a room server, a recipe pipeline, an API, or saved account state. I want to understand what happens after the click.

03 / TEST THE AWKWARD CASE

Now try the thing that breaks it.

Who gets to see a secret role? What if a proposal expires? Does the reminder still arrive after the page is closed? Those decisions make the build interesting.

Interactive / systems sandbox

A small test of your systems brain.

Pick a project, inspect its moving parts, then introduce a failure. Can you find the fix? This is a guided simulation of the architecture—not a connection to the live apps.

0 of 6 debugged
One room. Everyone’s phones. A lot of secret roles.Ready to play
Inside this piece

JavaScript · Everyone’s phone

The browser shows each player the controls and information they should see. The room does not need everyone to install an app.

Read the real build notes ↗

YES, I BUILD WITH AI

A fast collaborator.
A lot of my decisions.

Claude Code and Codex help me write, debug, and revise code. I choose what to build, decide how it should behave, and test whether it actually does. The build notes show the architecture and the tradeoffs; the toolchain shows where the tools fit.

Got a problem that keeps turning into
“someone should make a thing for this”?

I want to hear it ↗