How an EM’s Side Project Reached 1,800 GitHub Stars

The next four articles are going to be a bit different - a series of guest posts by Engineering Managers who built side projects while working full-time.

I believe that’s much harder than doing it as an engineer. We have less time, more responsibility, and our work isn’t always hands-on.

Each story is different, but I hope you’ll find something useful in all of them.

We’re kicking off with Piotr, who built a popular open-source project in a single weekend. A year later, he was laid off and decided to go all-in on building.

Here’s what we’ll cover:

• Getting 1,800 GitHub stars during a full-time EM job

• Getting laid off

• Going all-in on building

• How can you start in just a few hours

Mic to Piotr! 🎤

Getting 1800 GitHub stars during a full time EM job

In my last 2 Engineering Management jobs, I wasn’t expected to write any code. I didn’t want to mess with the company codebase and be a blocker, but I still had the urge code, so I decided to build something on the side instead.

The idea came from my own very real pain: you’re developing locally, and your terminal logs are a mess, super hard to search through and use during debugging. So I thought - why not build a simple web UI for that?

So at the beginning of 2024, I put together a basic version in a couple of days and called it Logdy. I posted it on Hacker News without a lot of expectations, but it gained traction and got 400 stars in two days.

I started during a weekend, and the interest from the community gave me energy to keep going - adding features, responding to GitHub issues. The open-source version isn’t very big or complex, so adding features took me just an hour or two during some evenings.

Right now, Logdy has over 1,800 stars on GitHub and a small but active community - people open issues, ask questions, and request features. I get around 2,000 runs per day, based on simple telemetry the app sends (you can block it, of course). So there’s real usage.

In the first month or two, a VC firm even reached out. They invested in open-source DevTools and said, “Would you be open to working on this full-time?”

I didn’t have a pitch deck, nothing prepared. But we jumped on a call. They basically said, “If you’re serious, put something together and let’s see if we can invest.”

At the time, I wasn’t ready. I was still working full-time and didn’t know if I wanted to go all in. So I said, “Maybe in a few months.” But neither of us followed up.

If I knew I would be laid off, maybe I would have given a different answer 🙂

Getting laid off

In 2010, I started my career as a self-taught software engineer. After 5 years I moved to freelancing/consulting - building web apps, mobile apps, whatever the customer needed.

After another five years, I started missing long-term ownership. That’s when I joined Fonoa, a VC-backed startup in the tax tech space, as their first hire - a founding engineer. They brought me in for a project before the company was even officially established, and it quickly turned into a full-time opportunity.

Over the next four years, the company grew to 120 people and raised up to Series B. I grew with it - eventually moving into an engineering manager role.

After Fonoa, I joined Salesloft as an EM - a US-based company with a distributed team and a site here in Poland with about 50 engineers. But due to economic reasons, 7 months after I joined they decided to shut down the Polish office.

I had some runway I’ve built during the years, and my son was just born, so I decided to take a few months off to spend the summer with my family at home and build things.

And if after that time nothing clicks, then I'll start looking for another Engineering Manager’s job.

Going all-in on building

Even before I got laid off, I started working on a way to make money with Logdy.

At some point, a few people started asking for more advanced features. That’s when I started thinking that maybe there’s space here to monetize. We live in the cloud era, right? Logs are big, and cloud storage is expensive.

So I started working on a commercial version you can run on-prem. It compresses logs by 20-30x, and the cool part - you don’t even have to decompress them to view them.

I’m currently working with three companies that are testing it. The feedback so far is positive, and I think they’d be willing to pay. The value is easy to show - if I can help you cut storage costs or save your team time, that’s a pretty clear ROI.

Improving the hiring process project

In parallel to the commercial Logdy version, I started another project with 2 friends:

The idea came from my experience as a manager - hiring lots of engineers, running interviews, and realizing there’s a lot we could improve in the process. I teamed up with two guys here in Warsaw who saw the same problems, and we started working on a first version.

