Booth Beam - Month 1

One-Line Summary #

From Prototype to Commitment

Highlights #

• Booth Beam navigation system through app has been fixed
• Application’s UX has been improved
• Working task management system has been set up
• Going fully public with retrospectives
• My private files are moved away from cloud services

---

Goals Grades #

At the start of each month, I declare what I’d like to accomplish. Here’s how I did against those goals:

---

Prepare BoothBeam for private beta by making the app usable (implement missing core features)

• Result: Most important core features are implemented and Release 2026.2 is out
• Grade: B

---

Start promoting BoothBeam

• Result: I did nothing on promoting app.
• Grade: F

---

Migrate file storage away from cloud services to my own infrastructure

• Result: All my files moved away from OneDrive to my personal HomeLab
• Grade: A

I spent more time on this task then expected, but it’s finally done. Now I can set HomeLab on a side for a while and shift focus back on Booth Beam.

---

Booth Beam metrics #

	February 2026	March 2026
Website visitors	N/A	14
Delivered stories	N/A	27

This month marks the initial setup of the website along with the first set of basic metrics. At this stage, these metrics are not meant to be perfect or comprehensive-they are simply a starting point to establish a baseline and begin tracking progress.

As the product evolves and I gain more insight into user behavior and business goals, these metrics will be refined, replaced, or expanded to better reflect what actually matters.

Current product state #

At this stage, BoothBeam is in a pre–private beta phase, but it is close to being ready for early users.

The core concept and architecture are in place. The backend can send commands to connected screens, and the screen application can receive and execute them reliably. The main communication flow is working, which validates the core technical approach.

From a functionality standpoint, the product is usable, but not yet polished. Key flows such as onboarding and screen management exist, but they are not intuitive and still require guidance. At the moment, new users would likely need assistance or prior context to get started successfully.

The biggest gap is not in the core features, but in the onboarding experience and supporting instructions. With clearer guidance and a smoother initial setup, users would be able to reach value much faster.

Stability has not yet been tested under broader real-world usage, but the current implementation is solid enough to begin controlled testing with a small group of users.

In short, the product is ready to move into private beta, with the understanding that onboarding and user guidance need to be improved to reduce friction and make the experience more accessible.

Reset Point: From Prototype to Commitment #

Even though work on BoothBeam started several months ago, I consider this to be Month 1.

Up until now, the work was inconsistent and exploratory-focused on prototyping and testing core ideas rather than building a real product. It was an on-and-off effort without a clear commitment, direction, or defined goals.

This month marks a shift. I made a conscious decision to either commit fully or stop working on it altogether-and chose to commit.

At the same time, the project itself reached an important milestone. The prototype evolved into something usable, meaning it can now provide actual value to users and is ready to move into a private beta phase.

This is also the first month I started treating BoothBeam as a real product: setting goals, tracking metrics, and documenting progress through retrospectives.

Because of that, this is not just another month of development-it’s the starting point of a new phase, where the focus shifts from experimentation to execution, and increasingly toward marketing and sales alongside development.

Side projects #

HomeLab #

Spent significant time setting up my HomeLab and moving away from cloud services:

• Migrated files from OneDrive to my HomeLab
• Set up automated backups
• Deployed Immich for family photo backups
• Transferred a large archive of family photos from OneDrive to Immich, uncovering missing shared photos that still need to be sorted
• Set up an eBook management system

Key Decisions #

Going Fully Public with Retrospectives #

I have a problem staying focused on a single project. After some time, I get bored and start losing interest. To deal with that, I work on multiple projects in parallel and switch between them.

This helps me stay engaged, but it comes with a cost. I often lose context, forget what I was doing, and leave things unfinished. Over time, this leads to abandoned ideas, slower progress, and a growing pile of half-done work.

To keep things under control, I rely on journaling and retrospectives. My current system is seasonal. Each season lasts 14 weeks. At the beginning, I decide what deserves my attention based on my areas of responsibility, then define goals and actions. During the season, I keep a daily task journal and do weekly retrospectives to track what actually happened.

Recently, I came across Michael Lynch’s retrospectives, and I really liked how they are structured. Clear, consistent, and easy to follow. I decided to adopt that structure for my own monthly retrospectives and publish them publicly.

This is slightly different from how I currently plan and review my work. My system is still seasonal, but I want to layer monthly public retrospectives on top of it. The idea is to create more frequent, meaningful checkpoints between seasons.

The main reason for going public is accountability and documentation. Writing things down for myself is useful, but publishing forces me to organize my thoughts in a way others can understand. That added pressure creates clarity.

Each month, I will share a retrospective with a goals overview, key metrics, and decisions made. At this stage, a “good month” means making progress on key projects and finishing smaller, well-defined pieces of work. There’s no revenue yet, but everything is moving in that direction.

Let’s see how this evolves.

