Development setup with LingCode

Foundations: one-time install

Homebrew (the package manager you'll use for everything else)

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

After install, make sure /opt/homebrew/bin (Apple Silicon) or /usr/local/bin (Intel) is on your PATH. Test with brew --version.

Language toolchains

Install only what your stack actually uses. Mix-and-match fine.

brew install node      # Node.js + npm
brew install python    # Python 3.12+ (system Python is too old)
brew install go        # Go
brew install ruby      # Ruby (or use rbenv/asdf for multiple versions)
brew install rust      # Rust (or rustup.rs for the proper installer)

For multiple versions of one language, install a version manager: nvm (Node), pyenv (Python), rbenv (Ruby), or asdf (unified).

Docker (for databases and ephemeral services)

Most local DB setups are easier with Docker than with a native install — one command to start, one to stop, no PATH conflicts. Install Docker Desktop or the lighter-weight OrbStack (recommended on Apple Silicon — uses less memory, faster).

Local databases

Postgres (the default choice for most apps)

Two ways to run it. Pick one; don't mix.

Option A — Homebrew (native):

brew install postgresql@16
brew services start postgresql@16
createdb myapp_dev
psql myapp_dev   # verify it works

Connects on postgres://$USER@localhost:5432/myapp_dev. Survives reboots via brew services. No password by default.

Option B — Docker (isolated):

docker run --name pg16 -d \
  -e POSTGRES_PASSWORD=dev \
  -e POSTGRES_DB=myapp_dev \
  -p 5432:5432 \
  -v pg16data:/var/lib/postgresql/data \
  postgres:16

Connects on postgres://postgres:dev@localhost:5432/myapp_dev. Start/stop with docker start pg16 / docker stop pg16. Data persists in a named volume, so restarting the container keeps your data.

MySQL

brew install mysql
brew services start mysql
mysql -u root -e "CREATE DATABASE myapp_dev;"

Or Docker:

docker run --name mysql8 -d -e MYSQL_ROOT_PASSWORD=dev -e MYSQL_DATABASE=myapp_dev -p 3306:3306 mysql:8

Redis (caching, queues, sessions)

brew install redis && brew services start redis
# or
docker run --name redis -d -p 6379:6379 redis:7

Test with redis-cli ping → PONG.

SQLite (no server — just a file)

Already installed on macOS. Nothing to set up. Most ORMs (Prisma, Drizzle, Django ORM, ActiveRecord) support it out of the box. Perfect for prototyping; graduate to Postgres when you hit concurrency or production.

Migrations & seed data

Raw SQL is rarely how you shape a schema during development. Use a migration tool — it tracks which schema changes have been applied, lets you roll forward/back, and turns "set up a fresh database" into one command.

• Node / TypeScript: Prisma (npx prisma migrate dev) or Drizzle.
• Python: Alembic (alembic upgrade head) for SQLAlchemy; Django has built-in manage.py migrate.
• Rails: built-in (bundle exec rails db:migrate).
• Go: golang-migrate is the most common choice.

Seed data — the "give me a dev database with 10 users and 50 posts" step — usually lives in a prisma/seed.ts, db/seeds.rb, or a Python script. Commit it to git so teammates and CI get identical starter data.

Env vars, .env files, and secrets

The .env pattern

Store development config in a file your app reads on startup, not hard-coded. Keep it out of git.

# .env (local only; never commit)
DATABASE_URL=postgres://user:dev@localhost:5432/myapp_dev
REDIS_URL=redis://localhost:6379
CLAUDE_API_KEY=sk-ant-...
STRIPE_SECRET_KEY=sk_test_...

And a .env.example that is committed, with placeholder values, so new contributors know what to fill in:

# .env.example (commit this)
DATABASE_URL=postgres://user:pass@localhost:5432/db
REDIS_URL=redis://localhost:6379
CLAUDE_API_KEY=
STRIPE_SECRET_KEY=

Add .env to your .gitignore. Seriously — check it's there. Leaked API keys from git are the #1 way dev teams lose money.

Loading .env into your runtime

• Node: dotenv package, or Node 20+ has --env-file=.env built in.
• Python: python-dotenv or Pydantic's BaseSettings.
• Rails: dotenv-rails in the Gemfile.
• Go: github.com/joho/godotenv in the init().
• Next.js / Vite: native support — files named .env.local are picked up automatically.

Secrets for production

Never deploy your dev .env to prod. Production secrets live in the platform's own secret store (Vercel env vars, Fly.io fly secrets set, Railway variables, heroku config:set, or your cloud's secret manager). The web platforms setup guide walks through each.

Common stacks end-to-end

npx create-next-app@latest myapp --typescript --tailwind --app
cd myapp
npm i -D prisma && npx prisma init --datasource-provider postgresql
# edit prisma/schema.prisma, then:
npx prisma migrate dev --name init
npm run dev   # http://localhost:3000

mkdir api && cd api && npm init -y
npm i express pg drizzle-orm && npm i -D tsx drizzle-kit typescript
# create src/db.ts, src/schema.ts
npx drizzle-kit generate && npx drizzle-kit migrate
npx tsx src/server.ts

python -m venv .venv && . .venv/bin/activate
pip install fastapi uvicorn sqlalchemy alembic psycopg[binary] python-dotenv
alembic init alembic    # configure alembic.ini → sqlalchemy.url from env
alembic revision --autogenerate -m "init"
alembic upgrade head
uvicorn app.main:app --reload

gem install rails
rails new myapp --database=postgresql
cd myapp
bundle install
rails db:create db:migrate
rails server   # http://localhost:3000

go mod init github.com/you/myapp
go get github.com/jackc/pgx/v5 github.com/sqlc-dev/sqlc
# write db/queries/*.sql, run: sqlc generate
go run .

How LingCode accelerates the above

You can do all of this in any editor. LingCode earns its keep during the small, repetitive, tedious parts that break concentration:

• Boilerplate. "Generate a Prisma schema for a blog with Users, Posts, and Comments" in chat — you get a usable starting point in 10 seconds.
• Migrations. Select a schema change, run /review — Claude flags missing indexes, bad null defaults, and forgotten updated_at triggers before they become a rollback.
• Error hunting. Paste a Postgres error message into chat — LingCode has your schema as context, and will usually point at the exact migration that caused it.
• Docker recipes. "docker-compose.yml for Postgres 16 + Redis + pgAdmin" — saves trips to Google and Stack Overflow.
• Seed data. "Generate 50 realistic seed users for Prisma" — better than name: 'User 1'; name: 'User 2';.
• Slash commands. /explain, /optimize, /refactor, /fix, /review all work on selected code — the full list is at the Skills guide.
• Multiple sessions. Start a long-running migration in one Claude Session, keep iterating on your schema in another. They don't step on each other.
• Terminal integration. Cmd+J opens a terminal in your project dir. Output from builds, tests, and docker compose logs is visible alongside your code without alt-tabbing to Terminal.app.

Before you ship

Four checks worth running once the local stack is green:

1. Secrets not in git. git ls-files | grep -i '\.env$' should return nothing.
2. Migrations idempotent. Drop and recreate the dev DB, run migrations from scratch — it should succeed.
3. Tests pass. Run them once in Release / production mode, not just dev — catches #if DEBUG divergences before they bite you in deploy.
4. Env var list complete. Diff your .env against .env.example; update the example so teammates and CI aren't missing keys.

Then read the deploy hub and pick your target.