How do private and enterprise projects differ?

First we have to know the differences between those two types of projects. Enterprise and private projects differ significantly. Private projects are developed only by yourself: you decide the architecture, you write the code, you test it. In an enterprise context those tasks are split across multiple roles. Usually one software architect designs the architecture only. He conducts interviews with stakeholders, derives functional requirements and application characteristics, and designs the architecture with regard to those requirements. The developer usually only has to care about the software itself.

Furthermore, enterprise projects have completely different requirements on scale and performance. While enterprise projects are often used by thousands of people concurrently, your private project is realistically maybe used by 5 persons (you and 4 friends). In those situations literally any modern architecture and technology scales well enough to serve you and your friends at reasonable performance. In addition, private projects are way simpler than enterprise projects. You just do not build an ERP system, you maybe build some tool or app for a personal use case, but nothing for regional or global scale.

So now we know that comparing enterprise projects to private ones is like comparing apples to strawberries. Both are fruit, but that’s about it.

Why do people still tend to overengineer?

Developers love to try out new stuff. When building a private project we are not getting paid for it, we are doing it for fun. Therefore, devs are attracted by the opportunity to try out new patterns or technologies. Actually, that’s how I started using Rust. I was mainly using Go for private projects and wanted to try out this new trendy language. This does not only apply to programming languages but also to architectures. When working for money, we are usually tied for months or even years to a single architecture that our architect decided to implement, so private projects present the perfect opportunity to play around with other architecture styles.

But this usually results in todo apps built with 20 microservices and three different messaging solutions. To be clear, that is a hyperbole, but it’s often quite similar to that, maybe less extreme. It is always tempting to overengineer stuff in our private projects.

But there are also devs who do the absolute opposite. They don’t use any architecture at all for private projects and end up building either a layered architecture out of habit, or end up with the big ball of mud antipattern. But that is fine too, as your private projects are only used by yourself, and building software in your free time should primarily be a great experience rather than exhausting. So it is absolutely fine to stay that way.

Should we stop overengineering?

All this raises the question whether we should stop overengineering. No, we should not. But nevertheless, we should be careful what we do, because building overly complex architectures in private projects can train bad habits. Just because some framework is hyped right now, it is not instantaneously a good choice for an enterprise project.

Developers who regularly overengineer their private projects with the latest technologies might subconsciously feel the need to implement those technologies in their enterprise projects too. The book “Fundamentals of Software Architecture” by Mark Richards and Neal Ford illustrates a similar example: a developer loves Scala and wants to widely implement it. In the end, he poisoned the whole team and two other developers wanted to leave. So it is really important that you mitigate the risk of adopting such a habit.

So what should we do then?

If you want to overengineer, just continue to do so. The same applies to developing without any architecture at all. If you like to be without any restrictions on your private projects, feel free to do so. Personally, I like to find a compromise: think a bit about architecture. You don’t need to do a complex trade-off analysis, just think briefly about what you want and what suits this use case best.

I recently discussed an application idea with a friend of mine. It was an application that received images and displayed them, and the images should be available in other sizes as well. We discussed two approaches: either you build everything as a blocking workflow, first uploading the image to S3 and then resizing it, or you use messaging to asynchronously perform the resizing in the background. To be fair, for a personal project both of these approaches are fairly reasonable.

What can we learn from this? We could have split the app into 3 other microservices, but we decided not to. We went with a compromise: only if it is absolutely useful to do something, do it.

Conclusion

Private and enterprise projects live under completely different constraints, so it never makes sense to judge one by the other’s standards. Overengineering your side projects isn’t a problem in itself, and neither is skipping architecture entirely, both are fine as long as you’re having fun. Just stay aware of the habits you’re building, and try to make deliberate choices instead of defaulting to either extreme. A little bit of thought about what actually suits your use case goes a long way.

What exactly is digital sovereignty?

In short, digital sovereignty means being able to control the digital infrastructure, data and software your society depends on, without having to rely on the goodwill of a foreign government or a foreign corporation to keep doing so. It’s the difference between using a service and being at the mercy of whoever owns that service. If your government’s email, your hospital’s patient records, or your company’s cloud infrastructure all sit inside systems that a foreign power can legally access, switch off, or simply decide to change the terms of, you don’t fully control your own digital life anymore, no matter how convenient that infrastructure is day to day.

Why would I care nowadays?

The European Union has one of the strictest data protection laws in the whole world. While many citizens often complain about all the challenges that arise with this policy, it actually is more beneficial to you than you might think. If you are using services that you do not pay for, think Instagram, Google or WhatsApp, most likely the product isn’t the software you are using, but you. Those companies aren’t selling their product to you, they are selling your data to interested third parties.

You might say you don’t care, that you’d rather stay with free services. Nevertheless, you’re still the one complaining when you just talked about a product out loud and Amazon almost instantaneously recommends you that exact product. And it isn’t just about privacy from online marketing either. Your private discussions and deepest secrets, the things you’ve told your closest friends, could just as easily be purchased by some third party.

WhatsApp added end-to-end encryption in April 2016. Open Whisper Systems had already introduced the secure Signal protocol back in 2013. That’s an implementation lag of three years, during which Meta (formerly Facebook) stored your private messages on their servers without proper end-to-end encryption, including whatever darkest secrets you might have shared with your close friends in a late-night chat.

In March 2018, this whole thing blew up publicly with the Cambridge Analytica affair, a huge data harvesting scandal in which the British analytics company gathered the private data of millions of Facebook users to analyse voting behaviour among US citizens ahead of the elections. Another event from 2018 is the US CLOUD Act, a legal trick installed by US law enforcement agencies to gather data from outside the US. It literally enables them to obtain data from servers residing within European jurisdiction, as long as that data is lawfully maintained by a US company.

Why does this fancy CLOUD Act affect you? Do you have anything to hide from them? Even if you don’t, you use US products all day long. Nowadays you might put your whole damn life into ChatGPT, Claude or Gemini, or, if you’re old-school, you might just google stuff. If you’re one of the 55% of German employees who work in an office, you probably use Windows as your operating system, or Word, Excel and Outlook as your office suite. And this isn’t only an issue for private companies. Governments use a huge amount of Microsoft software too.

But how does that affect me?

In most cases, probably not. Germany isn’t at war with the US at the moment, and Europe in general is the most important trading partner the US has. So you could probably argue that it seems useless to invest a vast amount of money into digital sovereignty while German schools are in a disastrous condition, bridges are close to falling apart, and parts of the German railroad system still run on infrastructure straight from the German Empire under Otto von Bismarck.

But if you haven’t had a serious head injury since 2022, you’ve probably noticed that we have a war in Europe again. Russia is brutally attacking Ukraine. Before 2022, most people would probably have said it’s impossible to ever have war in Europe again, because we have NATO and all these peace-making institutions like the UN. Well, that statement didn’t age very well, did it?

And why couldn’t the same happen with digital sovereignty? For decades, the United States was reliably pro-European. Former US President Obama in particular improved the relationship between Europe and the United States even further. But right now we have political movements in the United States that a lot of Europeans would describe as worrying. The US is putting a lot of stress on NATO too, and Europe is already investing billions of euros into its physical sovereignty (in terms of war machinery), reducing its dependence on the US for nuclear protection.

This raises the same question for the digital world: should we also become more digitally independent from the US, given that our entire society now runs on digital services and everything is connected? We’ve had other strong dependencies in the past decade, Russian natural gas being one of them. I don’t think I have to explain how that ended.

How can we tackle this issue?

First of all, there is no instantaneous solution to this problem. I am no great politician or policy maker, and don’t get me wrong, I care deeply about politics and I think everyone should. What I mean is that I don’t have the golden solution to this problem. By all means, I don’t think we should all just avoid US services entirely. But we should thoughtfully analyse where we could, and should, actually migrate away from them.

I will not stop using Instagram, Google or Claude. This very blog post is hosted on GitHub, which is owned by Microsoft. You might ask why. The answer is simple: it’s free. I don’t have to pay for a web server, and I don’t have to pay for scaling. US companies are simply the ones offering the best solution per buck. Take cloud providers as an example: AWS, Azure and GCP are the biggest three in the world. They’re widely used and well known by most developers out there, and they just offer great services. Need hosted Kubernetes? AWS EKS has you covered. Need a scalable, distributed database? No problem, here’s AWS DynamoDB or AWS Aurora. Need highly available object storage? Take a look at AWS S3.

Are there European alternatives? Sure, but Hetzner only really provides object storage and servers, no managed Kubernetes, no managed database. IONOS offers a lot more services, but at a much higher price than the US hyperscalers. Schwarz Digits seems promising, but at the time of writing I honestly don’t know that much about them yet.

