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

[hzia]

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!

[thecodrr]

These guys also tried to submit PRs on the Notesnook[0] repository. The PRs are really good but there's no way to talk to the actual developer working behind those PRs. They have a single central account named "gitstart" and all PRs that any of their user works on falls under that account. Of course, we couldn't accept PRs from them because they don't follow DCO[1] i.e., DCO requires that the committer MUST NOT be an organization.

I talked to them about this and they said they'd work on it etc. etc. Not sure if anything has changed in that regard or not.

[0] https://github.com/streetwriters/notesnook

[1] https://developercertificate.org/

[abstractcontrol]

> The PRs are really good but there's no way to talk to the actual developer working behind those PRs.

I'd really like an avenue to get into the US market as a remote worker, but am being unfairly treated by this job market. It is a pity as I am both a highly skilled programmer and have nearly a decade of experience. I'd consider this service if it could serve to showcase my skills, but if I am not going to get any credit for doing the work personally, there doesn't seem to be much point to it.

[thaumasiotes]

> Of course, we couldn't accept PRs from them because they don't follow DCO[1] i.e., DCO requires that the committer MUST NOT be an organization.

I read the certificate. It isn't long:

    Developer Certificate of Origin
    Version 1.1

    Copyright (C) 2004, 2006 The Linux Foundation and its contributors.

    Everyone is permitted to copy and distribute verbatim copies of this
    license document, but changing it is not allowed.

    Developer's Certificate of Origin 1.1
    
    By making a contribution to this project, I certify that:
    
    (a) The contribution was created in whole or in part by me and I
        have the right to submit it under the open source license
        indicated in the file; or
    
    (b) The contribution is based upon previous work that, to the best
        of my knowledge, is covered under an appropriate open source
        license and I have the right under that license to submit that
        work with modifications, whether created in whole or in part
        by me, under the same open source license (unless I am
        permitted to submit under a different license), as indicated
        in the file; or
    
    (c) The contribution was provided directly to me by some other
        person who certified (a), (b) or (c) and I have not modified
        it.
    
    (d) I understand and agree that this project and the contribution
        are public and that a record of the contribution (including all
        personal information I submit with it, including my sign-off) is
        maintained indefinitely and may be redistributed consistent with
        this project or the open source license(s) involved.

Where does this require that the submitter not be an organization? Even if you're fully committed to that idea, the obvious approach would appear to be:

(1) GitStart releases their patch under the open source license of the project's choice.

(2) An employee of GitStart submits it, in their official capacity, to the project, asserting under clause (b) that the contribution is based on (consists entirely of) previous work that is covered under an appropriate license.

[hzia]

It is on our roadmap to properly integrate DCO on the platform, as its a hard blocker for all repos under the linux foundation. We already add each devs that touches the PR internally as co-author now

The problem lies in the definition that “committer most NOT be an organization” which would require us to do a full review of our legal contract with devs so that this condition is upheld properly

[Kiro]

What's the point of DCO? Really don't understand why you would want to cripple yourself with that.

[dirtybirdnj]

I think this is a cool idea worth exploring.

At a lot of jobs I've dealt with using contractors, there was an internal concern that people external "didn't care" enough. How do you plan on addressing this concern?

It's a system that will depend a lot on trust, and it may be difficult to build that with companies whos DNA does not lend them to trust outsiders AT ALL let alone let them come in and muck with production level code (letting juniors do it!)

I'm playing devils advocate, like I said I think your idea is cool and worth exploring. Not enough companies invest in juniors to grow them into their full potential, and I commend you for this effort. Good luck.

[hzia]

> At a lot of jobs I've dealt with using contractors, there was an internal concern that people external "didn't care" enough. How do you plan on addressing this concern?

That’s correct. Either you are a full time employee, or you get second-class culture even if you are part of internal slack. It’s very hard to get external contractors to be excited when they dont get the swag / on-sites and share the culture.

Which is why we want to have devs belong first class citizens in the GitStart Community, and join all hands / game nights and learn from others. And our integrations push through PRs and all the updates to engineering teams.

[wallmountedtv]

I think we can see to Hacktoberfest as a comparison to this "let external junior devs to deal with backlog" idea. And this project gives the same fear and worries of that "chase for the cheapest PR to get my reward"-logic as that which Hacktoberfest encourages.

While GitStart pays their developers, that alone could encourage better habits, I fear it could also enable this chasing reward mentality harder, setting the juniors up for failure, as well as frustrating the customer with having to deny and review multiple low-quailty PRs.

How is this avoided? This seems heavily at risk to cause more headache than help.

[bradly]

> At a lot of jobs I've dealt with using contractors, there was an internal concern that people external "didn't care" enough. How do you plan on addressing this concern?

From my experience hiring, both full-time employees and contractors can not care; it felt more about the individual's character than their employment status.

[charlesTwenty]

