Why I Build in Public: the Fulin Labs Approach to Side Projects

Fulin Labs is four separate projects — Flashcard, ClassGame, ShortLink, SchedulePost — rather than one product with four features bolted on. That’s a deliberate choice, and so is writing about how each one gets built.

Small, standalone, focused

It would be easy to combine these into one “productivity suite,” but that usually produces a worse version of each individual tool: a shortener that’s also trying to be a scheduler ends up mediocre at both. Keeping each project standalone means it can be judged, used, and improved on its own terms — someone who only wants a URL shortener never has to wade through language- learning features to get to it.

The tradeoff is more surface area to maintain across four subdomains instead of one app. That’s handled by keeping the shared foundation — this site, the write-ups, the entity behind all of them — in one place: fulinlabs.com.

Why document the build process

Writing about how something is built, not just announcing that it exists, does two things. First, it’s a forcing function — explaining the reasoning behind a scheduling algorithm or an analytics pipeline surfaces gaps in the reasoning itself. Second, it’s the only way anyone outside the project understands why it works the way it does, rather than guessing from the UI.

Practically, that means every project on this site gets at least one post that isn’t marketing copy — it’s the actual design reasoning, including tradeoffs, written the way it would be explained to another engineer.

What’s next

New projects get their own hub page and their own launch post here before or as they ship. The posts are plain markdown, kept deliberately portable, so this write-up and every other one on this blog will still make sense wherever they end up being read.

See the full list of current projects on the projects page.