ReadyToTouch: a Go-backed directory of companies hiring backend engineers

A company list built for one person changing stacks

The problem is narrow on purpose. Someone wants to know which product companies actually run a given language in production, so they can aim a job search at real employers instead of guessing from job boards. The site answers that with one list per language, and every list entry links out rather than hosting data. Each company profile points at Careers, GitHub, Glassdoor, Levels.fyi and a LinkedIn search for current and former employees, so the intended use is to pick a company, then check whether it is hiring on the employer own page. The editorial rule behind the selection is narrow as well: product companies and startups only, no outsourcing, no agencies. That filter is what separates this from a generic company directory, and it is also the part no reader can audit from the code, because membership is decided by a person. The author describes the origin as preparation for a future move made while holding a stable job, so read the selection as personal taste expressed as data.

921 Go companies against 11 in Haskell

The language table shows where this directory is thick and where it is thin. Go carries 921 companies, Rust 301, Scala 169, Elixir 119, Clojure 25 and Haskell 11. Four more rows, for Erlang, Zig, F# and OCaml, carry a dash in the companies column instead of a number. Those rows deserve attention: the language page exists and the route is published, so a search for Zig or OCaml lands on an empty list. The discussion threads linked from the repository follow the same pattern, including one post asking maintainers of other lists whether OCaml should be added, which shows coverage follows demand rather than a survey. The Go lead also explains the stack. The service is written in Go, the module is `github.com/readytotouch/readytotouch`, and dependencies cover a web server plus PostgreSQL and Redis clients, with nothing aimed at scraping or ranking. Run a search for Zig or F# and you get a page and no entries.

Weekly updates, and the notice that paused them

Two archive signals in this project disagree, and the conflict matters for anyone planning to depend on the data. Repository metadata reports the project as archived: no, with the last commit landing on 2026-08-25, yet the top of the README opens by stating that the repository is archived and that weekly data updates are on pause while the author works on monetization strategy. The same notice says the platform remains fully online and free to use, so the notice marks the code and the update routine, not the running site. In practice the 921-company Go list is no longer being topped up on the cadence the project description still advertises, even though the site keeps serving. Metadata alone would tell you the project is live and changing; the first lines of the README tell you the opposite. Treat the counts as a snapshot with an unclear end date.

Four make targets bring the Go service up

There is no install guide, because this is a website rather than a library, but the repository ships a working local path and the README lists all of it. The Makefile starts by including `Makefile.ansible`, then points a `docker-compose.yml` symlink at the development compose file and copies the checked-in environment file before anything starts. The four documented commands cover the whole first run: prepare the compose symlink and environment, start the containers detached, load the database, then rebuild and restart the compiled binary.

make env-docker-compose-development
make env-up
make pg-fixtures
make app-restart

Expect containers to appear rather than a locally installed binary. Compilation happens inside the app container, so a Go toolchain on the host is not what builds the project, Docker Compose does that work.

The environment step silently replaces your own .env

The preparation target does more than the four line sequence advertises. It deletes any existing compose file, replaces it with a symlink into the development directory, and copies the checked-in development environment file over `.env` in the repository root, with no backup and no confirmation. That ordering means a developer who kept local secrets or an overridden database port in `.env` loses them on the first run, and the Makefile provides no target that reverses the copy. A separate production target performs the same swap from a different checked-in environment file, and nothing in the environment targets tells you which file was just overwritten, only that one of them was. Adding the directories the compose file needs, such as the Postgres data directory, is a separate target the documented sequence does not call, so a fresh clone can fail at the compose step before any application code is reached.

rm -f docker-compose.yml
ln -s ./docker/compose/development/docker-compose.yml docker-compose.yml
cp .development.env .env
docker compose -f docker-compose.yml --env-file .env up -d

Those four lines sit inside the two environment and start targets, copied from the Makefile exactly. The `--env-file .env` flag is why the copy step matters, because compose reads whatever the copy just placed there.

Fixtures are three raw SQL files, not a migration set

Seeding the database pipes three checked-in SQL files into the running Postgres container as the `yaaws_user` user against the `yaaws` database, one file per domain. Nothing in that target calls a migration tool, so the fixtures double as the schema for a local run. The repository carries `sqlc.yaml` at the top level, which points query generation at SQL, plus a `protos/` directory for interface definitions, and that fits the surrounding layout of `cmd/`, `internal/`, `client/`, `public/` and `datasync/`. The binary itself is compiled from `./cmd/main.go` and installed as `yaaws-server` inside the app container, a name matching the `yaaws` topic in the repository metadata rather than the product name, an oddity worth knowing when you grep the code. Tests and benchmarks run through the same container.

cat ./fixtures/postgres/users.sql | docker exec -i readytotouch_postgres_db psql -d yaaws -U yaaws_user
docker exec readytotouch_go_app go build -o /bin/yaaws-server ./cmd/main.go
docker exec readytotouch_go_app go test ./... -v -count=1

One fixture file per entity, then a build and a test run. The test target forces a fresh count, and the benchmark target pins the run length with `-benchtime=1000x`, which keeps comparison runs comparable on slow machines.

Every profile is a bundle of outbound links

Nothing on a profile page is a copy of employer data. Each entry links to the careers page, the GitHub organisation, Glassdoor, Levels.fyi and a LinkedIn search covering current and former employees. That design keeps the site cheap to run and immune to expiring postings, and it moves the verification burden onto the reader, who opens four or five third-party pages to judge one company. Freshness becomes a property of those outbound links rather than of the listing: a dead Glassdoor page stays dead in the directory. A `datasync/` directory at the top level, plus two linked research repositories on online Redis and online Postgres under a separate account, show the ingest side was studied in public even though editing stays manual. Two analytics endpoints, one for Plausible traffic and one for Similarweb, run alongside the app. No public API, export or scrape interface is documented anywhere.

A paid placement at the top, and a shut contribution door

The commercial model is stated openly: recruiters can buy a paid pinned placement at the top of their language list, and the README asks readers to raise it with their recruiter. That single sentence explains the archive notice, the halt to weekly data updates and the refusal of outside help at once. Contributions are explicitly closed for two stated reasons, planned monetization and a small team with an established workflow, with the note that extra contributions would slow the project rather than help. Forking stays possible under the MIT licence, so the code and the SQL fixtures can be reused for a self-hosted copy even when pull requests are refused. The difference from building a target list yourself is the curation filter and the pre-linked profile structure; the difference from a live job aggregator is that nothing updates on its own, so a company that stopped hiring stays in the directory with dead links instead of dropping out. If you need only one language, the two related research repositories on online Redis and online Postgres describe the data layer rather than the product.

Editorial conclusion

ReadyToTouch is worth bookmarking if you are a Go, Rust, Scala or Elixir developer picking employers, and worth ignoring if you need a job feed with fresh postings or a public API. Check three things first: whether the Go list still changes now that weekly data updates are on pause, whether the four languages showing a dash in the table will ever fill in, and whether the code lets you run your own copy, which the four make targets and the raw SQL fixtures make possible. Then confirm any company you shortlist against its own careers page before you apply.

Frequently asked questions

Official sources

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