And it gets even trickier than that. So far I’ve only been talking about hosting. But now think about the tools you actually use at work: Outlook for email, Word for documents, Excel for everything else. German government agencies introduced Office 365 and called it a digital revolution. And there are plenty of other services too that originate from the US.

All of this can start to feel incredibly unsolvable. But is there a solution? It’s actually pretty simple: open source software. Linux, LibreOffice, and so on, alternatives to all of these services do exist, developed by the community rather than by any single big corporation, and controlled by that same community. Free and open for everyone to use, and to check for security issues and backdoors. If you self-host those services within the EU, no US company can just grab your data, because you’re running your own stack.

That sounds very promising, but of course it isn’t that easy in practice. All the existing data currently lives in proprietary data formats, and while Excel can read LibreOffice documents reasonably well, it’s much harder the other way around. Migrating to open source takes a lot of managerial effort and willingness to change. And the most limiting factor of all is money. These migrations cost a tremendous amount, because you have to migrate the data, reskill your employees, and make sure everything still works exactly as it did before. That’s genuinely hard and challenging.

But there are already some very promising examples where it actually worked. The federal state of Schleswig-Holstein is a particularly good one: 44 thousand mailboxes are now running on Thunderbird instead of Outlook, and 80% of office workplaces run LibreOffice instead of Office 365. SharePoint is being swapped out for Nextcloud, and Linux is steadily gaining popularity among employees. At first, everyone laughed at Schleswig-Holstein for this. Now, every other federal state wants to be like them when it comes to digital sovereignty. Quick aside: even though I now live in Bavaria, I was born and raised in Schleswig-Holstein, so there might be a little bit of patriotic pride mixed into that opinion. Nevertheless, the facts speak for themselves.

Munich also follows an open-source-friendly approach and tries to use as much open source software as possible. And even the government in Berlin is making progress. The Federal Ministry for Digital Transformation and Government Modernisation founded ZenDiS, which roughly translates to “hub for digital sovereignty” and it has a lot of promising projects running already. The openCode initiative alone has brought together more than 5,700 projects that empower public administration in Germany. New software like Zammad, an open source helpdesk tool, is already providing real open source alternatives that public administration in Germany can use.

Quick note: I’m also contributing to openCode myself, on a project called KernUX, a design framework meant to standardize how certain government websites look, so that users get a consistent experience across different municipalities as they all follow the same design guidelines. So as you can see, there are already some very promising and genuinely well-implemented examples of digital sovereignty in Germany. But as always, there’s still a lot of work left to do.

What was the purpose of this article, then?

In general, I wanted to shine some light on this topic, because a lot of people simply aren’t aware of it. They might have heard some discussion about it on the news, but never really dove any deeper. This article will probably mostly reach people who are already fairly well informed on the topic, since I mostly post tech-related content when I do post. But maybe you have relatives or friends who aren’t especially tech-savvy, or who just don’t know much about this yet. Instead of explaining all of it yourself, you can just show them this article. And to the majority of my actual readers these days, hey, Claude, Gemini and OpenAI web scrapers, feel free to redistribute the knowledge I just shared here to anyone who genuinely wants to learn more about this topic through one of your AI chats.

And if you decide to do something about it, its even better. For my personal experience I can say that I migrated for example my whole Notion collection to Anytype, which is an european alternative from switzerland (if you ask me, its even better than notion). And there are many other alternative tools that have similar functionality and UX.

In general, I hope I could motivate you to take a closer look at which services you use, and which of them you’re handing your personal information to. Always remember, if it’s free, you might be the product yourself, and sometimes, even if you pay for it, you still are. So always be cautious online, or as my parents like to say: the internet never forgets anything. And they might just be right about that one.

Everytime I faced a problem in the software engineering process, it was somewhat related to poor complexity management. You might not think it is related to complexity issues, but at some point it is.

What is complexity exactly?

Complexity is a multi-faceted term. I won’t use some encyclopedia description made up of hard to understand phrases in order to explain it. Let me give you some probably relatable examples instead.

Everytime you wonder why the code looks like a mess, it’s because you did not manage to gauge the complexity of the function beforehand and ended up building it without thinking about how to split it up or write it in a more readable way. If you’ve read the Clean Code book you might know that you can write a whole philosophy on the readability of code. Complexity is exactly that. Complex code is harder to read, and therefore also harder to understand. You can reduce complexity by splitting up your functions into smaller functions that each do exactly one single thing. That reduces the complexity of each individual function to a minimum and makes the overall complexity more manageable and easier to oversee.

This also relates to the number of parameters you can pass to a function. The more parameters, or the more complex those parameters are, the more unpredictable the actual outcome of the function becomes. Let’s compare those two functions:

// Function one
fn do_something(a: u32) -> u32

// Function two
fn do_something_else(a: u32, b: HashSet<Vec<HashMap<String, String>>>, c: bool) -> u32

As you can see, the second function is a lot more complex. We have three parameters, of which the second one is a very complex datatype. Testing this is a nightmare. You won’t even get close to an acceptable test coverage. And even if you get there, how do you ensure the thing actually works as expected?

Ensuring the integrity of the whole software gets even harder when a function requires interaction with other classes or services. It’s pretty straightforward to unit test a single class, or even multiple classes independently. It starts to get really tricky when you have to integrate different components together.

Where is complexity management most important?

Complexity management matters most when you have multiple services or components in a system that are loosely coupled. You often don’t know which service will communicate with which other service. It’s a nightmare to manage, debug and prevent.

Let me give you an extreme example: car software.

Modern cars are more like a driving smartphone than our classic understanding of a vehicle. And they have one specialty that is a nightmare in terms of complexity management: they are highly configurable. I bet everyone has, at some point, opened the website of a premium car manufacturer like Porsche, Audi, BMW or Mercedes and configured their dream car. But have you ever thought about what this configurability means for complexity?

Just imagine how many different configuration options for seats there are: normal or sport seats, heating or no heating, cooling or no cooling, massage or no massage, leather or fabric. All of those are almost freely configurable. That’s 2^5 = 32 different seats! And almost all of those options have an effect on the underlying software. Now imagine all the other options you can pick during the configuration process.

Without proper complexity management, it’s impossible to ensure the car works as expected at all. Of course this is an extreme example, but there are plenty of other applications that handle very loosely coupled use cases and can lead to unwanted side effects in the same way.

Let me give you another example, a more regular one this time. Microservices are a modern trend. Everyone implements applications using them, and they are often developed within an event driven architecture. This means every service does not call any other service directly, but goes through a message broker instead. So we actually don’t always know where a message is being processed and where it isn’t. Debugging this is a nightmare, because you can run into side effects and bugs that are caused purely by the sheer complexity of those architectures. This is exactly why companies like Celonis exist. Their whole business is finding out what actually happened inside those highly loosely coupled, distributed architectures. If you haven’t done proper complexity management, I wish you the best of luck being on call and trying to find the cause of the random bug that just took your production environment down.

Log monitoring might help you find the bug, but it does not solve the root cause: complexity. If your system is too complex for you to know what happened, you must either ensure that certain things can only happen under certain conditions (and document those conditions properly, and keep that documentation up to date), or you have to rebuild parts of the system from the ground up so that you can actually handle the complexity of the overall application.

How can I manage complexity then?

I already talked a little about how to manage complexity, but let me dig a bit deeper now.

One of the simplest tools you have is the Law of Demeter, sometimes described as “only talk to your immediate friends.” Instead of reaching through an object to grab something from an object it holds, and then reaching further into that, you ask the object directly for what you need. Every extra hop you allow through your codebase is another hidden dependency between parts of your system that were never supposed to know about each other. The Law of Demeter forces you to keep those chains short, which keeps the blast radius of any change small and predictable.

Closely related is the difference between abstraction and indirection, two things people tend to confuse. Abstraction hides complexity behind a simpler interface, so the caller genuinely has less to think about. Indirection just moves the complexity somewhere else without actually reducing it, and often adds a layer you now have to jump through to understand what’s really going on. Good complexity management is mostly about honest abstraction. Bad complexity management is often indirection wearing an abstraction’s clothes: an extra layer, an extra interface, an extra factory, that makes the code look cleaner while making it strictly harder to reason about.

Pure functions help here too. A function that only depends on its inputs and only produces an output, without touching global state or reaching out to some shared mutable variable somewhere else, is trivial to test and trivial to reason about. You can look at its signature and know exactly what it can and cannot do. The moment a function starts depending on the outside world, whether that’s a global, a database, or some hidden singleton, you lose that guarantee, and the number of scenarios you have to think through to trust the function explodes.

