I can’t stop the urge of trying new ideas. I often have new ideas for projects, and at some point it gets overwhelming when trying to maintain 6 projects on my own. Examples of forgotten projects that I could no longer maintain include MusicMan, a Rust implementation of a music player controllable using Vim keybindings, and GoGo, Go (the game) programmed in Go (the language). Sometimes even projects I started with friends get forgotten, like Budgeteer, a budget-sharing mobile app for roommates to track common expenses.

This post will compare my experience working on projects alone versus with friends. I’ll mostly draw a comparison between DsEasy, which was a personal effort, and Entervio, which has been a team effort with my co-founder Jamal.

Why I Started Collaborating #

Having friends help me with projects really motivates me to contribute more, and it generally keeps the project alive. When you’re maintaining multiple projects solo, it’s easy to let them fade into the background when life gets busy or when you hit a difficult technical challenge. Collaboration creates accountability and momentum that’s hard to replicate when working alone.

The Benefits of Going Solo: Speed #

Being the only developer on a project surely has its benefits. It’s probably the fastest way to code. There are no arguments about how to implement stuff. You can push everything directly to master and move along. You can iterate very fast with no fear of breaking anything, and even if you break stuff, you don’t have to worry about blocking anyone else’s progress since you’re the only one on the project.

This approach has often allowed me to move quickly on certain projects, shipping features and experimenting with new ideas at a rapid pace.

The Drawbacks of Going Solo: Architecture Block #

Now, while you don’t have to argue with anyone about architecture design decisions, many times you’ll find yourself arguing with yourself about two paths that both seem good. I’ve found that this has slowed down my progress significantly by staying blocked on one issue and not knowing how to advance.

A lot of times I wish I had a colleague I could bounce ideas off of, someone who could help me argue for or against some of my ideas so that I would know more surely what the optimal path forward is. There have been times in DsEasy where I overengineered certain aspects of the app, and that has come back to bite me. Now I find myself having to refactor them with absolutely zero motivation to do so and no one in the project to help me with the new refactor or redesign.

The Benefits of Collaboration: Going Far #

Sustained Motivation #

With me not being alone on the project and having Jamal consistently contributing, that has allowed me to not easily lose motivation or purpose. It has certainly kept the Entervio project alive for a long time. Seeing my colleague’s commits and pull requests motivates me to pick up priority tickets and implement them, and we’ve kept the features rolling.

The Creativity Loop #

By having a person to bounce ideas off of, and him also bouncing ideas off of me, we always find new features or optimization ideas after finishing any leftover tickets. We begin creating new tickets and making new PRs. The ability to talk and discuss ideas with someone has created a creativity loop that has really helped us in the long term.

Ensuring Code Quality #

Having someone else in the project also motivates me to keep the project clean and maintain the best code quality. While that sadly means no more direct pushes to master for me, it means both of us get to care about the quality of the code and review each other’s PRs.

I hope this practice will help us later on in the corporate world, since we’ll have to review PRs in our respective jobs. Having this practice with each other will certainly help us not miss bugs or code smells in the future. It also motivated me to install all the tools that help us keep the code clean: linters, formatters, and the like.

While I still can’t find the motivation to write tests for our entire codebase, I’m hoping later on in the project I’ll finally find the time to make sure everything (or at least anything important) is tested and integrated into our CI/CD pipeline. (By the way, if you know any articles on how to properly test functions that contain LLM output, I would really appreciate it if you send them my way, especially when the LLM has to output JSON.)

The Drawbacks of Collaboration #

Honestly, the only complaint I have is that sometimes it takes time until we’re on the same page about a certain implementation or feature. This really drives home the idiom “alone you go fast, but together you go far,” I guess.

Other than that, I have nothing to complain about.

Getting the Best of Both Worlds #

With Entervio, we tried to combine the advantages of both approaches. We made a deliberate decision to delay all code quality improvements until later and focused on iterating as fast as possible. This allowed us to speedrun a working product that we were actually proud of. We weren’t bogged down by debates about the perfect project structure or arguing over which linter rules to enable. We just built.

Once we had something functional and valuable, we went back and ensured everything was up to standard. We added all the guardrails to prevent us from making silly mistakes: git hooks, linters, formatters, and (for the love of god) ditching a silly requirements.txt for an actual pyproject.toml managed by uv. We set up proper pre-commit hooks with Ruff to catch issues before they even made it into a commit.

This approach gave us the best of both worlds. We had the initial speed of a solo project where we could move fast and break things, but now we have an actual project that is clean and feels more serious than just another silly personal project. It’s something we can maintain, extend, and be proud to show to others.

Conclusion #

Both approaches have their place in software development. Solo work is perfect for rapid prototyping and exploration, while collaborative development shines when you need sustained motivation, better architecture decisions, and higher code quality. For a serious project like Entervio that we want to maintain and grow over time, collaboration has proven to be invaluable.

The key is knowing which approach fits your current needs and being honest about the trade-offs you’re making either way. And if you’re lucky enough to have a great collaborator, you might just find a way to get the best of both worlds.