Hi, I'm one of the main maintainer of Twenty and we have onboarded Gitstart on our codebase a few weeks ago. I can give a feedback on our collaboration so far:

1) Code quality is good, I would compare it to a very good junior engineer (I suspect some senior engineers are reviewing the code before shipping it!). We are reviewing all PRs and it usually takes 1 or 2 round of feedbacks before merge.

2) Gitstart developers are very reactive on pull-requests, their response time is not a bottleneck

3) You will need to be very accurate about your features. I think Gitstart direclty makes sense for open-source projects as this is part of the culture to discuss everything on issues, to share resources (figmas, specs, technical vision). If your company already has a culture of documenting most of the knowledge async, this should be a good fit.

[hzia]

Appreciate the feedback and for trying it out!

You are spot on that GitStart works really well for teams that have a culture or a strong intention of doing that

[amykhar]

The fact that it's using devs from 'remote countries' says to me they want to pay low wages. If this project paid market wages and was for devs worldwide who met minimum qualifications, I'd think it was cool. As it stands now, it just comes across as borderline exploitation.

[joshmanders]

I think you're looking at it with malice in mind. I see it as more of a "Lets get work to remote countries that typically wouldn't and show people that they can be quality developers"

[wutania]

afaik gitstart pays above market in the local economies, but there’s always room to improve of course. however it’s hard to pay everyone the market rate of american companies.

the developers are typically folks who wouldn’t be able to get a remote job otherwise due to universities not being globally recognized or english is not super fluent. many developers grow a lot during their time at gitstart and eventually move on to getting jobs at places like Google, Amazon too. they support any developer to grow (there’s a team dedicated to figure out growth paths for each developer on the platform)

disclaimer: i used to work at gitstart

[yakshaving_jgt]

A low wage in the market is a market wage. I'm not sure where you get "exploitation" from this.

[killerstorm]

Market wages are set by supply & demand. If somebody to agrees to a "low wage" and there's no coercion or deception involved, it's a market wage, by definition.

[Kiro]

What are market wages? Even in my country which qualifies as one of the most modern countries in the world the wages are really low compared to the US.

[rsstack]

I'm confused about the pricing. The pricing page shows this PR as an example of a "small" PR of 15 "credits". I have a hard time agreeing that this change is worth $150: https://github.com/calcom/cal.com/pull/8218/files

When seeing $10/credit, I thought a PR this small would be just one or two credits. I'd totally pay $150 to fix 10-15 such small bugs, but only one? Am I missing something?

[hzia]

Did you go through the PR discussion though?

In this particular case there was technical discovery on a non-trivial approach to patch an npm package (which didn't work out)

But above aside, one can get a lot more milage out of GitStart if small fixes are bundled together. As that means all of them share the cost of QA (across devices), bundled code review and less context switch overhead.

[michaelt]

A Silicon Valley developer on $200,000 costs $100/hour in salary alone.

When your employer onboards new hires, do they have a commit merged into main in their first 90 minutes with the company?

Software development is an expensive business, and some companies are used to paying this much and more. The no-fix-no-fee pricing model would also command a premium over hourly work.

[outsidetheparty]

I appreciate the intent here, but these are the immediate issues that leap to mind:

* "Do work, but get paid only if we use it" feels potentially exploitative. You do mention a "base pay" rate but I wonder how it compares to the "merged PR" rate?

* Code quality and adherence to internal code standards is challenging for external contributions. Open source projects, of course, are already used to this, so it's not surprising to see that's where the bulk of your current customer base lives; it's more difficult to see how this would work with other types of organization -- I'd be concerned that I'm spending more time in code review and such than I'd gain in contributed lines of code.

* The whole setup seems to fit in an uncomfortable middle ground between just hiring an offshore developer directly or through a traditional outsourcing firm, on the one hand; and hourly piecework on the other. The only advantage I see to this sort of arrangement on the hiring end compared to regular old long-contract outsourcing is that I don't have to pay for work I don't end up using, but that circles me right back to the "exploitative" part.

[hzia]

> "Do work, but get paid only if we use it" feels potentially exploitative. You do mention a "base pay" rate but I wonder how it compares to the "merged PR" rate?

90% of compensation for devs is base and does not depend on the “merge PR” rate (which is in-fact 95%)

> * Code quality and adherence to internal code standards is challenging for external contributions

> The whole setup seems to fit in an uncomfortable middle ground

Majority of our customers are in-fact private and not OSS. We can unfortunately only share the latter. But it is targeted towards engineering teams that have already started to invest into DevEx and building tooling to make contribution easier We do help to set that up if customers sign up on the Team or Enterprise plan as a first sprint to add all these guardrails in place.

I agree that junior devs today are heavily exploited by existing freelance and outsourcing platforms where it's a race to the cheapest contractor in the market. For teams who want to freelance, we are not a good fit (and most likely more expensive). Where we do shine is an in-house team that does not have the bandwidth to hand-hold each external contractor one by one to become productive. And with that focus, our devs get to enjoy a fixed base stipend, career ladder internally to grow and successfully joining our customers and / or larger corps like Meta, Google and so on

[iFelix]

I don't get some of the negative comments. We run an open source project with a very long backlog and I came across Gitstart as I was looking for ways to accelerate development. We started working with them recently and overall I'm very happy with the service. At first the quality of PRs wasn't great, but it is still better than the average open source contribution, and it's improving everyday as they gain knowledge of our codebase and expectations. As a remote team that is just starting a new project, it would have been hard for us to onboard and train a junior developer today. Using Gitstart fills a gap for tasks that we can easily delegate, typically something that's already done in a similar way in the code base. That way our team can focus on more challenging problems.

(Note: I was not asked to post this)

[bitlad]

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]

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?

