alura/techguide: a T-shaped career map you can fork and rebuild

The problem TechGuide.sh solves, and who it is written for

A junior developer asking "what should I learn next" usually gets an unordered list of technologies. TechGuide.sh answers that question with a structure: the T-shaped professional, someone with one deep specialty plus working knowledge of adjacent areas that make their own work or their team's work easier. The README attributes that framing to Alura's Dev em T material and says the project was inspired by the open source roadmap.sh, but deliberately differs in two ways. It uses the T model instead of a single linear track, which the README says opens more possible paths and orderings, and it wants more descriptive text explaining why each card is worth learning. The audience is explicit in the README: Alura students and the school itself, which uses the map to decide which courses, podcasts and articles to produce. If you are neither a Portuguese-speaking learner nor someone building a curriculum, the value you get is the data model, not the site.

How the guide is assembled: Next.js pages over YAML data

The repository is a Next.js application, not a static document. package.json names it tshapeddev at version 0.8.0, and the scripts are the standard Next set: dev, build, start, plus build:static for next build && next export. Content sits in _data as YAML, which is why the lint script runs eslint over src and _api and then yamllint over ./_data/**/*.yaml. Pages live in pages/, shared components in src/, and there is a GraphQL layer: apollo-server-micro and @apollo/client are dependencies, graphql.schema.json is checked in, and two codegen configs (codegen.yml for the back end, codegen-front.yml for the front end) generate types via graphql-codegen. A _scripts directory holds TypeScript tooling, including a module that produces shareable guides and a variant that emits them as PDF. The practical consequence is that a career is a data change, not a code change: you edit YAML, run the lint script, and the rendering layer picks it up.

Running TechGuide.sh locally and exporting a guide

The README does not include an install section, so the commands below come from package.json and from the repository layout rather than from documentation. The project pins a Node version in .nvmrc; read that file before installing, because Next 12 era toolchains are sensitive to the runtime.

cat .nvmrc
yarn install
yarn dev

The dev script starts next dev, and the README's FAQ points readers at https://techguide.sh as the hosted instance. To produce a static export instead of a server, use the build:static script, which runs next build followed by next export.

yarn build:static

The export path matters if you intend to host your fork on static hosting. If you change or add YAML under _data, run the lint script first; it is the only check in the repository that validates those files.

yarn lint

For a shareable artifact rather than a site, package.json exposes a script that generates guides and a second one that renders them to PDF, both driven by tsx against files in _scripts/modules. The README's roadmap lists exporting the T so a person can follow their own path and tell their story as done, and exporting the T as a study script as still open.

Contributions are welcome, new careers are not

This is the most useful thing to understand before opening a pull request. The README states plainly that the project is not looking for new careers right now and wants to refine the ones it already has, and that help with the code and the project itself is more interesting to the maintainers. It also asks contributors to pick a good, simple, explanatory title for items and to follow the file formatting, which is where yamllint comes in. The FAQ repeats the same posture: yes, you can suggest careers through the GitHub contribution mechanism, but the current focus is correcting errors and improving existing careers. For someone who wants to add a career that is missing, the README offers a workaround instead of a merge: create your own guide by following docs/br/criando-seu-guide.md. That is a legitimate path, and it also tells you the maintainers would rather review a fix to an existing card than a new branch of the tree.

Where it falls short: language, API stability and scope

The README's roadmap lists full English support as an unchecked item, so the product is Portuguese-first and an English reader is working against the project's own stated backlog rather than a finished translation. The FAQ also describes a future capability that does not exist yet: loading YAMLs from people, companies and even other schools, with an issue linked as a sketch of the idea. Anyone planning to build on that multi-tenant model is planning against a proposal, not a feature. There is a GraphQL schema in the repository, but the README does not document it as a public API, does not promise versioning, and does not describe authentication or rate limits, so treating the endpoint as a stable integration surface is a guess. Finally, the project is opinionated about scope in a way that limits it as a general tool: it maps careers the way Alura wants them mapped, which is exactly what makes it useful for Alura's course planning and exactly what makes it a poor fit if you need a neutral, vendor-independent competency framework.

roadmap.sh is the obvious comparison, and the README names it

The README says the project was inspired by roadmap.sh, which is also open source, and then states the two deliberate differences: the T-shaped approach instead of roadmap.sh's path model, and more descriptive copy explaining why each item is on the map, with tighter scope per item. The difference in practice is structural. A roadmap tends to answer "in what order do I learn this stack," while a T-shaped map answers "what is my depth and what is my breadth." If your problem is sequencing a single track, roadmap.sh's model matches the question more directly. If your problem is deciding how much adjacent knowledge a backend developer should carry, the T framing is the one TechGuide.sh was built around. Note also that TechGuide.sh ties its content to a specific school's output, which roadmap.sh does not.

Licence and the ongoing cost of a fork

The project is MIT licensed, and the README asks anyone generating their own guide to link back to https://techguide.sh and to respect the licence. MIT is permissive: it allows reuse and modification with the licence and copyright notice preserved. That is the extent of what the repository states, and it is not legal advice; if you plan to redistribute the YAML as part of a commercial product, have counsel read the LICENSE file rather than this article. The maintenance cost is the part people underestimate. A fork inherits a Next.js app, a GraphQL layer with generated types, and a YAML corpus that must pass yamllint. Upgrading means touching the codegen configs and regenerating types, not just bumping a dependency. The last push to the repository was on 2026-07-22, so there is recent activity, but the README's own roadmap shows English support and the multi-source YAML feature still open, which means a fork owner should expect to carry those gaps rather than wait for them.

Editorial conclusion

Adopt alura/techguide if you want a forkable, MIT-licensed career map whose guidance lives in YAML files you can edit, and if Portuguese-language content is acceptable. Do not adopt it if you need a fully English product, a stable public API, or a roadmap that the maintainers are actively expanding with new careers; the README states the team is focused on fixing errors and improving existing careers rather than adding new ones. Verify first that the repository still builds under the Node version pinned in .nvmrc, and read docs/br/criando-seu-guide.md before writing your own guide.

Frequently asked questions

Official sources

1. alura/techguide on GitHub
2. Issues
3. License: MIT
4. Project website
5. README