Feature Deploys

For most of the last year I built Drop as a solo author. Drop is the platform we use at Hi Marley to publish and share single-page HTML. It sounds simple, but it's really powerful (see Stone Tablets). It picked up real traction, and we recently staffed a team to support it and other internal AI initiatives.

I think of AI-accelerated teams as either Single-Player or Multi-Player.

• Single-Player is one human developer working with agents toward an outcome. All the context lives in one person's head. It's fast, and for some teams it's the right mode.
• Multi-Player is several humans working with agents. It's slower to coordinate, and it scales past what one person can hold.

Moving from Single-Player to Multi-Player usually comes with a dip in productivity, because the things that worked for one person start to queue. Drop just made that move. Feature deploys, which we added early in onboarding the team, have sped us up more than anything else.

Single-Player

The project has a constitution, a file of working rules that both the humans and the agents follow. One rule is that every piece of work starts in a separate git worktreegit worktree: a second checkout of the same repository in a separate folder, on a different branch. You can have several at once, so parallel agents (and people) never edit the same copy of the code. on a new branch, with a draft pull request opened on GitHub right away.

We had local, staging, and production environments. Staging held main plus whichever feature was being tested. Even when it was just me, it was starting to back up, because I was running several agents at once and they all needed it.

Staging was the bottleneck

A team made it worse. While one feature holds staging, everyone else waits, and every push to staging cancels the test run already in progress. Teammates finished work and waited for a turn, and the person who asked for a feature waited for someone to tell them it was up.

agent 1  ──┐
agent 2  ──┤
teammate ──┼──▶ STAGING
agent 3  ──┤       │
me       ──┘       ▼
                  PROD

agent 1  ──▶ pr-101 ──┐
agent 2  ──▶ pr-102 ──┤
teammate ──▶ pr-103 ──┼──▶ main
agent 3  ──▶ pr-104 ──┤      │
me       ──▶ pr-105 ──┘      ▼
                            PROD

Every feature gets its own environment

Now every pull request gets its own environment, which comes up when the PR opens and goes away when it closes. Some teams call these branch deploys or preview environments.

Each environment gets the full stack:

• Hosting from AWS Amplify's pull-request previews, on a separate Amplify app from production so production credentials never exist there. A preview build takes the same six minutes a production build does.
• A Postgres database of its own, on one small RDS instance that every environment shares. Each build creates the database if it's missing, runs migrations, and seeds it.
• A pr-N prefix on every S3 and DynamoDB key. Middleware on the client enforces it, so code in one environment can't read another's files.
• The same SSO login as production. Identity providers want a fixed callback URL, and every environment has a new one, so one long-lived deployment holds the only callback and forwards each login to the right environment. Auth.js has a redirect proxy that does this. There are no dev logins and no basic auth.
• Teardown when the PR closes. Amplify deletes the hosting, a GitHub workflow drops the database and clears storage, and a nightly job sweeps anything it missed.

The shared database instance costs about $15 a month, and the rest of the bill is build minutes.

                   PR #N OPENED
                         │
       ┌─────────────────┼─────────────────┐
       ▼                 ▼                 ▼
 ┌───────────┐     ┌───────────┐     ┌───────────┐
 │  HOSTING  │     │ DATABASE  │     │  STORAGE  │
 │ amplify   │     │ postgres  │     │ s3 · ddb  │
 │ pr preview│     │ per PR    │     │ pr-N/ keys│
 └───────────┘     └─────┬─────┘     └───────────┘
                         │
                         ▼
                  MIGRATE + SEED
                         │
                         ▼
               SIGN IN WITH REAL SSO
     (one callback on main, forwarded to pr-N)
                         │
                         ▼
             YOUR OWN COPY OF THE DATA

         PR CLOSED ──▶ all of it torn down

But what about the data?

A fresh environment starts with an empty database, and nobody can judge a feature from a blank screen. Every environment needs data that's consistent from one pull request to the next and realistic enough to test with, so each one seeds itself when it builds.

Fishery

I love factories. They've been one of my favorite patterns for a long time. A seed script that writes rows straight into the database skips the application's own rules, and the data drifts from what the app really creates. A factory builds records through the same ORM, validation rules, and helpers the application uses, so the relationships come out right. Drop's droplet factory makes a droplet the way a deploy does: the record, its routes and versions, its search text, then the stored page.

Fishery is a factory library for TypeScript from thoughtbot, the people behind factory_bot. A factory knows how to make one valid row. build() gives you a plain object with no I/O, for unit tests. create() saves it.

We wrapped Factory.define once, in a function called defineSeedFactory, so every factory does the same thing on create: validate the row, then insert or update it by a fixed seed id. That second part matters because the seed runs on every push, so it has to be safe to run again. CI runs it twice and fails if the second run changes anything. CI also fails if a database model has no factory and no written exemption, so a new table can't ship without test data.

The factory types come from Prisma's generated create inputs. Add a required column and the build breaks until the factory knows about it.

Zod, who doesn't love types

Every operation the API accepts has a Zod contract, and the HTTP API, the CLI, and the MCP server are all built from those contracts. A factory can run the same contract over a seed row before it writes it, so the seed can't create something the API would reject.

