Growing a human from DNA

Setting up the project

2 min readChapter 13 of 34By Bipin Singh

Let's prepare the ground for our first human. By the end of this chapter you'll have a CDK project, connected to your AWS account, with a structure that can grow into a whole society.

What you need

Tool	Why
An AWS account	The world our humans live in (use a sandbox account, not production)
Node.js (LTS, e.g. 22)	CDK and our Lambda code use TypeScript/JavaScript
AWS CLI v2	Credentials and handy commands
AWS CDK CLI	`npm install -g aws-cdk`
Git and an editor	DNA belongs in version control

Credentials

Prefer short-lived credentials:

aws configure sso          # sign in through IAM Identity Center (recommended)
aws sts get-caller-identity --profile your-profile   # check who you are
export AWS_PROFILE=your-profile

Create the project

mkdir cafe-sukoon && cd cafe-sukoon
cdk init app --language typescript

# runtime libraries used by our humans
npm install zod @aws-sdk/client-dynamodb @aws-sdk/lib-dynamodb @aws-sdk/client-eventbridge \
  @aws-lambda-powertools/logger @aws-lambda-powertools/metrics

# build and type helpers
npm install -D esbuild @types/aws-lambda

# one-time per account/Region
cdk bootstrap

esbuild lets CDK's NodejsFunction bundle each Lambda function locally (otherwise CDK falls back to Docker).

A home for every human

cdk init creates bin/ and lib/. We'll reshape it so each human lives in its own folder, with its brain code and its DNA side by side:

cafe-sukoon/
├── bin/
│   └── cafe.ts                  ← the app: which stacks exist, in which environment
├── infra/
│   ├── cafe-stack.ts            ← the society: shared world + all humans
│   └── shared/                  ← shared constructs (event bus, API front door)
├── services/
│   ├── waiter/
│   │   ├── src/
│   │   │   ├── senses/          ← Lambda handlers (API, events)
│   │   │   ├── skin/            ← schemas
│   │   │   ├── brain/           ← business logic
│   │   │   ├── memory/          ← DynamoDB adapters
│   │   │   └── voice/           ← event publishing
│   │   ├── infra/
│   │   │   └── waiter.ts        ← the Waiter's DNA (a CDK construct)
│   │   └── test/
│   ├── chef/
│   └── cashier/
├── cdk.json                     ← points CDK at bin/cafe.ts
└── package.json

Update cdk.json so the app entry runs bin/cafe.ts (e.g. "app": "npx ts-node --prefer-ts-exts bin/cafe.ts"), and adjust tsconfig.json includes if needed.

Tip

One repository with a folder per service (a monorepo) is the easiest way to start. Teams can still own their folders. When a human becomes big enough to need its own release cycle, it can move to its own repository — its DNA is already self-contained.

Environments: siblings with the same DNA

You'll grow the same society several times:

Environment	Purpose	Typical setup
`dev`	Experiments	Your own sandbox account; cheap settings
`staging`	Rehearsal	Same settings as prod, smaller scale
`prod`	Real customers	Separate account, strict permissions

Pass the environment name into the stack, and let it influence settings (for example, retention policies or lifestyle — see lifestyles).

Watch out

Use separate AWS accounts for production. An account is the strongest wall between siblings — a mistake in dev can't touch real customers.

Written by Bipin Singh

Senior Full-Stack Engineer · AI & AWS. I design and build serverless systems on AWS — and love explaining them simply.

Work with me