To Tududi or not Tududi #

Several months ago, I started using Tududi, a self-hosted task management app. I even wrote an article An Unexpected Way to Connect Tasks, Notes, and Projects - Discovered Through Tududi about how impressed I was with its simplicity. I joined the Discord community to follow development and see if I could contribute.

At first, it felt like the right tool. What I liked most was the ability to start immediately without setup. No need to define projects, tags, or structure upfront. Just add tasks and organize them later if needed. That flexibility matched how I think about work.

But after some time, the cracks started to show.

The app is quite buggy. That’s expected to some extent in an actively developed project, but only if bugs are being addressed. Instead, most of the effort seems to go into adding new features, while existing ones remain unstable or break.

Some concrete issues I ran into:

Recurring tasks behave unpredictably. It’s unclear when and where they appear, and there are bugs when setting intervals. “Areas” are introduced as a concept, but in practice they are just a project-type filter, not a real representation of areas of responsibility. A calendar feature was added, but it feels unnecessary and poorly thought out. The notes feature becomes unusable once notes start piling up, with no good way to manage or navigate them.

Following discussions in Discord confirmed that this is not temporary, but a pattern. The focus is on adding features rather than stabilizing the core.

Over time, I also noticed questionable implementation decisions. For example, adding a subtask requires sending the entire list of subtasks from the frontend, instead of appending a single item. That introduces unnecessary complexity and signals deeper design issues.

All of this led to a simple outcome: I started wasting time and losing trust in the system.

I’ve used tools like Jira, YouTrack, Trello, Todoist, and Things before. What I’m looking for is something in between: more structured than GTD apps, but lighter than full project management tools like Jira.

At that point, it became clear that Tududi won’t meet my needs anytime soon, so I decided to stop using it.

After evaluating a few options, I chose to try Plane.so. It’s not self-hosted, but the UX is solid, and the free plan is generous enough to get started. It seems to hit that middle ground I’m looking for: simple task management with support for user stories, categorization, and a built-in knowledge base.

Right now, my main criteria are simplicity and the ability to start without cost, with room to grow later if needed.

I’ll use it for the next few months and see if it holds up.

Moving Away from Cloud Services #

This month, I decided to stop paying for cloud storage and move everything to my own server. I invested a significant amount of time into setting up my HomeLab and gradually moving away from cloud services.

Several years ago, cloud storage felt like the obvious choice. I used a OneDrive family subscription for years. At the time, it was an excellent deal-around $100 per year for the full Office package and 1 TB of storage per user, for up to five users. That came out to less than $2 per month per terabyte, effectively making the Office suite feel free. But my needs have changed, and once my setup matured, it started to feel like unnecessary dependency.

I no longer use the Office tools, and cheap hard drives combined with my HomeLab setup now offer a more flexible and controlled alternative to cloud storage.

Over time, I’ve been experimenting with self-hosted tools, setting up a NAS, and implementing a backup strategy based on the 3-2-1 backup rule. Adding VPN access allowed me to reach my files from anywhere, which removed one of the last real advantages of cloud storage for my use case.

At that point, the decision became clear: reduce ongoing costs and fully migrate to my own infrastructure.

The migration itself, however, was far from smooth. Exporting data from OneDrive turned out to be slow and unreliable. Large exports were throttled heavily-sometimes down to 1-5 Mbps-and occasionally resulted in corrupted ZIP files. The only workable approach was to download everything in smaller batches.

In total, it took me two full days to move all files and reorganize them into their new locations, including importing photos into Immich.

Now that everything is under my control, I feel a strong sense of ownership and peace of mind knowing exactly where my data lives. At the same time, this shift comes with a new kind of responsibility. I am now the single point of failure-the only one who understands how the system is structured and maintained.

That realization raises an important question for the future: how do I make this setup more resilient-not just technically, but also operationally-so it doesn’t depend entirely on me?

Wrap up #

What got done? #

• Improved Booth Beam UX and made small adjustments based on usability thinking, in order to reduced friction in key user flows.

• Set up Booth Beam website and documentation project using Astro framework

• Moved away from Tududi as task management app and set up Plane for BoothBeam project management

• My personal website is updated with my project list and retrospective section

• All my files moved away from OneDrive to my personal HomeLab

• I took a small job for my client PizzaBotako.rs to set up and deploy PWA app

Lessons learned #

Cloud exit is harder than cloud entry - exporting data from cloud providers can be slow, unreliable, and time-consuming. Vendor lock-in is not just about APIs-it’s also about data extraction.

Simplicity at the start is not enough - a tool that feels great on day one can break down under real usage. Initial flexibility (no structure, just tasks) is valuable, but long-term usability depends on how well the system scales with complexity.

Goals for next month #

• Select and start 1 marketing strategy for Booth Beam
• Find 5 Beta testers and get their feedback
• Create short demo video of app