At the architectural level, Bounded Contexts, a concept from Domain-Driven Design, are one of the most effective tools for taming complexity in larger systems. Instead of trying to build one giant, shared model of your entire domain that every team and every service has to agree on, you draw explicit boundaries around areas of the business where a model, its language and its rules stay consistent. Outside that boundary, the same word can mean something different, and that’s fine, because the boundary itself is where translation happens. This keeps individual contexts small enough to actually understand, instead of forcing everyone to hold the entire system in their head at once.

CQRS, Command Query Responsibility Segregation, tackles a different kind of complexity: the complexity that comes from trying to make a single model serve both reads and writes equally well. By splitting the write side from the read side, you can let each of them evolve independently, optimize them separately, and avoid the situation where every feature added to one side quietly makes the other side more complicated too.

Finally, for complex distributed systems, it can be worth employing formal analysis using feature models to find dependencies and analyse the tree of connections between components. Feature models let you make the variability of your system explicit, as a structure you can actually inspect and reason about, instead of something that only lives implicitly in configuration files, environment flags and tribal knowledge. Once that variability is visible, you can start actively reducing it instead of just living with it.

If you ask me, feature models are the most promising tool when you have legacy systems that are just hard to refactor properly or when you are building highly complex distributed systems with shared functionality and a lot of indirect interaction. But as I am still conducting more research into that direction, I haven’t fully made up my mind about that certain technology. Nevertheless, feature models can definitely help to visualize your variability through feature model counting.

Let’s put it all together

None of these tools are a silver bullet on their own, and that’s kind of the point. Complexity management isn’t a single technique you apply once and then forget about, it’s a mindset you carry into every decision you make while building software: how many parameters does this function need, does this class really need to know about that other class, does this boundary actually reflect how the business thinks about this concept, or is it just how the code happened to grow.

The car configurator example and the microservices example both point at the same underlying truth: complexity doesn’t announce itself. It creeps in one seemingly reasonable decision at a time, one more parameter, one more service, one more shared piece of state, until one day you’re on call at 3am trying to figure out why production is down, and the honest answer is that nobody fully understands the system anymore.

The good news is that every tool I’ve mentioned here, the Law of Demeter, pure functions, bounded contexts, CQRS, feature models, exists precisely because other engineers ran into the same wall before you did. You don’t have to rediscover all of this the hard way. Start small: keep your functions honest, keep your dependencies short, and draw your boundaries on purpose instead of by accident. Complexity will never fully go away, but it can absolutely be managed, and that, more than any specific pattern, is the actual skill worth building.

But recently, things have started to shift.

Over the past few months, I found myself reaching more often for lightweight editors instead of firing up a full-blown JetBrains IDE. It wasn’t a conscious switch at first—more like a gradual drift. But eventually, I started thinking more critically about my workflow, the tools I use, and what actually fits best for the kind of personal projects I’m working on now.

In this post, I want to share that journey with you: the decisions I made along the way, what I learned from using both types of tools, and ultimately why I don’t rely on JetBrains software as much as I used to.

Why Jetbrains at all?

When I first started using JetBrains products, I was just another bloody beginner trying to make sense of programming. Back then, I had no clue what I was doing, and honestly, JetBrains IDEs were a huge help in getting me off the ground.

They made it really easy to explore the basics of a language — how it’s structured, how it works, and what’s even possible. I still remember how convenient the project templates were. As a beginner, having those ready-to-go setups was a lifesaver. (Although, to be fair, I haven’t touched one of those templates in almost four years now.) Another big help was the integrated documentation support. Being able to look things up right inside the IDE made learning so much smoother.

As I gained more experience, I started thinking beyond just writing code. Suddenly, tools for working with Git, managing databases, or debugging became a lot more important. And while there were always editors or extensions out there for each of those things, JetBrains IDEs were the only ones that offered all of them in one place — and at a surprisingly high level of quality.

Let me show you what I mean using PhpStorm as an example.

Git Integration That Just Works

If you’ve ever worked on a team or maintained multiple branches, you’ve probably run into merge conflicts. JetBrains’ Git tools—available in all their IDEs are hands down the best I’ve used for handling them. You get a clear visual diff, an intuitive 3-way merge view, and the whole process just makes sense. Could I resolve conflicts by hand? Sure. But this tool saves time and reduces mistakes, which makes it a no-brainer.

Framework Awareness

As a PHP developer, I spend a lot of time with frameworks like Symfony and Laravel. PhpStorm doesn’t just understand PHP — it understands the ecosystem around it. It recognizes things like service config files, offers templates for REST controllers or repository classes, and even integrates with tools like PhpStan or PhpCsFixer. It can apply formatting automatically based on the rules those tools define, which is a small touch that adds a lot of value.

SQL Support That Goes Beyond Highlighting

Writing SQL directly in your code? PhpStorm doesn’t just highlight the syntax — it validates your queries based on your selected database type (PostgreSQL, MariaDB, SQL Server, etc.) and even against the current schema. That level of context-aware support is a huge productivity booster.

Built-In Database Tools

Speaking of databases: the built-in database browser is fantastic. You can inspect tables, edit schemas, and run queries right inside your IDE. You don’t need a separate tool like Adminer or pgAdmin for most tasks. Everything is right there — and it just works.

Dev Containers, Debugging, and Language Versions

PhpStorm also supports dev containers, which is super helpful for working in isolated environments. And debugging with Xdebug? Seamless. Yes, other IDEs can handle this too, but there’s something about how JetBrains presents and manages these tools that just feels… right.

One feature that really made my day recently is the way PhpStorm handles different PHP versions. Need to target 8.2 instead of 8.4? You can set the version, and the IDE will adjust its rules and suggestions accordingly. It’s a great way to catch compatibility issues early.

VIM Mode & Other Small Touches

I also use VIM motions, and having solid VIM support baked into the IDE is just another cherry on top. I know editors like VS Code offer this too, but again — JetBrains just seems to do it a bit better.

And of course, language-specific features like managing different Java versions in IntelliJ are super well-executed too. Honestly, there are so many features I love about JetBrains IDEs that I could probably write an entire post just listing them out. But that’s not really the focus here. The point is: JetBrains IDEs are seriously powerful, well-engineered, and full of thoughtful features that make development easier.

Why use something else?

As much as I love JetBrains products — and I really do — they’re not without their downsides. And over time, those downsides started to get in the way of how I like to work.

The first big issue I ran into was performance. I often work with very large codebases — 100k+ lines of code in some projects — and I usually have multiple windows open at once, switching between projects to look something up or cross-reference ideas. In that setup, PhpStorm can easily eat up 8GB of RAM, if not more. And that’s not even counting what the rest of my system is doing.

Then there’s indexing. Ah yes, the blessing and curse of JetBrains IDEs. Don’t get me wrong, being able to search through an entire project in milliseconds is amazing. That part of the experience is gold. But in larger codebases, the indexing process itself is painfully slow. Sometimes it takes several minutes to finish, and during that time, the entire IDE becomes sluggish. On top of that, I’ve even run into occasional crashes under heavy load. Maybe it’s just me, but it’s extremely frustrating when you’re ready to dive into work — and instead you spend five minutes staring at a progress bar or restarting the IDE after a crash.

Somewhere along the way, especially after diving into Rust, I started to care more and more about performance. Rust sort of rewired my brain for thinking about efficiency. It made me appreciate speed and simplicity in my tools, just as much as in my code.

That’s when I tried RustRover. And… well, it wasn’t great. At least not when I first used it. It felt slow, and some Rust features like macro recognition or autocomplete just didn’t work as expected. I’ve heard it has improved a lot recently, and I’m sure it’s in a much better place now. But that early experience left a mark.

Eventually, a friend of mine recommended Zed, and I decided to give it a shot. The start was rough, not gonna lie. I was missing a lot of the features I had taken for granted. Even proper Git integration wasn’t available at first. But instead of going back to what I knew, I leaned into the challenge. I started using the raw Git CLI — and surprisingly, it was fun.

Over time, I began to appreciate this more minimal setup. I didn’t need an IDE telling me everything. I didn’t need deep debugging tools or integrated database inspectors for my personal Rust projects. What I did need was a fast, stable, and distraction-free environment. Zed, with just a few plugins for Rust and React, turned out to be exactly that.

No heavy indexing. No unexplained crashes. No unnecessary abstraction. Just my code, my terminal, and whatever tools I choose to plug in.

I slowly realized that for personal projects, I don’t need everything JetBrains offers. I don’t need dev container integration, live SQL validation, or built-in PHP version managers. It’s all useful stuff, but in my current workflow, it feels more like bloat than help. This lightweight environment gives me a sense of control I hadn’t felt in a while. It pushes me to understand the tools I’m using, rather than relying on an IDE to smooth out the details. And that’s something I’ve come to really value.