[alfalfasprout]

I imagine that it only works for the typical type of work that gets outsourced anyways-- very tightly scoped work in codebases that don't actually require deep integration with production systems or anything all that critical.

I have yet to have a super positive experience with the quality of work of offshore contractors either internally hired or via an external consulting company.

[grork]

I like the aspiration to grow engineers — it’s a laudable, and worthy, goal.

But I also feel there is a little bit of a pandora’s box here.

The model you’re creating here is more structured ‘gig economy’ path for software dev. Sure, you’ve got things like UpWork, and other freelance products, but the purchasers (e.g., business) are effectively taking a risky bet on the work which can tamper commitment to purchasing work that way.

But with ‘no merge, no fee’ could create a very strange dynamic where companies will opportunistically throw work over the wall and create bounty-like dynamics. I don’t know if this is particularly bad for the purchaser, but for the seller that could lead to some challenges overtime (race to the bottom etc)

[awesomeMilou]

I am trying to apply as a developer but I'm getting an "Invalid Format" error: https://developers.gitstart.com/welcome

On this page. The error is coming from your GraphQL backend:

{ "errors": [ { "message": "has invalid format", "path": [ "createDeveloperProfile" ] } ], "data": { "createDeveloperProfile": null } }

[madeofpalk]

> A number of commercial open source repos already use us

Worth acknowledging that GitStart has, at least in the past, submitted PRs to open source projects unsolicited in an attempt to bolster their reputation.

We found their PRs to be of extremely rough quality - exactly what you would expect from junior offshore developers - and it took up a non-trivial amount of our time to deal with the contributions and get them into a state where they could be merged. We would also often find 10+ email addresses associated with a single one-line change commit, which I found quite odd.

While I/we encourage contributions from developers of all levels, it felt super iffy that we were investing in coaching the junior developers of the YC/VC-backed startup, only for them to use us for cred.

In the end I believe we blocked GitStart from our repo.

[hzia]

I am really sorry you had a bad experience. As a bit of background, we started OSS contributions initially as a way for new devs who were ramping up to grow on open source repos. We learned a lot, and from feedback, we took that away and for the last few months OSS contributions are now on par quality as commercial ones.

I remember your case personally and reached out to you over email to apologize at that time last year. If there is anything else did wrong, please let us know

[derefr]

> We would also often find 10+ email addresses associated with a single one-line change commit, which I found quite odd.

To be charitable: could have been that the commit started off big and complex, getting modified and reviewed by several people over time... before one person finally figured out how to simplify it down to one line — and so then they rebase-squashed it down to just that line, rather than polluting your commit history with all the intervening nonsense.

[estebarb]

I want to point that rought code is expected from junior developers in general, not only "offshore" devs.

It is sad that developers from global south usually have to perform at a much higher level than their peers at the north, just because unfounded prejudices.

[moneywoes]

What is your project?

[andrewfromx]

"Your backlog is someone else's opportunity" is great line but I fear I would get tons of messy un-usable stuff that isn't really of any value to me. I wonder if you should pair this with like teaching and I should get the PR + some cash to review it?

[ayewo]

I’m curious why it took you guys so long to do a Launch HN considering you are from YC S19 — a batch from 4 years ago?!

Is GitStart a significant pivot from what you started with?

[sdesol]

Here's some insights for PRs created within the last 120 days for the mentioned repos.

88 PRs created: https://reviews.gitsense.com/insights/github?p=days-open&q=a...

70 merged: https://reviews.gitsense.com/insights/github?p=days-open&q=a...

7 rejected: (closed/not merged) https://reviews.gitsense.com/insights/github?p=days-open&q=a...

Interesting take away is, the merge rate is quite high, but since we can assume these PRs were created for a reason, can we also say 7 not being merged is also bad?

Full Disclosure: This is my tool

[hzia]

Love the analysis! Usually the closed number is higher because there are still many edge cases where PRs get closed outside of bad code. E.g bug already fixed in master, follow up PR, PRs merging into a larger one and so on

