When to use Backend Architecture Design

Understanding

If everyone truly understood each other and no one had ill intentions, we wouldn’t need laws, governments, or all the "civilization boilerplate." Until Elon’s Neuralink becomes a reality, we’ll need to focus on fostering understanding.

When a project is new, it feels like a "greenfield," much like the Windows XP wallpaper—green, peaceful, and open. In this phase, you can try new things, make mistakes, and learn valuable lessons, whether they’re good or bad.

Greenfield: A project that is new and free from any constraints imposed by prior work.

However, what might seem like a greenfield to you as a newcomer isn’t always the case. If the project isn’t new, take a step back, relax, and try to understand the context. The more you learn, the less "green" the field becomes. You’ll start noticing mines and technical debt scattered across the field.

When I look at the XP wallpaper, I see green grass, a blue sky, and no problems. But realistically, that field probably has snakes, bugs, turds, and most importantly, mosquitoes. The more you walk through the field, the more you discover. Understanding the landscape makes navigation easier. Maybe that field has no snakes but is swarming with hornets. You won’t know until you research and grasp the context.

If you take a "move fast and break things" approach with an existing project, you will break things—but you may not move forward at all.

You don't have to fix everything or architecture everything at large scale. Sometimes, all you need is to optimize smaller pieces of the working system. Its hard to design a solution for everything, its also hard to have 10 really close friends. You need to pick your battles, and you need to focus on things you can work on, improve, implement and deliver. We all want to be superheros, and I believe its good to have that mindset, but remember, Spiderman has been fithing with crime since the 60s, and he still hasnt finished it.

Another aspect to remember is, your solution might make so much sense, but whoever controlls the money will have the final say. You and your engineers agreed that thats the best way to go, but the business might not agree. You will need to sell that idea too. Technical people understand technical problems. Business people don't, all they see is money, profits and revenue.

Factoring

A project needs the following and it differs from project to project. One solution you used in another project, might not work in this one.

• Functionality
• Performance
• Scalability
• Security

Key questions to ask when factoring a project are:

What are you trying to solve? Who are you solving this problem for? Who benefits from it? What is the problem you are solving? Why are you trying to solve this problem?

On a personal project, you may not need to answer all of these questions, but in business. Its better if you do. Because every decision you make, cost money in terms of time and have an impect somewhere.

Here’s the revised version with your preferred style:

Expertise

The best tech stack isn't the one that's technically the best, but the one your team can use the most efficiently. I see people on X talking about Rust, Zig, and Gleam and what those tools can do. I haven't met a single person who has heard of Gleam, and I haven't met anyone who has used Zig. Rust is getting popular, so people have heard of it, but I haven't met a single person who really knows how to use it.

Sometimes this approach creates problems. Here's a story from my personal experience.

MAUI from Microsoft is a poorly implemented mobile framework. People who write C# say it's awesome and can do everything they need. The problem is that people who write C# usually create CRUD apps and nothing more. So, their understanding of "everything" is a very limited "everything."

Because of this, I see many .NET teams trying to use MAUI for their needs.

If we're being honest, MAUI is useless compared to React Native, Swift, Kotlin, and even Flutter. It's just not there and probably never will be. Microsoft has a habit of creating solutions for everything, then dropping support and leaving you with a half-finished product.

You need to understand your team's skill set, that's true, but you also need to understand the alternative tools available. If your business needs a mobile app and all your developers are C# developers, maybe you should outsource the application, hire new developers, or just drop the project. Going with MAUI will cause more problems than it solves.
Here's the revised version:

Budget

What resources are needed? How much time is required to finish the task? An estimate is fine. How many developers do you have, and how many more do you need? If your developer team is already busy and you give them another task, here's what will happen: the quality of ongoing projects will drop, the new project won't have a great start, and talented developers will leave.

Now, you need to hire more developers, but onboarding a new developer takes at least 2–3 months. This doesn't even include the time it takes to hire someone. A plan to quickly cut costs and save time will end up costing you more time and money.

Here's the thing—if your developer is talented, they’ll find another job. Most engineers are smart and can do basic math. They usually have their personal budgets calculated. Well-paid developers aren’t afraid to leave. Do you really think a supermodel will cry if you break up with her? No, she’ll find another guy, probably with more money.

Your plan has backfired, and now you’re left with a broken heart and a broken project.

