Setting Up: From Zero to Building in 30 Minutes

Why Environment Comes First

Most developers start a new project by writing code. We start by building the ground it stands on.

Before a single component is created, before a design token is defined, before an agent is born — the local environment has to be airtight. Not "good enough." Airtight. Because every shortcut you take in setup becomes a bug you chase in production.

This is Step 1 of the Context-First methodology: Local Environment. And it's the most underrated step in the entire system.

The Service Inventory

The first thing we do on any project isn't npm init. It's a service inventory — a complete audit of every external platform the project will touch.

For eComX, that inventory looks like this:

• Hosting: Vercel (deployment, edge functions, cron jobs)
• Database: Supabase (PostgreSQL, Auth, RLS, Edge Functions)
• Payments: Stripe (products, checkout, webhooks)
• Email: Resend (transactional, sequences, audiences)
• DNS: Cloudflare (domain, SSL, caching)
• Analytics: GA4 (measurement, streams)
• Advertising: Meta Business (pixel, CAPI, audiences)
• Design: Figma (wireframes, components)
• Version Control: GitHub (repository, CI/CD)
• Tunneling: ngrok (webhook testing in development)

Ten platforms. Each needs credentials. Each has its own authentication model — API keys, OAuth tokens, webhook secrets, service accounts. Miss one, and you're debugging authentication errors three weeks later when you're supposed to be shipping features.

Credential Acquisition

We don't just grab one API key per platform. We map every credential we'll need across the project lifecycle.

For Stripe alone, that's:

• Secret key (server-side API calls)
• Publishable key (client-side checkout)
• Webhook secret (signature verification)
• 11 price IDs (one per product in the ladder)

Multiply that across 10 platforms and you're managing 40+ credentials before writing a line of application code. This is why amateurs get hacked and professionals don't — the difference is a credential management system versus a sticky note.

The Keychain Protocol

Every credential goes into the macOS Keychain — never in plaintext files, never in Notion, never in a Slack message to yourself. We use a structured naming convention:

[PROJECT]-[PLATFORM]-[KEY_TYPE]
ecomx-stripe-secret-key
ecomx-supabase-service-role
ecomx-resend-api-key

From Keychain, credentials are written to .env files that are always in .gitignore. The .env.example file in the repo contains only placeholder values — your_stripe_secret_key_here — so any developer can see what's needed without seeing what's real.

This isn't paranoia. It's hygiene. One leaked Stripe key costs more than the entire project budget.

MCP Configuration

The Model Context Protocol (MCP) is how AI agents get access to tools during development. Our workspace MCP config wires up:

• File system access — read/write to project directories
• Browser tools — Playwright for testing and screenshots
• Terminal access — run commands, check build status
• Database tools — query Supabase directly from the AI context

This means when an AI agent is working on the project, it doesn't just see code — it can run it, test it, and verify it against the live database. The MCP layer turns a language model into a development environment.

The .agent/ Directory

Every project gets a .agent/ directory at the root. This is the project's operational nervous system:

.agent/
├── workflows/          # 18 development workflows
├── skills/             # Domain-specific skill modules
├── context.md          # Project context loader
└── README.md           # Workflow index

The workflows define how we plan, research, execute, and verify every piece of work. They're not documentation — they're executable instructions that the AI follows step by step. When I type /execute-phase 4, the agent reads the workflow, finds the phase directory, loads the plans, and begins executing them in order.

Multi-Project Workspace Management

I run 7 projects simultaneously. Each has its own .env, its own .agent/, its own credential set. The workspace structure is flat:

dynasty_projects/
├── ecomx/              # This site
├── ariaos/             # Multi-tenant AI platform
├── celtic-knot-com/    # Irish DTC jewelry
├── infiniteawakening/  # Spiritual wellness
├── genesis-witness/    # Scientific research
├── emmalish/           # Gamified SaaS
└── kohwork/            # Thai marketplace

Each project is self-contained. No shared credentials. No cross-project dependencies. If one project's Stripe key rotates, nothing else breaks. This isolation isn't accidental — it's the same principle as the BIOS constraint architecture applied to development infrastructure.

The 30-Minute Promise

With the /setup-environment workflow, going from empty directory to production-ready workspace takes under 30 minutes:

1. Minutes 0-5: Run service inventory, identify all platforms
2. Minutes 5-15: Acquire credentials from each platform dashboard
3. Minutes 15-20: Store in Keychain, generate .env from .env.example
4. Minutes 20-25: Configure MCP servers, verify tool access
5. Minutes 25-30: Run health checks — database connection, email delivery, payment gateway

If any health check fails, we fix it before writing a single line of application code. The environment is the foundation. If the foundation cracks, everything built on it is suspect.

Why This Matters

I've seen teams spend three days debugging a webhook that fails because their ngrok tunnel expired. I've seen production deployments crash because someone hardcoded a test Stripe key. I've seen an entire sprint wasted because the Supabase service role key was the anon key.

Every one of those failures happened because environment setup was treated as a chore instead of a discipline.

In Context-First development, Step 1 isn't glamorous. It's not the AI agent emergence or the 620% ROI case study. But without it, none of those things happen. The environment is the ground truth. Everything else is built on trust that the ground is solid.