Launch HN: GitStart (YC S19) – Remote junior devs working on production PRs
Hi HN, I’m Hamza from GitStart (https://gitstart.com/). We’re building a service for engineering teams to assign tickets and get back PRs. Here’s a video of how it works: https://www.loom.com/share/61d46a5b07e04b45a51af2a5008ee173

We recruit devs who want to grow from remote countries, to work full-time on these tickets and review each other’s PRs. For tech teams it’s pay as you go, and they only pay if they merge the PRs (we pay our devs a base regardless).
GitStart is very personal to me because I struggled myself to start my career as a junior dev. Being born in Pakistan made it super hard to find my first remote job. Things changed with Google Summer of Code, which was the first time I got paid to contribute to a large production codebase.

When I became a staff engineer, I started mentoring junior devs on their solo projects. I then realized what they really needed was production code experience, so I started sending them tickets from my backlog to grow them through code reviews. I also paid them for it. They learned a lot and I got a lot done, which started GitStart.

That’s why, in the description above, we say “devs who want to grow”. This is key to what we do—we are not just a body shop or middleman, and we don’t charge by the hour. We provide useful mentorship to junior devs. We want to be a meaningful part of their career path.

Our thesis (to use that slightly pretentious word) is that the economics work better this way as well. There is a lot of junior dev talent in these countries whose potential will bever be realized by hourly piecework. What’s needed are longer term relationships and work engagements, over the course of which a junior dev can learn and grow on a large production codebase. Much of this has to do with learning the culture of effective tech teams.

On the other side, effective tech teams don’t want hourly piecework either. Clients tell us they love having developers dedicated to their project, becoming more familiar with the code over time. This is the way for value to be maximized on both sides.

A number of commercial open source repos already use us, so you can check out some of the PRs created by GitStart here:

Cal.com: https://github.com/calcom/cal.com/pulls?q=is%3Apr+author%3Ag...

SourceGraph: https://github.com/sourcegraph/sourcegraph/pulls?q=is%3Apr+a...

StoryBooks: https://github.com/storybookjs/storybook/pulls?q=is%3Apr+aut...

Strapi: https://github.com/strapi/strapi/pulls?q=is%3Aclosed+is%3Apr...

Supabase: https://github.com/supabase/supabase/pulls?q=is%3Apr+author%...

Twenty: https://github.com/twentyhq/twenty/pulls?q=is%3Apr+author%3A...

Our main technical challenge has been securing code sharing. One solution was building GitSlice, which enables creating sub-repos that sync with the upstream repo. When GitStart devs create PRs on the platform, GitSlice syncs them upstream while pulling back CI/CD checks and review comments. This enables our devs to contribute with limited codebase access.

To prevent slices from breaking, we verify they run within a docker container, which also enables us to build review environments. Fun fact: we managed to support native iOS and Android codebases by building and running them on appetize.io instead of docker.

There have been countless attempts at this space so we would love to hear your feedback on how we approached this problem or your past experiences working with junior devs in this way. We look forward to a good conversation!