15 ms·

Launch HN: GitStart (YC S19) – Remote junior devs working on production PRs

235 points by hzia 3y ago

Hi HN, I’m Hamza from GitStart (https://gitstart.com/ 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 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%3Agitstart-calcom+is%3Aclosed https://github.com/calcom/cal.com/pulls?q=is%3Apr+author%3Ag... SourceGraph: https://github.com/sourcegraph/sourcegraph/pulls?q=is%3Apr+author%3Agitstart-sourcegraph+is%3Aclosed https://github.com/sourcegraph/sourcegraph/pulls?q=is%3Apr+a... StoryBooks: https://github.com/storybookjs/storybook/pulls?q=is%3Apr+author%3Agitstart+is%3Aclosed https://github.com/storybookjs/storybook/pulls?q=is%3Apr+aut... Strapi: https://github.com/strapi/strapi/pulls?q=is%3Aclosed+is%3Apr+author%3Agitstart https://github.com/strapi/strapi/pulls?q=is%3Aclosed+is%3Apr... Supabase: https://github.com/supabase/supabase/pulls?q=is%3Apr+author%3Agitstart+is%3Aclosed https://github.com/supabase/supabase/pulls?q=is%3Apr+author%... Twenty: https://github.com/twentyhq/twenty/pulls?q=is%3Apr+author%3Agitstart-twenty+is%3Aclosed 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!

steve76 3y ago
[dead]
bitlad 3y ago
Two observations. - This does not work beyond OSS projects. This is literally a compliance leaders nightmare. I just don't know who is touching the code, how and where ahead of time, no background checks etc. - Secondly, this feels like a nice way to "growth hack" you Github stars and fake some metrics for VCs. Your pitchdeck can 100s of contributors and 1000s of stars without really creating much value.
- hzia 3y ago
  Currently most of dev bounty platforms do start with OSS, but we only started doing that last year. Because of that, 90% of users of our commercial usage today is still close-source, and biggest customer base are from heavily regulated industries like insurance, finance, and even commercial banking, with 2 of them having > $15B each under management. Now, as you pointed out, we had to implement and background checks, audit logs and have direct full-time relationship with devs through our subsidiaries. But what made the biggest difference was our security tooling like GitSlice, which along with dev environments cuts down majority of risk exposure. I would be really curious why you think something like this wont work for private repos?
  - bitlad 3y ago
    There can be two reason why it is working. - They might be running shadow IT - Security and compliance is not their priority. Since you have implemented BG and other controls. My follow up question is are these devs in that case EOR or contractors whose payroll is processed via you. Your org starts to look like deel, remote or midsource. The whole PR assigning to junior devs feels gimmicky, no? However, there are two problem statements you are solving. I agree with the first premise, remote junior devs will get better opportunities and confidence when they do this exercise. I think the second part of value generation, I think risk is too high for a closed source org.

235 points by hzia 3y ago

steve76 3y ago

[dead]

bitlad 3y ago

Two observations. - This does not work beyond OSS projects. This is literally a compliance leaders nightmare. I just don't know who is touching the code, how and where ahead of time, no background checks etc. - Secondly, this feels like a nice way to "growth hack" you Github stars and fake some metrics for VCs. Your pitchdeck can 100s of contributors and 1000s of stars without really creating much value.

hzia 3y ago
Currently most of dev bounty platforms do start with OSS, but we only started doing that last year. Because of that, 90% of users of our commercial usage today is still close-source, and biggest customer base are from heavily regulated industries like insurance, finance, and even commercial banking, with 2 of them having > $15B each under management. Now, as you pointed out, we had to implement and background checks, audit logs and have direct full-time relationship with devs through our subsidiaries. But what made the biggest difference was our security tooling like GitSlice, which along with dev environments cuts down majority of risk exposure. I would be really curious why you think something like this wont work for private repos?
- bitlad 3y ago
  There can be two reason why it is working. - They might be running shadow IT - Security and compliance is not their priority. Since you have implemented BG and other controls. My follow up question is are these devs in that case EOR or contractors whose payroll is processed via you. Your org starts to look like deel, remote or midsource. The whole PR assigning to junior devs feels gimmicky, no? However, there are two problem statements you are solving. I agree with the first premise, remote junior devs will get better opportunities and confidence when they do this exercise. I think the second part of value generation, I think risk is too high for a closed source org.