Business Developer Is the New Black

AI First Backend-ers, AI First Frontend-ers, AI First Everything- but where are AI First business people? 🤷🏼

The current AI gold rush is booming — so hyped that many can’t see the bigger picture hiding underneath.
Everywhere you look, new AI trainings are popping up. LinkedIn feels like a Turkish bazaar where everyone is shouting about their new “Become an Nx Developer” course.

Of course, it's super important, don’t get me wrong, but here’s the thing: most developers are racing to master tools for problems they barely understand.
It’s like starting from the tail instead of aiming for the head.

Traditionally, choosing the right tech stack and creating the backlog were business decisions. Yet in the AI era, this responsibility is shifting - and landing squarely on the developers’ shoulders.

While everyone’s chasing shiny AI tools, the real revolution might be happening somewhere else and be something quieter: in the minds of developers who think like businesspeople.

So, what’s a Business Developer?
Glad you asked.

“Business Developer” is my term for the new generation of software creators - people who approach problems holistically, not just technically.

A Business Dev doesn’t just write code; they think in outcomes, because as a developer, you are not only writing some code. You’re creating a solution to a existing problem. You’re solving people’s pain, and by doing that — you’re making money = you’re doing business.

No matter the task, deadline, or tech constraints, their goal is simple: make the business better through smarter software and team decisions.
Over the last year, I’ve refined my own workflow into a set of principles that can help you adopt - or assess - the Business Developer mindset. Here’s what it looks like.

Step 1: Understand and Feel the Domain

How can you solve a problem you’ve never experienced?
How can you stay motivated to fix pain points you’ve never felt?

Take Glovo, for example - every new employee, regardless of position, spends time as a delivery courier. Genius, right? It forces engineers to feel the domain firsthand, long before they will even see the project from the kitchen.

As a new hire, you’re like a fresh sports car with a powerful engine, but you still need mileage to properly lube all parts to make it work smoothly and reliably.
That “mileage” is your domain experience.
This early period is priceless. Step into your users’ shoes. See what works, what doesn’t. Form your own opinions and compare them to the client’s view.
You’ll be surprised how many better ideas appear when you both see the problem from fresh angles.

Step 2: Understand and Challenge the Solution

This one’s controversial but powerful.

When a client explains their vision, don’t just nod.
- Ask obvious questions
- Challenge assumptions. Especially the most obvious ones and the hardest ones.

Some of the best breakthroughs in my career came not from pushing forward - but from taking a step back and rethinking literally everything.

Step 3: Keep a Developer Log

We all love our to-do lists, but the Developer Log goes deeper.
It’s your personal work journal - a living record of how your project and thinking evolve, and you can use any tool of your choice.

Here’s the framework:
1. Tasks: atomic, concrete, realistic.
2. Debt: tech debt noted but deferred.
3. Team Notes: issues or insights worth sharing.
4. Summaries: what happened in meetings or discussions.
5. Work Items: next concrete steps.

Once you get used to it, you’ll be shocked by how many patterns and opportunities emerge.

A good Dev Log, apart from the obvious benefits in the shape of better organization it gives you 2 important aspects that you are:
1. Aware of the bigger picture.
2. Able to predict potential business risks before they appear.

So let’s wrap it all up:

When you join a new project, remember:

First, map the domain like a complete newbie user.
Then, challenge the proposed solutions as many as you can!
Finally, keep your Dev Log running.

Because being a Business Developer isn’t about refactoring for refactoring’s sake.
It’s about improving lives - users’ and workers’ alike - while delivering quality results and generating profit.

That’s not a usual employee. That’s more like a business partner.
To me, that’s the developer of tomorrow 🚀

Read more about Developer Logs here.

Thank you very much for reading, hope you enjoyed it - feel free to leave your mark in the comments! 👋🏼