cal.diy

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!