I was 15, running a company, and learning that managing people is harder than any codebase
The first time I had to fire someone, I rehearsed the conversation for three days. They were a friend. They were also three weeks behind on every deadline. Nobody prepares you for that at fifteen.
How It Started
I was thirteen when I wrote my first line of PHP. I started freelancing almost immediately, and by the time I was fifteen I co-founded WEUPCODE. We were an outsourcing company - placing developers at client companies. At the same time, I was also outsourced as a contractor to an education software provider. The business model was straightforward: find talent, place them at clients, take a margin.
What I did not plan for was that "grow organically" would mean 25 employees and $300K in revenue within eighteen months. At fifteen, when my father registered the LLC in 2021, I was suddenly in a real business, managing a payroll system I barely understood, and having performance reviews with people twice my age.
I was terrified. And I had never been more alive.
The First Hire
Our first hire was Mateusz from Częstochowa - I met him through a common friend while doing another freelancing project. He was solid technically and became our go-to developer. The team grew fast from there. By month two, we had five people and the dynamic had shifted completely.
With two founders, decisions are conversations. With five people, they are meetings. With fifteen people, they are processes. I learned this the hard way when two developers spent a week building the same feature because nobody documented what was being worked on.
That was the week I learned about project management. Not from a book. From the look on Marek's face when he realized his entire week of work was redundant.
The Conversation I Did Not Want to Have
Three months in, I was dealing with my hardest people problem. Kuba was a friend from school. A genuinely nice guy - we would go to restaurants together, visit each other on weekends. The kind of friend you want to help succeed.
So I kept putting him on client projects. And every single time, the client was disappointed. Two months in, sometimes six months max, and they would ask us to replace him. I kept thinking the client was the problem. I would find him another project, convinced the next one would work out.
It never did. And here is my biggest mistake from that period: instead of being honest with Kuba and letting him go, I played the customer's advocate. I defended him to clients, made excuses, tried to make it work. Until the clients stopped trusting ME.
That is the lesson that still stings. Sometimes the kindest thing you can do for a friend - and for your business - is to be honest, even when it hurts. I lost customer trust that I never got back, because I chose friendship over professional honesty.
Scaling: The Parts Nobody Talks About
At five people, you know what everyone had for lunch. At ten, you need standups. At fifteen, you need sprint planning, documentation, and actual processes. At twenty, you realize you are spending 70% of your time managing and 30% building.
This was the hardest transition of my life. I became a programmer because I loved building things. Suddenly my job was making sure other people could build things effectively. I missed writing code the way you miss an old friend.
But the company needed a leader more than it needed another developer. And slowly, grudgingly, I got better at it.
The Money Conversation
$300K in annual revenue at eighteen sounds impressive at dinner parties. It is less impressive when you subtract salaries for 25 people, tool licenses, server costs, payment processing fees, taxes, and the accountant you hired because you have no idea how taxes work.
The margin was healthy - we were profitable from month eight. But "profitable" and "wealthy" are very different things. I learned more about cash flow management in those eighteen months than most people learn in an MBA program. Mostly because mistakes with cash flow have immediate, visible consequences. Like not being able to pay someone on the 10th because a client paid you on the 15th.
What It Taught Me About Engineering
Here is the irony: managing a company made me a dramatically better engineer. Not because I learned new frameworks or languages, but because I learned systems thinking at the human level.
How do you design a team that scales without becoming bureaucratic? How do you create processes that ensure quality without suffocating creativity? How do you give people autonomy while maintaining accountability?
These questions map directly to software architecture. Microservices vs. monolith is really a question about team autonomy. API contracts are really about communication between groups. Error handling is really about building systems that fail gracefully under pressure.
Every well-designed system reflects an understanding of human behavior. User behavior. Developer behavior. Organizational behavior. You cannot learn that from documentation alone.
Would I Do It Again?
Without hesitation. But I would do it differently. When I sit across the table from enterprise clients today, I understand both sides. I have been the developer building the feature and the person signing off on the budget.
The biggest thing I would change? Relationships. Back then, it was enough to just send some emails to get customers for outsourcing services. I kept the business going on transactions, not relationships. When the market tightened in 2023-2024, that stopped working. Transactional clients leave when times get tough. Relationships survive downturns.
That is ultimately why I had to close WEUPCODE. Not because the work was bad - because I never built the network that sustains a services business long-term. Relationships are the key, not just sending invoices.
That lesson is something you cannot certify. It is something you earn. And I earned it the hard way.
