# How we work: the Noord stack

The people, tools, and handoffs behind our projects—from the first conversation to a working system.

**TL;DR**

We turn conversations into briefs, make something a partner can try, and use their feedback to improve it. AI helps with the making; people still make the decisions. Start with one useful loop before collecting another twelve tools.

At Noord, we use AI to help us do more of the work ourselves. We can move from a conversation to something a partner can try, make changes while the questions are still fresh, and spend more time looking at whether the result is any good.

The methods in Polder come from work we have done over time with partners and on our own projects. This page shows how the tools fit around that work. You may need only a notebook for the first meeting and a shared page for the next review. Add the rest when you have a reason.

## From a conversation to a working system

Follow a piece of work through the diagram: a conversation becomes a brief, the brief becomes something to look at, and the review changes what gets made next. Expect to go around that middle part more than once.

1. Listen: People describe the real work. We ask, observe, and keep disagreements visible.
   Tools: Paper, Notion AI Meeting Notes
   Carry forward: Source notes. A conversation, a board, a transcript—with permission.

2. Decide: We agree on the problem, the constraints, and what a useful result must do.
   Tools: ChatGPT, Claude, a shared document
   Carry forward: Reviewed brief. Evidence, decisions, open questions, and an owner.

3. Explore: We make different directions tangible, then choose with the partner.
   Tools: Figma, Gemini / Nano Banana, Midjourney, OpenAI image generation
   Carry forward: Selected direction. A few comparable ideas, shown with real content.

4. Make: We turn the approved direction into small, checkable implementation tasks.
   Tools: Grok, Claude, ChatGPT, Vlak, Next.js, GitHub
   Carry forward: Working version. Editable files, a tested interface, and visible changes.

5. Review: Partners see the actual iteration. We review comments and resolve the next decision.
   Tools: Studio, Vercel previews, Playwright
   Carry forward: Feedback + approval. Comments belong to a version. Approval is recorded separately.

6. Deliver: We verify the release, explain its use, and agree who looks after it.
   Tools: Studio, GitHub, Vercel, a versioned project folder
   Carry forward: A usable handoff. Approved files, source access, usage notes, and ownership.

Feedback returns to the working version—or to the brief when the decision changes. Only reviewed, approved work moves into delivery.

The connections show the flow of work and information, not automatic integrations or permission to publish.

## The shared foundation

These tools have different jobs. The chat helps us think and make; the project files hold the work; Studio gives the partner somewhere to see it and respond. Keep the decisions with the files so they survive the conversation.

| Layer | What we use | How it connects |
| --- | --- | --- |
| Thinking and planning | ChatGPT Astra, Claude Fable, and Grok | Turn a reviewed brief into options, plans, and bounded tasks. Keep decisions in the project files, not only in a chat. |
| Design and visual work | Figma and Vlak; image models when needed | Explore with real content, then carry approved layout, type, color, and component decisions into the implementation. |
| Web interfaces | Next.js, React, TypeScript, CSS tokens, and Tailwind CSS where useful | Keep content and data structured; build reusable interfaces with a small client-side layer for interaction. |
| Code and previews | GitHub and Vercel | Review versioned changes and test a preview before release. Link the selected iteration from the partner project page. |
| Application data | PostgreSQL on Neon, with Drizzle ORM | Store project records and structured state in the application. Read and write through reviewed code with appropriate access. |
| Partner collaboration | Studio project pages | Bring the brief, explorations, working versions, feedback, and delivery together. Keep private project material behind the right access controls. |
| Operational outputs | Resend, react-pdf, and html2pdf | Send authorized transactional messages and produce portable documents from the approved project data. |

## Use the stack the project needs

Some projects need a publishing tool, a store, or a native app. Choose the part that fits the people who will use and maintain it.

- Sanity when a team needs a managed content model; Framer when the marketing team needs to maintain a site in its own editing environment.

- Shopify for commerce, with Hydrogen when we need a headless storefront. Stripe where the product needs payments.

- Swift and SwiftUI for Apple-platform apps. Keep the product's behavior native to the platform rather than reproducing a website inside a wrapper.

- Style Dictionary for token transformations where needed; Three.js only when a spatial or interactive surface serves the task.

- Notion or a shared document for portable notes, and consented recording or transcription during sessions. These support the process; they do not replace the person listening.

## Choose models by stage

We use ChatGPT Astra and Claude Fable for developing the direction and constructing a plan. Astra is our preference for open-ended, zero-to-one exploration; Grok has worked best for us when executing a clear plan developed with ChatGPT or Claude. These are observations from our work, not a universal ranking.

For images, our order is the latest Gemini / Nano Banana models, then Midjourney, then the latest OpenAI image model. Earlier OpenAI image models are not part of that recommendation. Keep the actual model version with the source image and prompt.

