BULDR // SYS_MANIFEST

← BACK_TO_ARCHIVE

Architecting Buldr_Hub: How everything came to life

As I've been working on various small projects in my free time, I realized that I had a lot of scattered ideas and code snippets lying around. With Buldr I wanted to combine them into something more structured and manageable. A platform where I could collect everything I'm working on, share it with others, and maintain it easily.

The vision

In my free time I've been constantly working on smaller independent projects. A small web-game to play with friends here and a little tool that'd help me with development there.

I rarely ever used Github for personal projects and I only owned one domain - <mysurname>.com - making it kinda hard to

  • a) give other people access to my apps without handing out my personal data and
  • b) showcase the things I'm doing to non-users

Pretty much chronically leaving behind an ever growing collection of "digital orphans" and I wanted to give them a home. A collection of things I do. Easy to manage, easy to maintain and - most importantly - easy to share.

The Techstack

The userbase is small, the developer is lazy, so my main priority was to keep things simple and iterable. There is no team doing PR Reviews, so things can and will break, making it even more necessary for the Stack to be flexible. That's why, after careful consideration, I went with:

Orchestration

Dokploy - The single greatest invention in the history of inventions maybe ever. A self-hosted tool that lets me connect to my Github and setup all my deployment needs.
I just specify the repository and branch and everytime something happens there, Dokploy will automatically pull the changes, rebuild the application and deploy it, without me having to do anything manually.
Set it up once, and forget about it.

Content Machine

PayloadCMS - my content management system of choice. It's, once again, self-hosted, very configurable and handles a bulk of the things I need.
User management, relational database stuff, part of the authentication... all while being pretty lightweight.

Storage

PostgreSQL - helps me keep things persistent.

Admittedly it's not the simplest solution I could've used, but it's easy enough while coming with quite a few performance benefits when compared to alternatives like MongoDB.
Not only that, but it also integrates perfectly with my existing apps and tools (like PayloadCMS for example).

Frontend

NextJS - might've been the most challenging part to work with. While it's still pretty low on the difficulty scale, I simply had no experience with it. I've used Vite before and got quite a bit of React experience, but NextJS did bring it's fair share of obstacles that wanted to be overcome or simply get used to.
Now that it's up and running, it's very easy to expand though, which is why I certainly don't regret that choice

One account to rule them all

The Hub itself already comes with multiple authentication hurdles.
On one hand is the hub itself, letting you login to your Buldr account (it will provide value at some point, I promise!) and on the other hand there's the Payload Dashboard. Technically two separate places, waiting to be combined.
That's not it though. Some of my apps already gave you the option of setting up an account. That would've resulted in quite a few sign up processes for you as a user though, if you wanted to use all of the services and the main goal of Buldr was to unify thing after all.
It's not fully there yet, but the idea is to let the Buldr API handle it all.
Want to keep your username while playing some Neo-Terra? That's the goal!
SSO-lite or something, idk.

It can't be that easy though

While puzzling things together, I was bound to run into an issue or two, yet all of them were solvable.

Logging - Deploying the hub seemed to work just fine. Yet, a few of my volunteering and unpaid testers managed to find a few bugs.
Debugging in Production stinks and existing Error Monitoring Tools like Sentry seemed way too heavy and feature rich for my purposes. So while I was at it, I gave GoLang a try. Yet another thing I've never used before, but brave as I was, I went with it.
The risk taking was worth it, because in the end I developed my own little suite and called it Bugsnatch. It's very bare bones, providing an API to report errors and a web interface to upload Sitemaps and look at your collection of issues - but in a pretty way!

Database Mismanagement - Yeah honestly that's just my bad. Don't use your production Database during development, or you will have to manually redo all your PayloadCMS content. Thrice.
At least I learned how to fix a WAL and to create backups, I guess.

Laziness (once again) - I'm mainly a developer. "Content Creator" really doesn't suit me. Neither my skills nor my interests, so to reduce the amount of text I gotta write, I now also self-host an Ollama instance. My budget is tight, my hardware not the best, so I currently only run llama3.2:1b, but as long as it helps, I'm happy. The main work is still done by me - I write code, I write blog, but manually writing app descriptions and summaries for blog posts, is now a thing of the past.

The future is bright

There's quite some things left for me to do so here's a rough outline of what's still on my agenda

  • Internalization using i18n
  • Properly implement the profile within the hub, maybe
    • add settings to change things like password or avatar
    • provide some kind of leaderboard across different apps
  • Update all Apps to allow you to make use of your account
  • Decide on open vs closed source

Was it all worth it?

Definitely. I learned a lot along the way and there's always room for improvement. Maybe I finally found a long-term project for myself, even if it's just arranging all my short-term ones beautifully!

Btw, if you're a recruiter: Repos are kept private for now but you might have gotten here through a job application of mine, feel free to contact me at [email protected] for a more intimate showcase of the behind the scenes.