I think basic NLP on the PR decision may be able to automatically differentiate them

[ye-olde-sysrq]

IMO this doesn't help solve backlog problems, it just means paying the (non-headcount) costs of a junior dev while not even making people investment that will make it worth it later.

In general, jr devs are net-negative. (If they're not, they're not junior! promote them!). They are an investment, they are learning and growing. It will take a senior longer to review, mentor, and coach them to a PR that the senior could've gone straight to that same PR. The whole point is that eventually you've grown another senior dev who will return big multiples on their compensation.

This sounds like you're just going to be spending sr dev time reviewing and rejecting, to have de minimis backlog items (there's a reason they're in the backlog and not prioritized) fixed, and you're not even growing a senior dev, which is the whole point.

Plus, IME most companies carry so much cultural context that being exposed to it for exactly 1 ticket + not having inside people to ask questions means this will be an uphill battle.

[hzia]

Completely agree on jr devs being net-negative! The cost however is far more than the PR itself (onboarding, fixing their environment, helping understand how react hooks work and so on).

With GitStart, we take everything else away entirely (dev envs, preview links, mentorship, trainings etc), with strong processes to make sure PRs are heavily reviewed internally with solid QA before its pushed upstream. I think this drastically reduces cost of working with juniors to the point that its “profitable”

Right now it’s not for everyone, especially for companies where there not enough motivation internally to craft good tickets or having enough backlog thats critical enough to make use of GitStart.

Now everything aside, we actually have seen cases where devs internally grow within, apply to our customers and become full time hires! We dont bind our devs at all to join our customers directly and instead celebrate it when it happens!

[hdjjhhvvhga]

Yeah, that's exactly the reason why junior positions in my niche are almost non-existent. Everybody wants to have seniors or at least regulars, but a junior just means problems for everyone. And you can't be sure they will stay once they learn enough.

[ritzaco]

A bit OT but I was curious about

> 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.

Is this an internal tool or something you also make (or plan to make) available? We have this problem too at Ritza (a technical writing agency), where often our customers have a mono-repo with a docs/ subfolder that we need access too. Currently we solve this with some custom bash scripts and cron to sync just a subfolder to an internal copy, but is far from perfect and still involves some manual cherry-picking.

[hzia]

You can potentially use CopyBara https://github.com/google/copybara

We go much further than CopyBara by syncing CI / CD pipelines, syncing review comments and so on.

We are considering launching GitSlice as product on its own. If you are interested, email me and I can keep you updated when its ready to test (hamza [at] gitstart [dot] com)

[brap]

>Your backlog is someone else's opportunity

Yeah, I don’t care.

I don’t mean to be harsh, but if I have to justify spending my company’s money on this, this is definitely not something I’m going to say. This isn’t charity, and I’m looking for quality code.

[bradly]

Have you noticed any interest in this for non-junior devs? As I rusty, old Ruby on Rails developer, I'd love to be able to be hired for single features.

[hzia]

We get this request often and personally I would love see this happen! I know quite a few senior devs who want to contribute reviewing PRs or contribute in the tech stacks they love with no strings attached.

The reason we have not done that is because we get all devs to commit full time on the platform, and thats a deal breaker for senior devs. Part time doesnt work well for juniors to reasonable grow on the platform, but I can defn see that working for seniors.

Curiously, how you do see your normal day look like if you could something like GitStart on the side as a part time senior?

[hzia]

I see more interest on this than I expected!

In the last month, we have rejected quite a few tickets that may have been easily tackled by a senior dev. Including technical documentation for infra, K8S, CLI agents to collect runtime traces, fixing flaky E2E tests and so on.

Hola at me if you are interested! (email in bio)

[wavemode]

The business model makes perfect sense to me. This is essentially a modernized version of what most big companies are already doing to shore up engineering needs at low cost (they will go to some overseas consulting company and say "hey we need X devs with Y skills, we can pay them Z per hour. project will last T months.").

[quadcore]

Wow I love the idea, thanks for making this and congrats on the launch.

From the comments I read I can tell the receiving devs can easily become grumpy if things are not as they want to the semi-colon.

A few ideas to solve that problem.

1. Have an internal team of experienced devs who make CRs and onboard the team of juniors on a new projects. From my experience, after a couple mistakes or misfit code, juniors adapt themselves, learn and end-up doing perfectly well.

2. When you submit a PR, submit a process with it (in a readme of some sort) with instructions on how the receiving devs should proceed with the PR. If they are not happy with it, maybe they can just say "not happy with it" and you take on yourself to figure out why. That sort of instructions. The last thing you want is them complaining they spend more time on it than simply coding it.

Im pretty sure the management of the human interface here is key because the only way this can work is if you've got off-the-charts feedbacks. You need processes for that (you probably do already).