To what will I stick in the future?

To be honest, this hasn’t been a simple or clear-cut decision — and even now, I’m not 100% sure where I’ll land long term.

For work projects, I’m definitely sticking with JetBrains tools. There’s just no replacement (yet) for the kind of power they offer. Full-text search across massive codebases is something I rely on daily, and the deep debugger integration, real-time SQL validation, and seamless Git support are must-haves in my day-to-day workflow.

A lot of the projects I work on involve multiple Git repositories—sometimes even split across submodules. Managing that level of complexity manually would be painful. JetBrains makes it manageable. And when it comes to resolving messy merge conflicts, their visual merge tool continues to be a lifesaver. It’s one of those features that, once you’ve used it, you never want to give up.

But for personal projects, the story is different. I want something lightweight. Something focused. Something that lets me just write code and enjoy the process without waiting for indexing or watching my RAM usage creep toward double digits.

That’s where Zed comes in. As long as it keeps supporting Rust and React well — and stays as clean and fast as it is now — I’m happy to use it for my personal coding. It’s minimal, fast, and gives me the kind of low-level control that makes the whole dev process feel more “hands-on”. It’s just the code. Everything else I manage my self in my terminal emulator. No extra abstractions. No bloat. Just the essentials.

That said, I want to be clear about one thing: I’m still very much in love with JetBrains. In my opinion, they’re the best in the industry at what they do. Their products are thoughtful, powerful, and built with real developers in mind. They’ve helped me grow from a total beginner to a confident, professional developer — and they’ll always have a place in my heart.

So while I might not reach for a JetBrains IDE every time I spin up a personal project, I’m not going anywhere. For the big stuff — the mission-critical, get-things-done kind of work — JetBrains is still my go-to.

And I kind of love this balance.

Today, things are very different. I genuinely enjoy working with Rust. This is not only because I understand the language better now, but also because I have found a tech stack that suits my way of building software.

What technologies did I use before rust?

Before I started learning Rust, I was mainly working with Java and especially Go. For web development, I used Go in combination with Fiber as my library of choice.

What I loved about Go back then is actually the same thing I love about Rust today: simplicity. I came from heavier frameworks like Quarkus, Spring Boot, and Symfony, all of which offer large ecosystems for building web applications.

Don’t get me wrong, I still really like working with Quarkus and Symfony. They are great tools, and I enjoy using them. However, Go felt lightweight. Error handling was simple, without the need for complex try-catch clauses. It offered high performance without requiring me to think too much about memory management or other low-level concerns. That was the main reason why I used Go for a long time.

In fact, I still use Go today. Not as much as I used to, but I still find it a great choice for lightweight microservices. Its ease of use, broad support, and the almost endless range of use cases made Go my go-to language—at least until I truly discovered Rust.

My personal rust learning experience

Learning Rust is not like learning most other programming languages. Before you can even start writing useful code, you need to understand quite a few theoretical concepts.

Back when I first tried to learn Rust, I had very little interest in theory. That turned out to be a big mistake. I struggled a lot and found even basic things difficult. Traits? I had no idea how to use them. Copy and Clone? No clue. The borrow checker? What even is that? Macros? I thought they were like keyboard macros. And then there was tokio, futures—wasn’t Tokio the name of a city? Rc, Arc, Mutex, RwLock, Cow? I didn’t know what any of that meant.

To be fair, some of it still feels like magic to me today. I’ve never written a complex macro, and I couldn’t tell you the exact differences between all the async runtimes. But that’s fine. I plan to explore those topics more deeply in the future.

Right now, I’m at a point where I can build microservice applications that query and store data in a database and maybe do some calculations. And that’s good enough for me at this stage. To be clear, I’m still far from mastering Rust. I wouldn’t even call myself an intermediate developer in the language. There is a lot left to learn. But I know enough to get things done.

So if you want to learn Rust, do yourself a favor and start by reading The Rust Programming Language book. That’s what I should have done in the first place. I actually own the print version now. But you don’t have to buy it—the online version is available for free.

What I use it for now

By now, I’ve almost completely replaced the work I used to do with Go by using Rust instead. Most of the monoliths and microservice applications I write today are powered by Rust. Well, most of them. I still use Kotlin and Go for certain use cases where they make sense or where I just feel like using them.

For web development in Rust, I mainly use Actix as my framework of choice. It is simple to use and offers exactly the features I need.

When it comes to database connectivity, I’m currently using sqlx. I also tried Rust for another project where I initially used Diesel, but it felt a bit too heavy for my taste. I tend to prefer simpler solutions, and sqlx fits that mindset better.

Why do I love it so much

You might ask why I’m now so in love with Rust, even though I had such a hard time learning it in the beginning.

The answer is simple: when I write Rust code, it is solid. And I don’t just mean memory safety. All those small mistakes that can easily slip through in other languages are basically non-existent in Rust, thanks to its strict type system.

When I use sqlx, for example, I can only use specific types for my database structs because the code is validated against the database schema at compile time. The same applies to SQL queries. It’s ensured that the query structure matches the data types I use to store the result. I rarely run into bugs that are not caught at compile time. And when I do, they’re usually easy to track down because I know exactly which kinds of errors cannot happen. Debugging in languages like Kotlin or PHP often drives me crazy. In Rust, it’s relatively calm and predictable.

I also really appreciate Rust’s simple approach to writing code. This might sound paradoxical at first, since learning Rust is hard. But once you understand how the basics work, you can get results quickly and without unnecessary boilerplate. You can write useful code in Rust without fully understanding all the deeper concepts. But if you want to go deeper, you can take advantage of powerful features like macros to simplify and automate parts of your codebase. And throughout it all, memory safety is built in by design.

By now, I’m very familiar with my Rust ecosystem. I can write functionality just as fast as I can in Kotlin, PHP, or Go—sometimes even faster. But with one major advantage: I never have to worry about data type mismatches, null pointer exceptions, or other runtime errors. My toolchain takes care of all that. Invalid time format in a JSON body? If Actix can’t deserialize it using serde, it will handle the error for me.

I can be completely confident that the data I receive in requests and send in responses is exactly what I expect, both in format and type. And that’s what I love so much about Rust. It might take more effort to ensure memory safety and implement certain features compared to other languages. But that effort pays off in the long run.

Will I stick to rust in the future?

The question is pretty simple to answer: yes.

But the full answer is not quite as straightforward as it might seem. I really love Rust, and I want to continue learning more about the language. I’m especially interested in exploring its more advanced features and digging deeper into how it works.

That said, I won’t become a typical Rust purist. Not everything I build will be written in Rust. It is definitely my favorite language at the moment, no doubt about that. But I’m also curious about other technologies. For example, I’m considering learning Zig at some point. Even though it’s still relatively unpopular, it seems like a very interesting language to me. I will continue to use other languages for my projects as well. Go and Kotlin will definitely remain part of my tech stack for specific use cases, especially when building microservices.

However, Rust will stay my primary backend language for now. And I’m convinced that it will continue to grow in popularity over time, thanks to its strong advantages and evolving ecosystem.

I strongly disagree with this narrative and frankly, I find the whole trend deeply frustrating. Most of these vibe-coded apps are not only rushed but also poorly architected and alarmingly insecure. What is being celebrated as innovation often lacks the fundamentals of sustainable and responsible software development.

Vibe Coding is not only using AI

As far as I know, there is no clear or widely accepted definition of vibe coding. So before I continue, let me explain what I personally mean by it.

To me, vibe coding is not simply about using AI to assist in software development. That distinction is important. When you use AI as a tool, for example to generate boilerplate code, refactor functions, or get unstuck, you typically have a solid understanding of software development fundamentals. You know how to design architecture, apply appropriate software design patterns, and critically assess the code you write, including code suggested by AI. You are able to spot mistakes and poor practices because you understand the broader context.

Vibe coding is something different. It is more abstract and, frankly, more careless. In vibe coding, the AI effectively becomes the architect. It chooses the patterns, structures the code, and makes key decisions while the developer blindly follows along. There is little concern for how things are implemented, as long as they appear to work and the application looks functional on the surface.

This, in my view, is exactly how many of the new, self-proclaimed “cool” SaaS builders operate online. It is thirty percent coding and seventy percent tweeting about how revolutionary their AI-written note-taking app is, often without any understanding of what is actually going on under the hood.

Why is vibe coding bad?

By now, you can probably already imagine why vibe coding is such a bad idea.

You’re essentially pushing code to production without any real verification. And how could you verify anything when you don’t actually understand what the code is doing in the first place? Without a solid grasp of software development, you’re left blindly trusting that whatever the AI generates is correct, secure, and maintainable, which is wishful thinking at best.

