GM @X I am Kolar I help businesses work smarter with backend systems and automation. I: • Design backend systems that scale smoothly • Automate repetitive tasks to save time • Build bots that handle daily operations • Simplify complex workflows Slide into my DM let's talk

Security is not about making your app impossible to hack. It's about reducing trust in the right places and limiting the damage when something goes wrong. That's what separates a feature that works from a system people can trust👀 After 14 days of this software security series, one pattern keeps appearing: Every security feature exists because developers chose not to trust something. We hash passwords because we don't trust databases to never be leaked. We use OTPs because we don't trust passwords alone. We implement authorization because we don't trust every authenticated user with every action. We validate input because we don't trust what users send. We rate limit because we don't trust every request to be genuine. Notice the pattern? Backend security is basically a series of questions: Should I trust this user? Should I trust this request? Should I trust this device? Should I trust this data? The safest answer is rarely "Yes." It's usually: "Verify first." And that's probably the biggest lesson I've learned about backend engineering: Good systems are not built on trust. They're built on verification. 🔐

Nigga restore my files🥹😂

Security isn't about making your app unhackable. It's about reducing trust.

This is the 999th time I'll be explaining to my mum what I really do to make money.

Most engineers who struggle with system design interviews aren’t bad engineers. They just started learning the wrong things, in the wrong order. Here’s the actual roadmap, what to learn first, what comes next, and what to save for later.

When you hear "Company X suffered a data breach." What do you imagine? A hacker typing at 500 words per minute… Green code flying across the screen… Then suddenly: "ACCESS GRANTED." 😭 Movies have made us believe that's how it happens. But in reality, a data breach is usually much more boring and much more dangerous. A data breach simply means: Someone accessed data they were never supposed to see. That's it. The scary part is how they got there. Sometimes it's because: - a leaked password - a forgotten API endpoint - a developer exposing credentials - a database left publicly accessible - excessive permissions - a successful phishing attack In many cases, there wasn't some magical hack. There was just one small mistake. And here's what surprises many people: The attack is often over long before anyone realizes. An attacker may quietly: - copy customer records - download emails - collect phone numbers - steal API keys Then leave. The app keeps running. Users keep logging in. The company doesn't notice until weeks or even months later👀 This is why security isn't only about preventing attacks. It's also about limiting damage. Good systems ask: - Does this user really need access to this data? - If one account is compromised, can it expose everything? - Can we detect unusual activity quickly? - Can we revoke access immediately? One backend lesson changed how I think about security: Assume something will eventually go wrong. Then design your system so that one mistake doesn't become a catastrophe. Because the difference between a small incident and a company-wide disaster is often not the attack itself. It's how much the attacker can access after getting in.

Software Engineering I build web and mobile applications that: - don't panic even when Nigeria happens to them😹. - keep users' money safe even when transactions don't go as planned. - handle poor networks without making users suffer. - expect failures, recover gracefully, and keep moving. - solve real problems instead of creating new ones.

When did Airtel ODU enter the debate?😂

You just need to know the fundamentals right?😁

When the request filters is too complex to be sent from query parameters, making URL too long. They just switched to POST so they can send it easily as a JSON payload in the request body. After all, the goal is to get a response.

Frameworks come and go. Programming languages evolve. But a well-designed database can serve an application for decades. Learn to design databases, and you'll stop thinking in tables. You'll start thinking in systems. Check out my article on system design. x.com/Kolar_Dev/status/20657…

AI can write code now. Your job now as a software engineer is to read the code and think in systems.

Crazy🫪 The second richest man doesn't even have half of the first

Up and feeling like building replacement of one big tech company. Which should I build?

Increase the volume 📢📢

Tech startups I think

It's now obvious that something is wrong with the Meta's technical team. Look at the poor system updating of WhatsApp desktop and mobile too.