Reference · Working notes · Noord
How we work: the Noord stack
The people, tools, and handoffs behind our projects—from the first conversation to a working system.
Download this method as MarkdownHuman work, connected
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.
- Listen
People describe the real work. We ask, observe, and keep disagreements visible.
Source notesA conversation, a board, a transcript—with permission. - Decide
We agree on the problem, the constraints, and what a useful result must do.
Reviewed briefEvidence, decisions, open questions, and an owner. - Explore
We make different directions tangible, then choose with the partner.
Selected directionA few comparable ideas, shown with real content. - Make
We turn the approved direction into small, checkable implementation tasks.
Working versionEditable files, a tested interface, and visible changes. - Review
Partners see the actual iteration. We review comments and resolve the next decision.
Feedback + approvalComments belong to a version. Approval is recorded separately. - Deliver
We verify the release, explain its use, and agree who looks after it.
A usable handoffApproved files, source access, usage notes, and ownership.
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 | 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 | Image models when needed. | Explore with real content, then carry approved layout, type, color, and component decisions into the implementation. |
| Web interfaces |
| Keep content and data structured; build reusable interfaces with a small client-side layer for interaction. |
| Code and previews | Review versioned changes and test a preview before release. Link the selected iteration from the partner project page. | |
| Application data | Store project records and structured state in the application. Read and write through reviewed code with appropriate access. | |
| Partner collaboration | Bring the brief, explorations, working versions, feedback, and delivery together. Keep private project material behind the right access controls. | |
| Operational outputs | 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.
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.
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.
Tools, in order
Here is where each tool helps. Use an equivalent you already work with if it fits the task and your project’s access requirements.
In the conversation
NotionNotion AI Meeting NotesPaper 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
At review and delivery
Browser and accessibility checksPlaywrightA 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.
A question for this review
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.
Meaning, direction, access, partner approval, and the release decision remain with the responsible people.
Product documentation
Follow these links for the providers’ current instructions. They describe capabilities, not independent evidence for Noord’s model preferences.