# Designing first PRs that do not require a local environment > Source: > Published: 2026-07-10 05:10:23+00:00 A "good first issue" is not actually beginner-friendly if a contributor must install a mobile app, an API, two speech engines, and model files before changing one sentence. I ran into this while preparing [ai-language-partner](https://github.com/duct-tape2/ai-language-partner), a local-first Japanese speaking practice app for Korean learners. The full stack includes Expo/React Native, FastAPI, local STT, local TTS, and pre-authored dialogue packs. That is useful for the product, but it is a poor prerequisite for someone's first pull request. I split the work into three lanes: The browser-only lane is not a typo farm. Each task has user value, a linked issue, a source file, acceptance criteria, and a direct GitHub edit link. Each no-install task tells a contributor: The project currently has 27 browser-only tasks within 52 scoped public issues. Automation responds to a claim command, posts a first-PR guide, and prepares a review packet. It does not decide whether a contribution is meaningful. The maintainer still checks: I am intentionally not optimizing for raw PR volume. One contributor with one useful merged PR counts. Maintainer-authored PRs, bots, duplicate identities, and split typo PRs do not. That policy makes growth slower, but the public contribution record is real and auditable. The open question is whether reducing setup cost is enough to turn discovery into completed contributions. I am tracking claims, opened PRs, review latency, and merged external contributors rather than only stars. The repository and hosted demo are public: If you maintain a project with a heavy local setup, which tasks have worked well as genuinely useful browser-only contributions? *Disclosure: I used AI coding assistants to help organize parts of the repository workflow and edit this post. I reviewed the final structure, links, and claims.*