It’s like deploying an application and simply hoping that it’s not vulnerable, that everything magically works as intended, and that no edge cases will ever break it. Spoiler: they will.

Unfortunately, I no longer remember where I originally found this image. If you happen to recognize it, please let me know so I can give proper credit.

I believe this image perfectly captures why vibe coding is such a huge problem.

AI confidently provides output that looks correct until you ask the right question. But to ask the right question, you need to understand what the code is actually doing. And that is exactly the issue: many people do not.

We have all seen examples of developers accidentally committing API keys to public GitHub repositories or deploying highly insecure applications simply because they lacked the knowledge to question the AI’s output. This is not a rare mistake; it is the consequence of not knowing enough to validate or challenge what the machine suggests. That is why vibe coding is not just misguided, it is dangerous. In the past, the barrier to writing code was that you had to know how to do it. Now, with vibe coding, you can build and deploy something without truly understanding software development. That might sound empowering at first, but on closer inspection, it introduces serious risks.

Software engineers are engineers. Would you feel safe driving a car that was vibe engineered by someone with no training in mechanical engineering? Would you take medication developed by a vibe pharmacist? Most likely not. Sure, software might seem more harmless, but it can still be critically vulnerable. Storing passwords in plain text, skipping hashing and salting, means one data breach and your password, which you probably use for multiple accounts, is out in the wild. Even if it is just your email address, that is enough for phishing, spam, and identity fraud.

When I use an application, I want it to be secure and not accidentally secure. Most of all, I want it to work as designed, not as vaguely intended by an AI. That is a big difference. Maybe it is just me, but I am genuinely worried about the direction this is heading. Do not get me wrong, AI is an incredible leap forward for developer productivity. But replacing developers altogether might turn out to be a massive mistake.

The limitations of AI

AI is undeniably good at certain things, especially when it comes to writing boilerplate code or suggesting best practices. For common, well-documented problems, it often delivers solid results. Tasks that have been solved countless times before, AI can handle those reasonably well.

But the moment your problem becomes even slightly more complex, things start to fall apart. Take this example: writing simple database pagination in Rust using Diesel is no problem for most AI models. However, introduce just one extra trait bound into the mix, and suddenly no model seems to get it right. Despite the fact that the correct solution is relatively straightforward for someone with a bit of Rust experience, the AI fails.

This illustrates a deeper issue. AI is fantastic for repetitive, boring tasks. It can help generate tedious glue code, refactor existing logic, or even provide high-level scaffolding. But it still struggles with semi-complex problem solving, especially in more niche or strongly typed languages like Rust.

That is because today’s most powerful models are still narrow AI. They do not truly understand what they are doing. They cannot generalize, adapt, or reason beyond what they have seen. They are built to mimic, not to think. They rely entirely on patterns and examples found in the training data, code written by humans, often taken from the public internet. And here is the problem: as the internet becomes more and more flooded with unchecked AI-generated code, the quality of that training data will inevitably decline. This creates a feedback loop that could make future AI models worse at programming, not better.

The real breakthrough would be Artificial General Intelligence, or AGI. That is the holy grail, an AI that can truly reason, learn, and solve problems across domains. But despite billions of dollars in research, AGI remains a very distant and very uncertain goal. It may never be achieved.

So please stop telling developers they are about to be replaced, especially when your entire coding experience consists of launching a painfully insecure and painfully slow SaaS that barely has five users. No, I am not afraid of the future and I am certainly not afraid of losing my job. What I am concerned about is the growing trend of people refusing to think critically. Evolving with technology means understanding it and using it responsibly, not blindly outsourcing your thinking to it.

Will some developer roles disappear? Probably. With AI taking over more repetitive tasks and templated design patterns, the demand for junior developers might shrink. But will software engineers as a whole vanish? That is far from certain, and frankly, I doubt it.

How to use AI properly

In my opinion, AI is just another tool, a powerful one that can significantly boost developer productivity. But like with any tool, the key is knowing how to use it properly. And the most important rule is to always verify what the AI gives you.

If you do not understand the code, do not use it. Try to understand it first. Treat AI-generated code like you would code from a teammate. Review it thoroughly, test every edge case you can think of, and do not trust it blindly.

Let us take a simple example. Imagine you are building a REST API with basic CRUD operations and your database schema is already defined. That is a task AI can easily handle, saving you maybe 30 minutes of routine work. But once the code is written, your job is not done. You need to ask yourself if authorization is implemented correctly, if the right properties are exposed through the API or worse, if there are any sensitive fields leaking out. Are the database queries efficient? Is caching implemented in a sensible way? Is there proper rate limiting? And are the endpoints named consistently and meaningfully?

Only after checking all of these things and making the necessary improvements is the code truly safe and ready to use.

In fact, this blog post is also partly written with AI. I created the bullet points and structure and the AI helped shape them into coherent text. But I reviewed and validated every section. That is exactly how it should be. AI assists, you remain in control.

When you encounter something new, you can absolutely use AI to support your learning process. But do not start by asking it to write the solution. First, think through the problem yourself. What would be an efficient and clean solution? Only then should you turn to AI, not to write code for you but to provide background information, suggest known algorithms, or point you to RFCs and technical standards that are relevant to your use case.

With that knowledge you are in a much better position to write correct and understandable code and more importantly to reason about it.

It really is that simple.

When learning new things, AI can be a solid partner. It can help prepare study material or generate more advanced questions to test your understanding. It is a great tool for accelerating learning but it should never replace your own thinking.

AI has the potential to boost your productivity beyond what was possible with traditional tools. But it should stay what it is, a tool. If you let AI do all the thinking, your value as a developer drops to zero.

So do not be careless. Do not be passive. Use your brain.

But lately, I’ve been seeing more and more people who really trigger me.

Many of the people you see on social media might initially seem to offer a great deal — but if you take a closer look, their services are often quite poor. Sometimes, they even lie straight to your face.

A bit of background information

Before we dive in, you need a bit of background to understand what really matters when building a website or a custom application for clients.

Creating a website isn’t just about choosing a CMS or applying a fancy template. It’s about building a cohesive brand identity for the people you’re working with. Let me walk you through the entire process.

When you receive an initial request to build a website, the first step is to understand your client’s actual needs. What is the primary purpose of the website? Is it to boost sales? Increase awareness of the client’s mission? Generate leads? This clarity is essential, because everything you build — from structure to content — should serve this core purpose.

Once that’s clear, you need to think about project management. You’ll have to estimate costs: hosting, legal services, ongoing maintenance, and your own work. Transparency is key. Explain how the price is calculated and why it is what it is — high, low, or somewhere in between. Identify all stakeholders and make sure the project’s framework conditions are crystal clear. If you skip this step, your project is likely to fail due to misalignment and lack of agreement with the client. But once the organizational groundwork is laid, the “real” work can begin.

Next comes screen design. What pages are needed? What content should go where? What type of content are we even talking about? Which colors and design style suit the brand? Should it be modern, retro, minimalistic? Every design decision should serve the primary purpose defined earlier. And no — a random WordPress template does not fulfill all of your client’s needs. Sure, templates can work in low-budget scenarios or when a generic solution is acceptable (which might be the case in 1% of all projects). But if the goal is to build something purposeful and custom, a template just doesn’t cut it.

Templates are too generic. They’re designed to meet many use cases at once, but not specifically yours. And let’s face it — most template-based websites look the same, which makes it hard to stand out from the competition. A better approach? Use a framework like Bootstrap as a starting point and customize each component to match the client’s individual needs. Use the grid system as your foundation, but then tailor everything to truly serve your client.

Also, choose a CMS or page builder that allows for custom extensions and plugins. Ideally, it should be open-source and self-hostable. Why? Because your client’s needs will evolve. Imagine you build a site for a barbershop. Initially, it’s just about listing prices and attracting local customers. A year later, they want an online booking system. Or imagine your current hosting provider becomes insecure or non-compliant with data protection laws. In such cases, being able to migrate quickly is essential. Tools like Webflow, with their closed ecosystems and vendor lock-in to AWS, can be a serious limitation. A self-hosted, open-source CMS gives you far more flexibility and control.

Even after the content and layout are finalized, your work isn’t done. These days, SEO matters — a lot. Ideally, you should consider SEO from the very beginning, even before laying out your first design wireframes.

And when it’s time to buy the domain, make sure the client owns it. Have them register the domain in their name and give you access only to the DNS settings — unless you’re explicitly authorized to register domains on someone else’s behalf. This protects your client from vendor lock-in. Clients should stay with your agency because of your excellent service, not because you hold their domain hostage. Anything else is just unprofessional.

