Maintainability and scalability are the two holy beasts of software engineering. I really don't believe that even large code houses with armies of skilled and talented people have too much to show on this front. Also neither of them has a be all end all solution on that.

Maintainability means that you have a codebase with little to none tech debt where everyone can jump in and contribute. There are a few things that you might do to increase maintainability, like following a specific coding style and convention across the whole codebase, follow the SOLID principles, YAGNI, and other weird acronyms. Keep in mind, though, that these principles can easily lead down the path of a cargo cult. The best advice I can give for maintainability is to "Always write your code as if the next person who will work on it is a violent psychopath who knows where you live" 😁😁😁

As of scalability, things become even more unclear. We go around and say, "We will follow the X architecture because it is more scalable", then after a while we go like "Let's use the shiny new Y architecture it's more scalable". There are actually at least three dimensions you can scale an app, so there isn't a definitive answer. Again, the best thing you could do is to organise your code in components with a single responsibility or context, and keep them as loosely coupled as possible. But again these are too general guidelines and your approach should be dictated by the project at hand.

That's a really tough question
I don't think many projects can say with confidence "yeah I have figured that out".
And if they do that could be a symptom of the reverse.

Like they over-engineered an infinitely scalable Netflix-like micro-services zoo
... but their backend has currently 1 request per second.

There are practices you can and should put in place:

• don't merge pull requests without tests
• have CI/CD in place
• put some kind of alerting/monitoring/centralized logging
• define your architecture principles
• beware of a antipatterns like spaghetti code or lavaflow
• identify your performance bottlenecks

But you probably want to stay humble.
Your codebase being maintainable is more a constant struggle than a science.

1. Follow coding standards and conventions: Adhere to established coding standards and conventions for your programming language. This makes your code easier to read, understand, and maintain.

2. Write modular code: Break your code into smaller, reusable modules or functions. This allows you to manage complexity, isolate issues, and reuse components across your project.

3. Use version control: Use a version control system like Git to track changes, maintain a history of your code, and collaborate effectively with other developers.

4. Write unit tests: Create unit tests to validate the functionality of individual code components. Regular testing helps catch bugs early and ensures the stability of your codebase.

5. Use a consistent naming convention: Use clear and descriptive names for variables, functions, and classes. Consistent naming improves code readability and maintainability.

6. Enforce prohibition of writing code comments, the code should be self explanatory.

7. Refactor regularly: Periodically review your code to identify areas for improvement, remove duplication, and simplify complex logic. Refactoring helps keep your codebase clean and maintainable.

8. Optimize for performance: Analyze your code's performance and identify bottlenecks. Use efficient algorithms and data structures to improve scalability.

9. Utilize design patterns: Implement proven design patterns to solve common problems. Design patterns provide reusable solutions that can improve the structure and organization of your code.

10. Plan for future growth: Consider how your code will need to change as your project grows or requirements change. Design your code to be flexible and adaptable to reduce the effort needed for future updates.

When they ask questions like this, they want to hear keywords like: design patterns, loosely coupled, SOLID principles, etc. But honestly no company I ever worked for had achieved truly maintainable and scalable code... Its the holy grail of software engineering. At most what you can achieve is a basic understanding of the code base among all team members that will live on until the last team member with the knowledge is replaced.

I believe it's impossible to build totally maintainable code initially. First focus on your requirement writing the cleanest code you can as you go, but do not over engineer it before it's needed. Chance are either this requirement is never going to be revisited again and thus you have more complexity than useful or is going to be totally changed in unexpected way and the great architecture you built will be in the way of the new requirement.

Most of the time, keeping the code simple is the most maintainable solution.

The same goes with scalability, don't architecture for scalability before you need it, chance are the boundaries you'll create will be at the wrong place and again in your way.

Maintainability: My favorite trick for this is to architect everything with testability as the chief architectural goal. Not only does this help you to efficiently achieve great test coverage, which itself is good for maintainability (keeps you from breaking stuff), but I find that this approach naturally leads to modular and cohesive code.

Scalability: I wouldn't usually worry too much about mega-scalability up front because it might just be a waste of time. Many, many projects run just fine forever on a handful of machines all talking to one database instance. It's usually hard to know whether you'll need to go beyond that scale or not, and designing for it might be a waste of time due to the added complexity. If you're sure you'll need it, then by all means, design for that up-front. But it really does happen that sometimes people try to design for scalability that they never end up using, I've seen it.

One technique that I like, which preps you for needing to scale, but without introducing too much complexity, is building a modular monolith. What I mean is for example, have a "users" module, a "photos" module, a "posts" module, etc, and have those be separate in code and have them be able to talk to independent database instances. But then just deploy them all as one package and have them talk to the same database instance (but different logical databases inside of it). If that database instance gets too hot one day, and the posts module is mostly the culprit, then pull out the big guns and refactor it to use Scylla or something, and start deploying the code in separate containers. To be honest I haven't had to do that yet in my career, but I'm looking forward to the day!

Modest scalability is a different story. A modestly sized project can still be crippled by bad database indexing and query writing, ignoring time complexity, etc. I don't have any super specific tips about this, you just have to learn about the basic good performance practices of the technologies you're using.

I like to think that I get a little better at these things every day, but I still have a long way to go! These are very hard problems and as others have said in the comments, nobody has all the answers.

unit testing and never deliberate create tech debt. "We will refactor later" is the biggest lie ever.

For a platform to be truly scalable, it needs to be able to handle increases in the number of users, applications, data, and processes. Additionally, for professional developers assisting with low-code development, their goal is to write code that does not regularly need to be updated as things change.
regards: camping startup

Scalability and maintainability. Two words that result to an over engineered application. Make your code simple and concise. Do not think too much about the future.

Following SOLID principle might be a way to ease maintainability