Initially, we focused on something not many people talk about - the hiring bar. I’d ask other managers: Do you know where your bar is? Can you measure it?

Everyone had a gut feeling, but no way to quantify it. And when interviewers aren’t aligned, your hiring bar drops - and so does team quality.

That idea made sense to some, but it’s a harder sell. Companies we’ve talked to pointed us to a more immediate pain: screening. They open a role, get 300 CVs, and spend hours filtering.

So we said - let's start there. Let AI handle the early vetting, help push candidates through the pipeline, and buy back time.

The vision is still broader, but we’ll get there step by step. We already have one company working with us on an MVP.

So how can YOU start in just a couple of hours?

I’ve seen managers who stopped coding for a couple of years and said, “There’s no way I can get back into it. Too much has changed.” And I get it - the landscape shifts fast.

I have 4 tips for you:

• Solve your own problem

• Start super small

• Use copilots

• Don’t be afraid of open source

Solving your own problem

I know it’s a cliche, but this makes starting so much easier. It doesn’t even have to be a unique project!

Here’s an example: one idea I had recently was a job board for engineering managers. There are tons of job postings for EMs and engineering leads, but they all follow the same boring template: responsibilities, stack, location. The usual stuff.

But you could use LLMs to reformat those into something useful - like a proper structure for EMs: What’s the team size? Is it a product-led company? What kind of engineering culture?

Maybe in a few months I’ll be looking for a new EM role myself, so it would actually be useful. A job board with just engineering management positions, curated and structured properly, with the right filters.

Similarly, it can be anything that will improve your life just a bit. An internal tool for your company, an app to track your baby’s meals. Anything works (again - doesn’t have to be original!)

Starting small

When I started, I had no kids. Now I can imagine that after eight hours, having a kid at home and family to take care of, you may not have the energy and time (and sanity) to spend your evenings coding.

That’s why my suggestion is to start super small. Try to find 4-5 hours on a weekend, when you can do some focused work and release something - anything to get that initial dopamine boost!

In the ‘job board’ example, it can be just a place where you can track your own job-searching process, suited exactly to your needs.

Doing something like that is possible in a couple of hours at most, especially if you use copilots:

Using copilots

When I started, copilots weren’t that great yet. If I were starting today I’d probably use Claude Code to generate the whole codebase.

Get yourself a $20 subscription and just start. Even something basic, like a TypeScript project. You’ll immediately see what these tools can do.

I tried it recently - I asked it to scaffold a TypeScript project, and it gave me a pretty solid setup. It even handled all the quirks around configuration. I asked it to make the type system stricter, and it knew exactly what to do. That’s when you start thinking, “Okay, this thing is actually capable.”

Don’t be afraid of open source

Building open source libraries is often associated with ‘hardcore’ engineers. Especially if you haven’t coded for a while, it might be scary to show your code to the world, open to comments and ridicule.

Logdy’s code works - but I wouldn’t say I’m proud of it. It’s not something I’d want to point at and say, “This is how I write code.” I just didn’t have time to overthink it, so I focused on getting things through the door quickly. Quality comes later.

The best part of building on the side: even if nothing comes of it, you still learn, and you have something real to show. And who knows - you might even end up saying in a future interview, “Yeah, I built the tool that helped me find this job.”

Discover weekly

1. Stop trying to change your manager by

   Wes Kao
   . Wes shows that even if you don’t think you are trying to change your manager - you probably do, so stop :)

2. Developers don’t need more documentation by Dennis Pilarinos.

   Docs get written, but answers stay hard to find. The problem isn’t the docs themselves. It’s that the context developers need is scattered, outdated, or missing entirely. Why does this keep happening, and what’s the alternative? (sponsored)

3. Make Mistakes Cheap, Not Rare by

   Michał Poczwardowski
   . Most of us grow up feeling that mistakes are deeply negative things we need to avoid - Michael challenges that.

4. Now, Together by

   Natasha Jaffe
   . When should you do things together with your employees. A really useful tool to have in your belt!