Then there’s the legal aspect. At minimum, every website needs an imprint (Impressum) and a privacy policy. Don’t underestimate this. ChatGPT can’t reliably write these for you. Services like e-recht24.de can help, but in some cases, you’ll need a real legal expert to make sure your site is compliant. It’s always safest to consult a lawyer or someone well-versed in online privacy laws, rather than blindly trusting a generator.

And no, it’s not enough to just list your cookies in the privacy policy and install a free cookie banner. You must ensure that no external resources are loaded before a user gives consent. And if they decline, those resources must not be loaded. Most cookie plugins don’t handle this properly.

Here in Germany, there are three key laws you need to be aware of: the european GDPR (DSGVO), the BDSG (Bundesdatenschutzgesetz), and the BFSG (Barrierefreiheitsstärkungsgesetz). Familiarize yourself with them and understand the limitations they impose.

When you’re developing custom software for clients, the standards become even stricter. Your software must follow up-to-date security practices. That takes professional experience — or at least several years of serious hobby development. When I first started out, I lacked that experience, and I built some truly awful apps for other people. Thankfully, they’re no longer in use! Those applications were completely insecure, poorly architected, and a nightmare to maintain.

So, if you’re building production-grade software for clients, make absolutely sure you know what you’re doing. It’s not enough for ChatGPT to know — you need to know. You should be familiar with architecture, design patterns, security protocols, databases, and more. If you’ve just finished university and your only programming experience is a Java course you had to take, that’s not enough to develop real software without a senior supervising you.

Start with personal projects. Get your hands dirty. Learn. And I don’t mean build a basic calculator app — go deeper. Learn how to design scalable, maintainable, and secure systems. Do that before you start building for clients. Otherwise, they’ll end up with a mess—and you’ll be the one stuck cleaning it up.

So what are the people doing that triggers me

I spent a lot of time digging into the communities I mentioned earlier, trying to understand how those one man agencies actually work. I watched countless videos, read endless tweets, and even joined a few Discord servers to see things from the inside.

The most frustrating part? Some people blatantly lie to your face. Now, sure — it’s nothing new that people lie on the internet. But these folks are doing it to win over new customers. And that’s what makes it different.

Let me give you an example. Here in Germany, there’s a special corporate legal form called a “UG” (Unternehmergesellschaft). You can start one with as little as €1 in capital, but you’re required to save 25% of your profits until you reach €25,000. Once you hit that amount, your UG can be converted into a GmbH (a more robust corporate form).

Why does this matter? Well, there’s someone on social media who recently gained quite a bit of attention by posting flashy pictures with expensive cars, claiming he’s been running a successful software agency since 2017 — one that supposedly made him a millionaire. But if you check the public records on North Data, the company he’s referring to is still a UG and wasn’t even registered until 2021. So no, it didn’t start in 2017, and no, it didn’t make him a millionaire. It’s all just a tactic to gain attention and attract new customers — and in my opinion, that’s as shady as it gets.

But the real issue goes deeper. Most of these new “Webflow agencies” have no idea what they’re doing. After spending time in their Discord servers, I got a pretty good sense of how they actually work.

Remember what I said earlier about building websites with purpose? These people don’t even ask what the website is supposed to achieve. They just create something they think fits the client’s brand. There’s no real project management. Cost estimates are based on vague descriptions with no breakdown of how long each page or feature will take. No clear cost structure, no distinction between hosting, maintenance, and development. In many cases, they offer fixed prices — like €2,000 for a full website — without any real scope definition.

They often use off-the-shelf templates or buy one for around €50 and slightly modify it to “match” the client’s aesthetic. Spoiler alert: most of the time, it doesn’t.

Worse, they lock their clients into platforms like Webflow, which offer limited plugin support and make it hard to implement truly custom features. SEO is usually an afterthought — if it’s considered at all. And as if that weren’t bad enough, they even register the domains under their own names. That might seem harmless at first, but when the client wants to switch agencies, it becomes a nightmare.

Now let’s talk about the legal side — this is what really sets me off. These agencies either use generic GDPR generators or AI tools to spit out privacy policies and legal texts, with zero regard for actual compliance. They don’t even bother to check whether third-party content is being loaded before consent is given via a cookie banner.

Selling mediocre work? Fine — you’re just a bad agency. But ignoring legal compliance and relying entirely on AI to generate legal documents? That’s not just unprofessional — it’s reckless. If you operate like that, you should not be allowed to build anything for clients. But clients often buy into it anyway — because it’s cheap and they lack the knowledge to understand the complexities and limitations of professional web design.

And that’s just websites. When it comes to custom applications, things get even worse.

I’ll keep it short: most of the people I encountered have no real experience. They’ve watched a few Python tutorials and now believe university degrees are pointless because they “already know everything” about building applications. Some of them hadn’t even heard of password hashing. One guy thought it referred to choosing strong passwords across different apps.

These people are building production systems — used by real companies and organizations — with no knowledge of software architecture, no understanding of privacy regulations, and zero awareness of secure development practices. And when things get complex, they just ask ChatGPT.

From the perspective of a professional developer, it’s genuinely sad to see.

So what would I do better?

Lately, I’ve been seriously thinking about starting my own web design agency — which is also one of the reasons I decided to write about this entire topic.

First and foremost, the most important investment would be in a legal and privacy expert. That’s not just crucial for me personally, but also for the protection and trust of my future clients.

From there, I’d take a truly individual approach with each customer: sitting down with them to understand their specific needs and building a custom website tailored exactly to those goals. No templates, no baseless cost estimates.

If you really want to run an agency that delivers meaningful value, you need to take time — lots of it. It’s not just about building a website; you also have to host it, maintain it, and provide long-term support. That all adds up quickly.

And here’s the core issue: you simply can’t build a legally sound, fully custom website that truly serves the client’s needs for just €2,000. The bare minimum for a small, well-built site is around €5,000.

This is exactly why I haven’t started my own agency yet — I just don’t have the time right now to offer the level of service I know would be necessary. I understand what it takes to build a truly effective, secure, and purpose-driven website. And that kind of quality takes time — and therefore money. The websites I’d build would naturally be more expensive than what most of the cheaper agencies offer, simply because I’d invest far more effort into getting the right result for the customer. But I also don’t want to compromise on quality. I want to deliver the standard I would expect myself if I were the customer. And if I can’t achieve that with the resources I currently have, then I’d rather not do it at all. I’d feel uncomfortable offering a lower-quality solution at a cheaper price — especially knowing it might not truly meet the client’s needs. But maybe that’s just my perfectionism speaking.

That’s also why these low-cost agencies remain so profitable: they’re the cheapest option on the market. Sure, your local barbershop doesn’t need a highly sophisticated website to function. But if the website looks like every other barbershop’s site, it becomes practically useless — it offers no unique selling point, no reason to stand out.

What can we do to avoid those people?

To be fair, not every one-person agency offering a €2000 website is necessarily bad. There are plenty of talented individuals out there who know exactly what they’re doing.

But in order to distinguish good agencies from bad ones, we need to take some action. One — admittedly unrealistic — approach would be to require some form of certification before someone is allowed to build websites professionally, similar to how other industries are regulated.

Take the automotive industry, for example. Cars must undergo rigorous safety and quality inspections before they can be sold to consumers. The issue with web development is that it’s extremely accessible. Anyone can watch a two-hour YouTube tutorial, start tinkering with Webflow or WordPress, and piece together a basic website. But the result often falls short of what a professional would define as a high-quality product.

Just like a car buyer might judge a vehicle by how fast or comfortable it feels, without understanding the inner workings of its engine or structural integrity, a client can think a website looks good while missing the fact that it fails to meet key needs — or worse, isn’t even GDPR-compliant. Without a technical background, clients can’t reliably evaluate the actual quality of a website.

This is where certification could come into play. If anyone who wants to build websites for clients were required to obtain a certification from a recognized institution, it would help ensure that basic quality and privacy standards are met across the board. Of course, implementing such a system would require political will and infrastructure, which makes it a long shot for now.

A more realistic approach is raising awareness among the general public. People should understand that a €2000 website is unlikely to meet the standards of a modern, professionally built site. If more people become aware of the risks and limitations, the market could begin to regulate itself. Clients would be more selective, and low-quality providers would eventually get weeded out.

The same logic applies to building custom applications.

That said, I’m not an expert in either policy-making or economics — although I am a member of a political party and have a basic understanding of how markets work. I can’t claim with absolute certainty that these suggestions would have the desired effect, so I welcome your ideas and opinions in the comments.

If you’re a customer, be cautious. If your agency includes you in the development process and seeks your input regularly, that’s often a good sign. Also pay close attention to how they calculate their prices and how they approach legal compliance — especially GDPR. Ask detailed questions about their design process and how domain ownership is handled. Transparency in these areas is a major green flag.

