I Tried to Build a System to Manage My Digital Life

I Tried to Build My Own Personal Control System

I wanted to build one system that could help me manage more of my daily life.

The idea was to have different parts for different things: managing my time, organizing my day, keeping track of tasks, understanding how I was using my phone, managing my money, and eventually adding more controls.

It was much bigger than a normal productivity app.

Instead of building everything as one big application, I decided to split the project into separate services.

The first one I built was for managing my money.

Building the First Service

I started with money because it was something I actually wanted help with myself.

I had tried looking for mobile apps that could help me organize my spending, but I never really found one that worked the way I wanted. Some had parts I liked, but nothing matched the kind of control I had in mind.

So I started building my own.

At the beginning, I experimented with Laravel. The problem was not that Laravel was bad. It was more about the kind of project I was trying to build.

The system was going to have many different responsibilities. Money was one part, but later there could be time management, tasks, phone activity, schedules, and other controls.

The more I thought about that structure, the more I wanted those parts to stay separate instead of letting everything grow inside the same application.

That is when I moved to Node.js with Express and started building the project around separate microservices.

For this experiment, that structure made much more sense to me.

The money service could handle money. Another service could later handle time. Another could handle tasks. Each one could stay focused on one job instead of everything becoming mixed together.

Of course, microservices also created their own problems.

Once you separate everything, you have to think about how one service talks to another, what happens when one of them fails, how they share data, and how you keep everything working together.

But even with those problems, I preferred that structure for this project.

It felt easier to understand and easier to grow one part at a time.

One Microservice Was Enough to Show Me the Problem

Then I started actually building the first service.

That was when the experiment became much more real.

The money service alone took me much longer than I expected. It was not just coding a few screens and finishing it.

I had to think about the structure, how the data should work, how the mobile application should behave, how different parts should connect, and how I wanted the whole thing to work in real use.

I also used AI agents while building it.

They helped me move faster in some parts, but they also had a cost. The more work I gave to AI, the more credits I used.

And AI did not remove the thinking.

I still had to decide what to build, plan the structure, check what the agent produced, fix problems, change things when they were wrong, and understand how everything connected.

After working on only the first microservice for a long time, I started doing the math in my head.

If this one part already needed this much time, work, and money, what would happen when I started building all the other services?

I still had the time system.

The task system.

The phone control.

The daily organization.

And probably more things after that.

That was when I realized how big the project actually was.

Then Privacy and Security Made It Bigger Again

There was also another part of the idea that mattered a lot to me.

I did not want to build a system that collected everything people were doing and sent all of that data to my servers.

If an application can see how someone spends money, how they use their phone, how they organize their day, and maybe other personal information, that is a lot of sensitive data.

I did not want to own that data.

My idea was to keep as much as possible local.

If the system was running on your phone, your data should stay on your phone.

If I later made a desktop version, I wanted the same idea there.

And if something like this was ever used by a company, I would rather give them the system and let it run inside their own environment instead of having all of their information pass through my servers.

I still think that is the better direction for a project like this.

But it also makes the engineering much harder.

Now I had to think about local storage, background processes, permissions, communication between services, security, different devices, and what happens when something breaks.

The project was no longer just a useful personal app.

It was becoming a serious system.

Why I Stopped the Experiment

At some point, I decided to stop working on it.

Not because the idea stopped making sense to me.

Actually, I still like the idea.

The problem was that the first microservice had already shown me what the full project would require.

If I continued building every part alone, I could spend months or even years on it.

And if I wanted to move faster with AI agents, that also meant spending more money on credits while still doing all the planning, reviewing, fixing, and testing myself.

Then there was security.

Privacy.

Mobile and desktop behavior.

All the different services.

And all the problems that would appear once those services had to work together.

At that point, I realized this was bigger than the kind of project I should try to complete alone.

Maybe one day it could make sense with a company behind it, a team, a partner, investors, or simply more resources.

But as one person building it for myself, it had gone beyond what made sense for me to continue.

What I Learned From It

One technical thing I took from this experiment was how much architecture matters when a project starts having many different responsibilities.

For this project, Node.js with Express and separate microservices worked better for me than continuing with Laravel.

I would not say that means Laravel is bad or that everyone building a large system should stop using it.

But if I personally had another project made of many small independent services, I would probably choose Node.js and Express again.

I liked being able to keep each service small and focused.

The tradeoff is that microservices move some of the difficulty somewhere else. Instead of one big application becoming complicated, now you have to manage the communication between many smaller applications.

That was another useful lesson from the experiment.

But the biggest lesson was not really about Laravel, Node.js, or microservices.

It was about understanding how large an idea really is before committing yourself to finishing all of it.

Sometimes an idea sounds simple when it is still in your head.

Then you build the first real part and suddenly see all the things hidden behind it.

That is what happened here.

I did not finish the full system, but the experiment still did what an experiment is supposed to do.

It gave me an answer.

The idea was possible.

I just learned that building it properly was bigger than what I wanted to take on alone.