One of Go’s underappreciated strengths is how easy it is to structure a project with multiple build targets from the same codebase. Whether you're building a CLI tool, a server, or an AWS Lambda function, Go gives you the flexibility to share your core logic while targeting different runtimes with minimal friction.

The Power of cmd/

A common and clean pattern is to organize your project with a cmd/ directory that contains a subdirectory for each binary:

/cmd
  /cli
    main.go
  /server
    main.go
  /lambda
    main.go
/pkg
  ...shared logic...

Each main.go under cmd/ is its own entry point. You might use the same packages under /pkg for all of them, just wired up differently depending on what kind of environment or use case you're targeting.

Why This Matters

This pattern keeps your codebase DRY, modular, and maintainable. It also makes your build process clean and explicit:

go build -o bin/cli ./cmd/cli
go build -o bin/server ./cmd/server
GOOS=linux GOARCH=amd64 go build -o bin/lambda ./cmd/lambda

You can even write shared test suites for the logic in /pkg and know all three binaries are using the same trusted code.

Moving Forward

If you’re working on a Go project and you foresee multiple deployment targets—don’t fork the repo. Don’t duplicate logic. Instead, embrace this structure. It’ll save you time, reduce bugs, and scale beautifully as your project grows.

So go ahead: one codebase, many front doors. Just keep building.