And yes, even if an agency uses a privacy notice generator, that doesn’t automatically disqualify them. If the agency is open about it and offers a lower price as a result, that can still be a fair deal. Just be aware of what you need. Templates might work fine for some use cases. What really matters is transparent communication.

If an agency is upfront from the beginning about how its pricing is structured and why their service is either cheap or expensive, that’s a great sign. As always, it’s better to be cautious than careless.

A few days ago, I made the difficult decision to stop updating its dependencies. Letting go of this project was not easy for me. That’s why I want to share my experience with you—perhaps my thought process will be helpful if you ever find yourself facing a similar decision.

The projects starting point

To put it simply: from today’s perspective, the codebase is a complete mess.

I started this project in my early days as a software engineer. I wanted to learn a new framework and decided to go with SvelteKit, which was still in open beta at the time. So, I gave it a shot. To be fair, working with it was a great experience. But after a few months, I stopped working on the project—mainly because I stopped doing my math homework, lol.

As a result, there has been no real progress over the past few years. The entire project is based on outdated beta framework code. And to be honest, the code itself isn’t great—it reflects my lack of experience at the time.

Updating the project to the latest dependencies would require a significant amount of effort. First, I’d need to untangle the dependency mess. Some of the old npm dependencies are no longer supported or even necessary, as SvelteKit now provides built-in solutions for them.

Even after cleaning up the dependencies, I’d still have to refactor and migrate all the code to follow modern best practices for SvelteKit. On top of that, I’m not entirely sure how certain things work in SvelteKit today, so I’d need to do some research to fully understand all the new changes.

Influencing factors

Several factors influenced my decision on this topic.

First and foremost, there’s the effort required to migrate the project to the latest version of SvelteKit. As I’ve already mentioned, the process is quite complex and would demand a vast amount of time. Due to significant changes in how SvelteKit works, I would need to rewrite almost all of the code. While much of the logic could be reused, the migration would still be challenging. Additionally, finding suitable replacements for deprecated dependencies and framework functionality could be time-consuming. For example, Svelte CLI has been replaced by Vite, meaning I’d need to find new solutions for static exports and other features.

Another key factor is that there are no real security risks in not upgrading the dependencies. The application is a simple web app that runs entirely in the browser. It does not rely on external services or a backend, so I can confidently say that leaving the dependencies as they are does not introduce any security concerns. Moreover, the project has no real users—this migration would be purely for myself, not for a larger user base.

On the other hand, I do want to learn about the new techniques and improvements in SvelteKit. At the same time, deliberately choosing not to upgrade the dependencies creates an internal conflict for me. I hold myself to high standards—not because I think I’m the best developer, but because I want to continuously challenge myself and improve. Avoiding this migration on purpose feels like avoiding a challenge, which bothers me.

Lastly, there’s an emotional aspect to consider: I actually like this codebase. It serves as a memory of my 2021 self working on this project. Even though the code is objectively bad, I still find it somewhat beautiful. Refactoring it would feel like erasing a piece of that memory, which creates another internal conflict. That said, this emotional argument carries less weight compared to the practical considerations.

Final decision

Reaching a final decision was difficult. The significant effort required, the lack of users, and the minimal security risk were key factors in my decision-making process. I don’t have much free time to dedicate to personal projects, and upgrading the dependencies would consume a large portion of it—something I wasn’t willing to sacrifice.

Learning modern SvelteKit could just as easily be done with a new project. However, the thought of avoiding a challenge still weighed on me. And then there was the emotional aspect—I genuinely like my legacy code because it reminds me of the “good old days”.

In the end, I had to make a choice. I decided to act rationally rather than emotionally and ultimately chose to stop upgrading the dependencies of this project.

What can you learn from all this?

Personal decisions like this are difficult for everyone. That’s why I believe you might gain something from my thought process.

In the end, you have to make your own decisions. Simply copying mine would be the worst possible approach to tackling your own challenges. When facing a similar dilemma, you should certainly consider the emotional value of your project. However, it’s equally important to think rationally about all the influencing factors. Acting rationally while setting emotions aside can be difficult at first, but trust me—it will ultimately lead to the right decision.

Of course, emotions matter. And in project management, they are crucial when working with team members. But when it comes to the hard facts of a project itself (rather than the human component), decisions should be made rationally.

Take my case, for example. I loved this project—it was one of my first web development projects, and I worked on it for over two months. It had significant emotional value to me. Yet, deciding not to upgrade the dependencies was still the right choice. The effort simply wouldn’t have been worth it. I can still work on the project, but only with its outdated beta framework.

As I said, emotions are important, but so are the hard facts. When collaborating with others, their emotions and perspectives should be a priority. But when it comes to making technical decisions about the project itself, a fully rational approach is the best way to achieve the best outcome. In the end, acting rationally benefits everyone involved—it’s a win for all.

Why is it hated so much?

In its early days, PHP was considered quite insecure. Many of the CVEs at the time were related to PHP, reinforcing its reputation as an unsafe language—an assessment that was accurate back then. Additionally, the language had an overwhelming number of configuration options. Different configurations across devices often caused certain features to work on one system but fail on another. These configurations extended beyond basic settings like maximum file upload sizes, execution times, or memory limits to options that control error handling, which can significantly impact an application’s behavior and security.

PHP is also regarded as an outdated language by some. Object-oriented programming (OOP) was introduced relatively late with PHP 5. Additionally, the standard library lacks an organized namespace, which is another common criticism. Many other important features, like OOP, were also added much later than in other languages. For instance, enums were only introduced in PHP 8.1, released in 2021. Moreover, PHP did not have a package manager until 2016, when the first stable version of Composer was released. By comparison, Maven had its first release in 2004.

Another common criticism of PHP is its syntax. For instance, array iteration functions are much more elegant and efficient in other languages compared to PHP. Here is a brief example:

JavaScript:

result = myarray.map((x) =>  x.property)
        .sort((a, b) => (((a == b) ? 0) : (Math.pow(a, 2) > Math.pow(b, 2)) ? -1 : 1))
        .reduce((a, b) => a * b);

PHP:

$unsorted = array_map(fn($x) => $x['property'], $array); 
uasort($unsorted, function($a, $b) { if($a == $b) { return 0; } return pow($a, 2) > pow($b, 2) ? -1 : 1; }); // now sorted
$result = array_reduce($unsorted, fn($a, $b) => $a * $b);

Credits

As you can javascript example looks way cleaner and is easier to read. The PHP code seems way harder to understand.

Another major issue with PHP is the inconsistency between errors and exceptions. Errors stem from the time when PHP only supported procedural programming, while exceptions were introduced with object-oriented programming (OOP). Since PHP is a blend of both paradigms, some functions throw exceptions while others return errors.

For example, the json_decode function accepts a flag that determines whether it should throw an exception or return an error. Some standard library functions, like file_get_contents, return an error. If the operation fails, it returns false; if successful, it returns the file contents as a string. You then can retrieve the error using error_get_last. In contrast, other functions, such as SplFileObject::__construct, throw exceptions when an error occurs.

Another reason the language is often disliked is the lack of high-quality, open-source projects written in PHP. While WordPress is popular, its codebase is often criticized for being messy, as the project is in a transition phase between procedural and object-oriented programming. Although it is improving, its current state remains problematic.

Is it better today?

Projects like TYPO3 have evolved over the years to adopt a more modern approach to PHP. They began using a package manager and object-oriented programming (OOP) to clean up their codebase. As a result, developing extensions for TYPO3 is now much more enjoyable compared to WordPress plugin development.

Over the past few years, many new features have been added to the language. PHP 8.1 introduced enums, and since PHP 7, we also have scalar type declarations. The language is now much more secure than in its early days. However, the bloat of configuration options still exists, as does the inconsistency between errors and exceptions. That said, the inconsistency is gradually being reduced. While the syntax remains largely the same, I personally don’t find it as problematic as others claim. In fact, it can be quite readable and clean. But of course, this is a matter of personal opinion. Many people might feel the same way about the syntax of languages like Rust, Go, or Java.

The package manager Composer now offers a wide range of useful packages. Additionally, there are numerous tools available to enhance your coding experience. These tools provide supportive features and almost every capability commonly found in other languages. Want unit testing? Use PHPUnit. Need code formatting? Try CS-Fixer. Looking for extra type safety and static analysis? Check out PHPStan.

Ecosystem

In addition to all the great tools, it’s the ecosystem that makes me really enjoy PHP. Frameworks like Symfony and Laravel are well-integrated and a pleasure to use. You can accomplish almost anything you want with them, as long as it involves web development. These frameworks even support building internal CLI applications within web applications. Furthermore, they allow integration with frontend frameworks like React or Vue. Symfony UX is another approach that makes web development with PHP more modern and enjoyable. There are so many different ways you can utilize these frameworks.