Once the direction is approved, give routine jobs to a lower-cost agent or a script. Supply a small task, the relevant sources, and a checkable output. Lower cost per token and lower total token use are different things; judge the complete result, including retries and review time.

[Model choices and image-generation preferences](https://noord.dev/polder/choosing-design-models#image-generation)

[Sequence prompts, then delegate](https://noord.dev/polder/delegating-with-prompts)

## Show the work, then ask a useful question

Studio is where our partners see the work. We make and revise it with Claude, ChatGPT, or Grok, check the files and preview, and put the selected version on the project page. The assistant needs access to the relevant files to help with that; a chat account alone does not connect it to Studio.

Give the partner something specific to respond to. ‘Does this make the main action clear?’ is easier to answer than ‘Thoughts?’ Keep their comments beside the version they saw. If two comments ask for opposite changes, talk about the choice before sending both to an agent.

The core project stages are Proposal, Exploration, Execution, and Delivery. An in-person workshop can precede the Exploration work. Publishing a draft makes it available for review; it does not mean the partner has approved it.

## Keep a handoff smaller than the conversation

The next person rarely needs the whole conversation. They need to know what was decided, why, and what is still open. Keep that short record beside the work, with links back to the original notes for anyone allowed to read them.

```text
Project and version: [name / version]
Problem: [the person's actual task]
Evidence: [source IDs and permitted file locations]
Approved decisions: [choice / reason / owner / date]
Direction: [selected preview or design file]
Next task: [one outcome and the files allowed to change]
Acceptance checks: [observable checks]
Still unresolved: [question / decision owner]
Partner review: [version / question / feedback location]
Release approval: [separate from draft availability]
Handoff owner: [who maintains the result]
```

## Try one complete loop first

Try this on a small piece of a real project. Take it far enough that the partner can use it and tell you what is wrong. You will learn where the process needs help much sooner than you would by connecting every tool first.

Keep files versioned and recoverable. Use connectors or command-line tools only with the access needed for the task, and ask before new costs, external messages, or publishing. Someone should be able to continue the work if a model, account, or service changes.

[Run an exploration workshop](https://noord.dev/polder/workshop-exploration)

[Set up a project environment](https://noord.dev/polder/new-project-setup)

[Review the quality of a release](https://noord.dev/polder/qa-gate)

## Product documentation

- [Next.js documentation](https://nextjs.org/docs)

- [Vlak components and design system](https://vlak.dev)

- [Vercel preview deployments](https://vercel.com/docs/deployments/environments)

- [Drizzle ORM documentation](https://orm.drizzle.team/docs/overview)

Product documentation describes capabilities, not independent evidence for Noord’s preferences.

Source: https://noord.dev/polder/how-we-work

## Tools, in order

### In the conversation

[Notion](https://www.notion.com/) · [Notion AI Meeting Notes](https://www.notion.com/help/ai-meeting-notes) · Paper or a shared workshop board

Agree on capture, listen to the actual work, and record the decisions with the people responsible.

Carry forward: A checked brief with evidence and open questions.

### While exploring and making

[Claude](https://claude.ai/), [ChatGPT](https://chatgpt.com/), or [Grok](https://grok.com/) · [Figma](https://help.figma.com/hc/en-us/articles/15145852043927-Create-and-manage-variables) · [Vlak](https://vlak.dev) · A coding workspace with approved file access

Choose a direction together, then give bounded implementation tasks to the tools with appropriate access. Keep the actual files versioned.

Carry forward: A working iteration the partner can inspect.

### At review and delivery

[Browser and accessibility checks](https://www.w3.org/WAI/test-evaluate/preliminary/) · [Playwright](https://playwright.dev/docs/accessibility-testing) · A versioned project folder

Show the selected version in Studio, collect specific feedback, and verify the approved handoff separately from draft publication.

Carry forward: A useful release with decisions, source files, and an owner.

### Review the work with partners

We make and revise the work with Claude, ChatGPT, or Grok, then put selected versions on our Studio project pages for partners to review. Check the preview before sharing it. You can do the same with a private prototype or shared document; use a workspace that can access the files you need.

Name the version, say what changed, and ask the question you need answered. Keep feedback with that version and discuss conflicting requests before making the next changes. Confirm approval separately, and keep confidential work in a restricted space.

For this method: Can the partner follow the decisions from the original problem to the version being reviewed?

### Delegate the routine work

Format a checked brief or implement a small, approved change with explicit acceptance checks.

Keep with a person: Meaning, direction, access, partner approval, and the release decision remain with the responsible people.

[Sequence prompts, then delegate](https://noord.dev/polder/delegating-with-prompts)

[Choose a model for the design task](https://noord.dev/polder/choosing-design-models)