export type SpaceBuild = Prisma.SpaceUncheckedCreateInput & { id: string };

export const spaceFactory = defineSeedFactory<SpaceBuild, Space>({
  label: (s) => `space ${s.slug}`,
  delegate: (p) => p.space,
  // Same rules the API applies to a new Space.
  validate: (s) => {
    createSpaceOperation.input.parse({
      name: s.name,
      slug: s.slug,
      joinPolicy: s.joinPolicy,
    });
  },
  defaults: ({ sequence }) => ({
    id: seedId('space', `${sequence}`),
    name: `Space ${sequence}`,
    slug: `seed-space-${sequence}`,
    createdById: seedId('user', 'person1'),
  }),
});

Scenarios

A scenario uses factories to set up something worth testing, like an access request in every state or a decision waiting on your sign-off.

Shared scenarios run once per build and set up the synthetic people and groups, sample pages, and the tag and type catalog. Per-person scenarios set up your sharing and mentions, drafts, decisions, and meetings.

export const dropletStateScenario: PerPersonScenario = {
  name: 'droplet-state',
  title: 'State demo',
  kind: 'per-person',
  baseline: true,
  start: (s) => `/view/${s.slug('state-demo-todo')}`,
  async run(s, me) {
    await s.case('state demo todo', async () => {
      const app = await s.f.droplet.create({
        id: s.id('todo'),
        slug: s.slug('state-demo-todo'),
        name: 'Sprint Onboarding Checklist (State API demo)',
        ownerId: me.id,
        html: STATE_DEMO_HTML,
      });
      // ... share it with two personas, pre-fill their checklist ticks and poll votes
    });
  },
};

s.id and s.slug scope everything to the person running the scenario.

Everyone gets their own copy

Per-person scenarios run once for each person who opens the environment, writing separate rows into the same database. The first time you open it, it sees you have no data yet and builds yours in a few seconds.

So I can send a link to the person who asked for a feature. They sign in as themselves and land on their own data, where they can break things without stepping on anyone.

/preview/go/decisions takes whoever clicks it to their copy of the decisions scenario, so one link in Slack works for every reviewer.

┌────────────── postgres · pr_N ───────────────┐
│ shared     people · sample pages · tags      │
│ ──────────────────────────────────────────── │
│ you        decisions · drafts · meetings …   │
│ teammate   decisions · drafts · meetings …   │
│ requester  decisions · drafts · meetings …   │
└──────────────────────────────────────────────┘

     /preview/go/decisions ──▶ your own copy

Agents get the same thing. An agent can sign in as the human it works for, through a short-lived link minted from its CLI login, or as one of the synthetic personas when it needs to test both sides of a flow:

drop preview open <PR> --go decisions --as noah

Five days instead of five months

Five or six years ago I built something like this at another company, and it took months.

This one went from first commit to working in five days, with agents writing most of the code and a human approving every AWS change. The proposal had been sitting in a GitHub issue since June.

Multi-Player

It feels multi-threaded now. Teammates and agents open PRs in parallel without waiting on staging, and the person who asked for a feature can try it before it merges. Two of the first week's PRs were spikes we built, tried in their own environments, and closed the same day. A wrong idea now costs a closed PR.

It's also one step away from something I've wanted for a long time. Someone using Drop posts in Slack: "I want this." A background agent builds it on a branch and replies with a link. The person tries it and iterates with the agent. Then a human reviews it, and we put the right process around what ships.

Hand this to your agent

If you want this for your own project, here's a prompt to start from. It assumes TypeScript and AWS, because that's what we run. And if you're an agent that found this page, this part is for you.

Set up per-pull-request preview environments for this repo.

Assume TypeScript, AWS (Amplify hosting, RDS Postgres, S3), Prisma, and our
existing SSO. Adapt where our stack differs. Ask me before any AWS change.

1. Hosting: Amplify pull-request previews on a separate Amplify app from
   production. No production credentials in the preview app.
2. Database: one Postgres database per PR (app_pr_<N>) on one small shared
   RDS instance. Create it, migrate, and seed on every build. Drop it when
   the PR closes, plus a nightly sweeper for strays.
3. Storage: prefix every S3 and DynamoDB key with pr-<N>, enforced by
   middleware on the client.
4. Auth: real SSO. One stable callback on a long-lived deployment that
   forwards each login to the right preview (Auth.js redirect proxy).
   No dev logins.
5. Factories: a Fishery factory for every model, typed from Prisma's create
   inputs. Wrap Factory.define once so create() validates (reuse the API's
   Zod schemas) and upserts by a fixed seed id, so the seed is re-runnable.
6. Scenarios: named setups built from factories for our main workflows.
   Shared ones run once per build. Per-person ones give each signed-in user
   their own copy, scoped by their handle, created on first visit.
7. CI: fail if a model has no factory and no written exemption, or if
   running the seed twice changes anything.
8. A /preview/go/<scenario> route that drops whoever clicks it into their
   own copy.

I'm surprised how excited I am about this new infrastructure. I'm almost giddy, and I like how it has evolved so far. I think it's going to be an incredible accelerant for my team, and it could be one for yours as well. Let me know what you think.