Building a $5K ARR Side Project While Managing 9 Engineers

Today's guest article is the 2nd one in the ‘EM-builder series’!

You’ll read about how Taylor scaled Delly to 30+ paying customers and $5,000 ARR - all while managing 9 engineers as an EM at CoverMyMeds.

There are 2 things I really loved about this story:

• The pain Taylor wanted to solve is something every manager will relate to

• He got to actual paying customers, and continues to scale while still working full-time!

---

Thanks Unblocked for sponsoring today’s article!

One of the hardest things about our job as EMs is that we are very often the “unblockers.”

Despite best efforts, documentation is usually scattered or outdated – so our teams come to us for answers. But the more they do that, the harder it gets for us to take real focus time.

Unblocked solves this problem by helping every engineer be more self-sufficient. It connects to tools like Slack, GitHub, Confluence and Jira, and uses all the scattered knowledge in those tools to provide accurate (99%+ satisfaction rate!) answers about your application. Teams that use Unblocked report saving 1–2 hours a day per engineer to focus on solving problems instead of searching for context:

---

🎤 to Taylor:

Solving every manager’s pain

In my role as an EM, I manage multiple people - all of them called ‘software engineers’. In reality though, they quite often have very different responsibilities:

• One person might be leading retros and ‘softer’ tasks.

• Another one may be heads-down shipping great code.

• A third one spends big chunks of time mentoring junior engineers or helping other teams.

All of them might be great at what they do, but there weren’t a lot of tools to help visualize those different responsibilities.

I had a friend going through something similar and he said, “There’s got to be a better way to show this.” So I thought, why not build something to solve this? Back then, I was expected to do any coding in my EM role, and I thought it would also be a great opportunity to scratch that itch, while also solving a real problem.

We weren’t sure where it would go. Maybe it would become a company, or maybe just a side project we used ourselves.

I got excited about the idea, and did what every engineer does - went straight to building :)

Building the MVP - the tech stack & finding the time

The goal for the MVP was to build a tool that helps you visualize your role through the responsibilities you own, and then nicely show it across a team.

My wife was in law school, so I had a bit more space in life back then. When she needed to study, we’d go to the library, and I’d just build. It took me 18 months to finish the MVP, averaging around 10-20 hours a week.

Right now, with Cursor or Claude Code, it would have taken me WAY less time, but I wasn’t in a rush, and it was also a great learning opportunity for me.

I sucked at DevOps, so to set something from scratch to production I had to learn many new pieces (which by the way I believe were crucial for growing my career and being able to make good decisions and help lead my team in my day job).

It was also the first time I got the chance to start a project completely from scratch, choosing the languages and frameworks myself. I tried to strike a balance between putting something up (relatively) quickly, and also learning some new tools.

At first, I chose Python for the backend, but I quickly realized it was the wrong choice, as I had never coded in Python before, so I switched to the familiar Ruby. On the frontend side, I did make the choice to learn a new framework - I’ve been curious about Svelte and SvelteKit for a while, so I gave it a try. It ended up being pretty intuitive.

In the first version of Delly, once you mapped the responsibilities, you had the ‘check-ins’ feature. We would prompt you on a weekly basis, to tell us where your time went.

Here we made the right decision, to not automate anything yet - but depend on manual entries. We knew we would be able to pull in info from integrations, but wanted to see if the basic version was useful first.

Those manual check-ins weren’t perfect, but they gave you a basic breakdown of the percentage of where each person’s time went. And then over time, you can track that and understand where people's time is actually going.

So after 18 months of building and using it ourselves, we decided to find out if it's something people will actually use.

Getting the first customers!

And they did!

I worked at a startup that had grown big, and I didn’t want any IP issues. So instead of onboarding my company, we started with my friend’s church.

By the time the church onboarded, we had already pinged our network and found a second customer that was willing to try it out - a financial advisor company.

To be honest, I think they were willing to give it a try less from the ugly demo that we gave them, and more from their relationship with us. They trusted us, and we still have them as customers, and they’re continuing to expand their usage!

From there, we went on two routes:

• We continued selling to companies. Nonprofits, churches, and less ‘classic’ organizations loved our product, because in such places the people are spread very thin across tons of different responsibilities.

• We also sold subscriptions to individuals - especially summer interns. Using Delly was a good way to show where you're spending your time on your summer internships and highlight some of the things you did.

So right now we have around 15 summer interns, and also around 15 companies (some with multiple teams).

One thing I noticed after we started working with real customers is that time was easier to find.

We worked with a couple of nonprofits (helping families with young kids with free babysitting and some other things), and when they had a problem and I could fix it, I’d go quite long to solve it. Having a stronger sense of why just made it so much easier, and time kind of floated away.

What’s next?

We're currently at ~$5,000 ARR.

Through the research we’ve done and what we’ve looked into, I really believe role clarity is a powerful way to enable teams.

Some people think ambiguity pushes employees to do more because they’re unsure of what’s expected. But the more I’ve studied and seen across teams, the firmer my belief: to help people operate at higher levels, responsibilities need to be clear.

Our next step is to figure out who we can help the most and where we should focus.

A tricky part is that we already have paying customers who have been with us for a while, and we want to continue making them happy. As we use Delly for ourselves (and already have many integrations), I know that most of my time is spent on ad-hoc existing customers' requests.

I'm now trying to change it more to sales and marketing and doing some of that stuff because we need to really hone in on that as we've got a decent product and some satisfied customers.

The unexpected side-effect

I’ve always enjoyed both the tech side and people side of my roles, but since starting Delly, I realized I enjoy the business side too.

When all these customer requests come in alongside long-term features we want to build, it’s my job to think and prioritize: out of a million things we could do, what should we do?

The more I’ve seen, the best engineering leaders are those who deeply understand their product, and the best product leaders are those who truly understand engineering. If you can cross those lines, you empathize with the other side and become a stronger leader.

5 months ago, an opportunity opened at CoverMyMeds. They needed someone with both product perspective and technical depth - someone who could ask: how do we scale well, help engineers ship more, and keep systems stable during peak seasons?

So between dabbling with that at Delly and wanting to grow my career and skills in a new space, it felt like the right next step.

So I decided to give it a go and try the PM role for a while.

Why I recommend a side-project to every EM

I never felt like I was a stellar engineer. As I started working Delly, I learned so much on the way. Especially since having LLMs to ask questions and to learn from.

When you're in a big company, you are a small piece of the puzzle, and you rarely see the full puzzle. I feel like I learned more about software engineering from working on Delly because I had to build something from the ground up just by myself.

And this, in turn, helped me to lead better.

If you haven't done coding for a while, you're probably going to be bad at it. Yes, even with the help of LLMs. You’ll have annoying bugs and embarrassing mistakes.

It is worth it. Allow yourself to fall on your face and look a little bit dumb.

Spending a year and a half trying to get an MVP up is way too long for what it should have taken, but it was worth it to me, there was a lot of growth during that time.

And just like sharpening your product skills makes you a stronger engineering leader (and vice versa), I believe keeping up your engineering skills also makes you a better people leader. It helps you empathize with what your team is going through and see what challenges lie ahead.

Discover weekly

1. The 13 viral marketing laws 🏛️ by

   Tom Orbach
   .
   Marketing Ideas
   should be your first subscription if you want to get some revenue from your side project :)

2. You Know What To Do by

   Stay SaaSy
   , about how we often know what we need to do - and just need to do the hard thing.

3. Managing engineers more experienced than you by

   Suresh Choudhary
   . Three mistakes new Engineering Managers make while managing highly experienced engineers.