Is a monorepo worth it for a two-person team?

Short answer: usually yes for a small team that shares code, as long as you keep the tooling light. The pain you describe (versions drifting between repos) is exactly what a monorepo removes.

What you gain

• Atomic changes. One commit and one pull request can change the API, the types and the web app together, so they never disagree.
• No publish step for shared code. A shared types package is imported directly, rather than versioned, published and bumped in each consumer.
• One place for tooling. Lint config, TypeScript config, CI and issue tracking live together.
• Easier onboarding and search. One clone, one search.

What it costs

• CI gets slower as the repo grows unless you only build what changed.
• Tooling choices. You need a workspace manager (npm, pnpm or yarn workspaces) and optionally a task runner that caches builds.
• Access control is all or nothing. Not a problem for two people, but it matters if you later bring in contractors who should see only one part.
• Deploys need care. Each app should deploy independently from its own folder.

A light setup

repo/
  apps/web
  apps/api
  packages/types
package.json   # "workspaces": ["apps/*", "packages/*"]

Start with plain workspaces. Add a build-caching tool only when CI time hurts.

Pitfalls

• Sharing code with hidden coupling between apps. Keep package boundaries explicit.
• One giant shared utils package that everything depends on.
• Forgetting path filters in CI, so every change rebuilds everything.

If the repos truly share nothing, splitting them is fine. If they share types or logic, merge them.