Thoughts on Void Presence and why I'm not trying to promote it

While developing new updates or Void Presence itself, I never really thought about where this could lead me. Starting from v1.0.0, I didn't set any plans for this application. The goal was simple: build a nice-looking profile for myself, nothing more.

I didn't think about how it would look in the future. It was rough, but it worked. There were bugs and errors, but nothing critical. Essentially, I was the only one using it.

From personal project to responsibility

If you observe my development process, you might conclude that I'm doing overhead, or so-called overengineering. I realized this when I started thinking about customizing the builder and bootstrap installer. That's when I understood: everything I'm building has long outgrown my personal project and become something more.

I started designing architecture not for myself, but for someone else. And that's both wonderful and scary. It's wonderful to open the database console and see new people who decided to register, download something. But behind that lies responsibility: for security, for stability, for making sure everything works for users.

Development speed and release rhythm

If you look at 600+ downloads, you can clearly see: the application was being developed very quickly. I was pushing 12 patches per day — that's a lot. But recently I realized that, honestly, it shouldn't be like that.

It's better to release updates once every 1–2 weeks so people using the app don't constantly think about needing to update. We have an automatic updater, but I understand: that can also annoy someone.

Where I'm heading next

Now I'm starting to move into more complex systems: NestJS, Prisma together with RabbitMQ. All my future projects will be significantly more complex than void-webhook. Essentially, that project is about that same overengineering — when the task is more about learning to write with these technologies.

I perfectly understand that it's easier to spin up Express, make a small server, and use Cloudflare Tunnel to push it online and ping a Webhooks. But I want to do it properly and beautifully: add Zod, think through the architecture, make type safety at every layer.

Personal tools built for everyone

If you trace my recent projects, new ones like Obsidian Sync and Nimbus were created purely for myself. But somehow I still ended up adding GitHub Actions workflows. You might ask: why, if these are narrow, personal tools?

I added Multi-platform builds for multiple platforms. And that's probably the clearest sign that everything I build now is aimed at someone who might theoretically need it — even if I started out building just for me.

Silent growth and the radio effect

Right now, I don't really write or talk about myself and my projects anywhere. The only real mention is this site. But there's a funny thing about the idea of Word-of-mouth growth.

It's funny to watch a project that isn't advertised anywhere get downloaded more and more. Someone writes to me in Discord DMs, someone opens issues on GitHub, someone quietly downloads configs. Essentially, an ecosystem is forming where everything interacts the way it should.

The cost of writing on full chill

The big problem with the whole project is that it was written on full chill. I only started thinking seriously about it after reading 62 Specific Ways to Improve Your Code.

It's scary to look at the code I wrote, simply because I can see how to make it better. But like any developer working with TypeScript, when a project is built more or less on Type-level programming, you eventually realize that rewriting it means hitting a wall: changing one type, even a seemingly insignificant one, can break everything. There's a golden rule: 'If it works, don't touch it.' And right now, changing components only happens when I'm adding something new and trying to wire everything properly.

Ideally, I should have created an npm library that pulls in shared types. I just didn't think we'd reach a point where the architecture would be more complicated than instant noodles.

Vanilla DOM, Wails, and shooting myself in the foot

If you look at what's written inside the app itself, you'll just hit horror. There's a lot of code, and because it's not React but plain vanilla with Direct DOM manipulation, it becomes very hard to work on projects like this.

Ideally, I should have written it with Wails + Go. The bundle would be much smaller, types would be inferred automatically, and I wouldn't have to think about IPC (Inter-Process Communication) bridges and similar topics. But right now, switching would be like shooting myself in the foot — and after the shot, the foot would fall off — because I'm not really a Go developer.