Building My First Real-Time Full-Stack App
What a multiplayer Go app taught me about decomposing game logic, synchronizing state, and designing before styling.
My first real project at Fractal was a multiplayer Go app. I started without knowing the rules of Go, then discovered that understanding the rules was only the beginning: I still had to turn them into data and code that two connected players could share.
the problem was smaller than it looked
At first, I tried to hold the whole game in my head. The board, legal moves, captures, scoring, rendering, and multiplayer state all blurred into one giant problem.
The work became manageable when I stopped asking, “How do I build a Go app?” and started asking, “What is the next piece of data this decision needs?” Each answer exposed a smaller function, state transition, or component. Then I could build and test that piece before moving on.
That sounds obvious now. It did not feel obvious during the first few days.
unfamiliar tools became ordinary through use
React Query and sockets both felt strange at the start. By the end, their patterns felt much less mysterious because I had used them to solve concrete problems: move data between the client and server, keep two views synchronized, and update the board when state changed.
I learned more from following one real value through the system than I would have learned from memorizing another abstract tutorial.
styling is not a substitute for direction
I spent too much of the week styling without first deciding what the product should look and feel like. That produced a lot of CSS work without a coherent visual result.
The lesson was not that styling is unimportant. It was that implementation cannot manufacture a design direction I have not chosen. A rough visual plan up front would have made the later work faster and more deliberate.
what I would do differently
I would still begin with the rules and data flow, because those were the hard parts. But I would also sketch the interface before polishing it, and I would present the technical decisions that mattered—the game logic, state model, and board rendering—instead of giving a surface-level tour.
The project made one engineering habit stick: when a system feels impossible, stop trying to solve the noun. Find the next piece of data, make one decision explicit, and keep going.