Engineers are your resouces, and most have money and can leave you. You need to keep them happy, and you need to keep them motivated. If you don't, they'll leave.

What about using open-source software to cut costs? Depends.

Open-source or not, you have to maintain it if the stakes are high. If you build your business around that open-source solution because it's free, guess who has the highest skin in the game? You. You will maintain it. So, its not free.

Time

Time isn’t free because salaried people are working on the project. If you have one month to deliver, don’t spend three weeks prototyping and experimenting, because you won’t meet the deadline. Time constraints must be taken into account; otherwise, you’ll miss the timeframe, fail to deliver on time, and likely go over budget due to ongoing salaries.

Project Size and Complexity

Docker and Kubernetes are powerful tools with many benefits. However, for a small project, not using Kubernetes might offer even greater advantages. There’s always a trade-off. Serverless architectures, Lambda functions, and cloud computing are impressive solutions, but they exist because there was a specific need for them. That doesn’t mean they’re the right choice for every project.

Large and complex projects benefit from advanced system designs, while small projects often thrive with simpler designs. Understanding the project’s size and complexity is critical to selecting the right tools and avoiding unnecessary overhead. Because, someone has to maintain it. Sometimes its best to avoid all the fancy tooling and going with the "Boomer" tech. Old, boring and been around for decades. Its simply the defination of the "Lindy effect".

Here's the refined version of your content:

User Feedback

We added all those cool features and followed last year’s popular guide on improving UI and UX. Too bad our customers are older and don’t know what a hamburger menu is. Clearly, it’s their fault for being outdated, right?

Early in my career, I faced a similar situation. I was building a system for lawyers, most of whom were 40–60 years old at the time. The only apps they used regularly were Facebook and games like Candy Crush.

The system was meant to help them track task progress and client statuses. Standard lawyer stuff. For me, it was exciting because it was my first real project.

I researched and implemented cutting-edge UI and UX trends, feeling proud of how modern and sleek it looked. Then, the lawyers started using the system.
“Where’s the menu?”
“What does this arrow do?”
“I’m lost!”

Turns out, tech influencers and 50-year-old lawyers don’t share the same design preferences. I had to strip out the trendy elements, replacing the hamburger icon with the word Menu and swapping icons for plain text. Increased the font, and made the buttons bigger. Headings didn't follow any rules. 62 years old laywer said, this needs to be bigger. Okay, do you want me to make other headers bigger too? No, just this one. There goes your design consistency. Oh also, make it red and bold. All of them? No, just this one. Well... this isn't going to my portfolio for sure...

We focus on UI/UX for a few reasons: to impress stakeholders, create portfolio-worthy work, and improve user experience. But the problem is, we often prioritize these reasons in that order.

1. Impress stakeholders.
2. Add to our portfolio.
3. Improve the user experience.

This order is backward. We should:

1. Improve the user experience.
2. Ensure stakeholders are happy.
3. Use the project as a case study for our portfolio.

Why? Because customers are the ones who use the system. Happy customers lead to recurring business, and stakeholders need that to keep paying the bills.

If your UI doesn’t win design awards, make it a case study. Write a blog about why you prioritized usability over aesthetics. Now, you have:

1. A system customers love to use.
2. Stakeholders who appreciate your approach.
3. A case study showcasing how you solved real-world problems.

Isn’t that a better outcome?

When browsing apps, watching reels, TikTok, and so on, what happens if a video doesn’t load in 3–4 seconds? You skip to the next one. Maybe that video was the most important one you’d ever see, but you didn’t waiy, you just moved on.

The attention span of people today is no more than 5–6 seconds, and it’s getting shorter.

Six or seven years ago, if something took too long to load, a spinning loader was the go-to solution. It reassured users that something was happening. A few years later, we replaced spinners with loading skeletons placeholders that mimic the structure of the content. Skeletons made users feel like the app had the data and was just putting it in place. It was a small psychological win. Got us another few seconds of attention.

Now, we use partial loading. We load whatever we can immediately, display loading animations for the rest, and keep cycling through. Even if a user’s attention span is as short as a dog with 10 tennis balls, we can still hold their attention by serving chunks of data as quickly as possible.

Trends evolve, and so do customer needs. Depending on your industry and audience, you may need to keep up with these changes or become the pioneer of the ecosystem. For lawyers, you don't.