What Nobody Prepares You For When You Start Managing People

For most of CodeSpring's life it was just me. I'd describe what I wanted to an AI, it would write the code, and I'd ship it. No meetings, no process, no difficult conversations. Just me and a laptop.

That changed when we hired developers, and this week was the first time I really had to manage people properly. Not just assign work and hope for the best, but actually look at what was happening, figure out why things weren't moving, and have conversations about it.

The thing that made me act

I'd been noticing for a while that features were getting built but never actually reaching our customers. In software there's a whole process between "the code is written" and "users can actually use it," and things were getting stuck in the middle. Work would sit there for over a week, finished but not live.

When I actually dug into it, it was worse than I'd expected. We had fourteen things in various states of nearly-done, but customers couldn't use any of them. So I spent an evening reorganising everything. I paused seventeen things that weren't urgent, set up a proper system for handling customer requests separately from new development, put deadlines on everything that was in progress, and created a new rule: first thing every morning, get yesterday's finished work live before starting anything new.

Then I recorded two video messages explaining all of it to the team.

And then I immediately worried I'd been too harsh. I went back through everything I'd written and softened the language.

The part that's hard to talk about

Here's the thing about managing people when you've never done it before: every conversation feels loaded. When you ask someone why something is taking longer than expected, you're not just asking a question. You're navigating this whole landscape of "am I being reasonable or am I being that boss." And you never quite know.

I sent messages this week that I spent twenty minutes drafting, trying to get the tone right between "this needs to happen" and "I'm not blaming you." It's exhausting in a way that's completely different from the exhaustion of building something yourself.

The thing I keep coming back to is that what I found isn't a people problem. The team is good. They work hard. The issue was that we didn't have a clear process for getting things from "done" to "actually live." That's on me to set up, not on them to figure out.

What's actually happening with the business

The numbers are encouraging. We're spending about $1,250 a day on ads and bringing in more than that in revenue, which sounds like it should be relaxing but instead means you're watching the numbers every few hours because a bad day can wipe out a good week.

February was rough. About fifty thousand in revenue but only three thousand in actual profit after ad spend, because we'd been running ads to too many countries and the quality of people clicking through was terrible. At the start of March I cut seven countries that weren't generating any return and focused all the budget on what was already working. Early signs are positive but it's too soon to know for sure.

The bigger thing I'm learning

The hardest part of growing a company isn't building the product or figuring out the marketing. Those are hard, but they're the kind of hard where you can sit down and grind through it. The hard part is making the shift from doing everything yourself to creating systems that let other people do it. That requires a completely different set of skills, and you don't get to practice them gradually. One week you're a solo builder, the next week you're responsible for whether four other people can do their jobs effectively.

I'm figuring it out as I go, which is pretty much the story of everything I've done with CodeSpring so far.