I have been working professionally in the Symfony environment for about three years, and from my perspective, I can definitely say that I’ve never encountered a scenario where the framework itself or a third-party library couldn’t get the job done. These frameworks help you complete tasks efficiently and effectively. Of course, other frameworks in different languages offer similar functionality, but in my opinion, Symfony stands out for doing many things in exactly the right way.

Conclusion

Overall, you could say that PHP was a pretty bad language in its early days, and even into the 2010s. However, today PHP is a solid choice for web projects. The language has gained many modern features and continues to evolve, becoming even better. With Composer as your package manager and a well-integrated ecosystem of tools and frameworks, PHP is definitely a great choice for modern web development. It’s no longer relevant to hate PHP.

I would recommend you to just give it a shot and try it out yourself. You will love it.

I believe many people feel the same way. They want to explore something they’ve never worked with before. This is the essence of lifelong learning, especially in software engineering. In this field, you’re always learning new things, and that’s one of the reasons I love it so much.

Sideprojects for learning?

Well, you know, I’m more of a practical person. When I want to learn something new, I can’t just go through examples or walk through all the playgrounds the language or framework might offer. The approach that works best for me is to actually build a project with the framework or language. I’ve spoken to many people, and most of them agree with this. Learning in a practical way through a project is much more enjoyable, and you can see your actual progress.

I have a fairly long list of side project ideas I want to develop someday. For learning Laravel, I simply picked one of those ideas. In this case, it was a simple web application where my friends and I could create fun bets and place our wagers on them. Pretty simple, not overly complex. I also added some additional requirements to explore the capabilities of the framework and see how easy and pleasant it is to develop with. Examples include localization and notifications within the web app.

In my opinion, this is a great deal. You’re working on some of your side project ideas while simultaneously learning something new. It seems like a win-win. Well, it’s not always that easy…

The learning curve

When you’re learning something new, there are often patterns or best practices you haven’t encountered yet. You might have discovered them if you had first read the documentation. But let’s be honest: While most people do read the docs, they might forget certain things when they’re actually developing. You can’t know everything right away. Knowledge comes from experience and repetition. It comes from failing and spending hours debugging a simple problem, rather than solely preparing by reading the documentation.

However, as you learn the framework or language, you get better at it. After a few hours or days, you start to pick up the basic patterns. In the case of Laravel, for example, you learn how the ORM works and how to handle database connections. You learn how to implement controllers and use Blade. You also discover best practices for organizing the file structure of your components.

How easily you can learn something new often depends on what you’ve already learned. It might seem a bit confusing, but let me explain what I mean: Imagine someone who has spent their entire career working in the object-oriented programming (OOP) world of Java. This person knows everything about object-oriented programming, and these concepts are deeply ingrained in their mind. Now, imagine this person learning React. While they might be comfortable with class components, they could struggle with things like hooks, functional components, and other non-OOP concepts. On the other hand, this person might find Angular easier to learn because its patterns are more similar to Java’s.

Refactoring hell

After you’ve learned a lot about this new technology, you might look at your project and think, “How did I build this?” And honestly, that’s completely normal. When you started this project, you had no idea how things worked. You might have used a file structure that isn’t considered best practice, or perhaps you put logic that belongs in a repository directly inside your controller.

At this point, you have two options: leave it as it is or start refactoring everything. Depending on the size of your project, this could take a significant amount of time. You might be thinking it would have been better to read the documentation from the start, but I actually don’t agree with that. Think about what would have happened if you had just read the documentation: Sure, you might have followed some best practices, but you wouldn’t have learned nearly as much.

When I think about my experience with Laravel, I remember long debugging sessions where I tried to figure out how things worked. I dug deep into the framework’s internals to understand how it operates under the hood, rather than just learning the basics needed to get the job done. Sure, the first approach would have been easier, but because I took the time to understand the framework better, I now know how to solve problems when they arise. So, even if you now find yourself needing to refactor your entire side project, you’ve gained some serious skills. Sure, choosing the quickest way to get things done isn’t inherently bad, but in the long run, the more challenging approach might actually help you work more efficiently.

Of course, you might not have approached the problem the best way when you tried to fix it on your own. There could have been an abstraction in the language or framework that would have made things easier. You could have used it right away, but now you have a deeper understanding of your technology and how it works. That’s still a win.

Your sideproject is no system critical infrastructure

But the question still remains: Should you refactor your entire codebase or not? I would say it depends. It’s a pretty personal decision. Personally, I would always try to refactor it. If the result isn’t worth the effort, you can limit your refactoring to the basics. But what you should keep in mind is that your side project is not critical infrastructure.

Let’s be honest—most of us start a side project without much planning. We get an idea and start coding right away. There’s no use-case analysis, no UML class diagrams. Maybe some component designs, but even that’s rare for side projects (at least for me). The main purpose of side projects is to have fun. We’re not building the backend of a billion-dollar enterprise here. These projects are not meant to be that formal. Side projects should give developers the freedom to do whatever they want, without any restrictions on component design or even best practices. The goal is fun and learning.

So please, stop overengineering your side projects. If you’re realistic, the primary users of such a project will likely be you and your friends. There’s no need to consider a microservice architecture just to scale to a million users at once. But if you enjoy thinking about those problems, feel free to dive into them.

But should I read the docs?

Earlier in this article, I mentioned that you shouldn’t read the documentation. That’s not entirely accurate. Of course, you should definitely read the docs to gain a basic understanding of how everything works. What I meant was that you don’t need to read the entire documentation in detail before starting your project.

Over the years, I’ve developed a personal approach to using documentation for new projects. First, I think about what I’ll need initially. In the case of my side project, it was routing, basic REST APIs, and database interaction. So, I sat down and skimmed through the docs to get an idea of how things work. Then, I started working on my project. When I run into a problem, I first try to solve it on my own. Through this process, I learn how the framework works. For example, if I need to retrieve a search query parameter from the HTTP request URI, I don’t immediately look up the documentation. Instead, I check out the Request object that’s passed to my controller and explore its API to see if it provides a solution. This way, I not only learn how to retrieve a search parameter from the URI, but also how the API works in general, which prepares me for future problems.

This might seem like the harder and more time-consuming approach at first, but it will pay off in the long run. There’s always the shortcut of reading the documentation, browsing Stack Overflow, or nowadays using ChatGPT or another chatbot to solve your problems. But throughout your career, you’ll also work with technologies that are less well-known or not as thoroughly documented. In those cases, you’ll need to understand how the framework or language works internally to solve problems effectively.

Let me give you an example: In my professional career, I’ve been working a lot with the PHP framework Symfony. It’s well-documented and relatively easy to start with, but it also has a steep learning curve because it simplifies many things. However, like any other framework, it can become quite complex. In one project, I had to work with a library that instantiated an admin dashboard. I wanted to override some form submission behavior, but the problem was that the Symfony docs didn’t cover this scenario, because the admin dashboard library added an extra abstraction layer on top of the Symfony API. Stack Overflow wasn’t much help either, since this wasn’t a common use case for overriding form submission behavior. To solve the problem, I had to understand how the Symfony API worked internally in order to hook into the form submission process and make the required changes. Without learning Symfony the hard way, I would never have been able to do that.

Conslusion

So, what can you learn from all this? The main focus of side projects is to have fun. You shouldn’t restrict yourself with unnecessary limitations. They’re perfect for learning something new because they aren’t major commitments, giving you more room to experiment, make mistakes, and learn from them. And yes, your code might end up looking pretty bad, and you’ll probably need to refactor it. But take a look at your first projects with the technology you’re currently most proficient in—weren’t they pretty bad, too? You always improve. And if you want to, you can refactor your project later with the experience and expertise you’ve gained so far.

The second takeaway is that you should definitely read the docs. But you should also challenge yourself. Don’t make it too easy. If learning a new technology feels easy, you probably haven’t learned much. Sure, things might be similar, but if there’s no difference, they’re essentially the same. So, try solving a problem without immediately checking the docs or asking a chatbot. Instead, figure out how things work and how you can use them. This approach leads to more expertise than just reading the docs because you’ll truly understand the technology, how it works, and how to use it. You won’t just know about it—you’ll have hands-on experience.

So, never stop learning and never stop challenging yourself, because doing so would mean you’re not learning anything. Failing makes you a better programmer than just reading about it.

Finally, a motivational quote for you:

Just let them know that we have a finite amount of time on this planet and you can be viciously mediocre or you can get the fuck after it. ~ idk who said that