Project studio I — design
- Write a one-page project blueprint covering user, task, data, platform split, and risks
- Defend the Dify/n8n/Postgres split from the cognition-plumbing-state rule
- Name 3 measurable success criteria before writing a single node
Students need time to turn concepts into a concrete build plan. Projects that skip design spend the build week flailing — and "we'll figure it out as we go" is the most expensive sentence in software.
- If you can't name your user and their one task in one sentence, what have you designed?
- What goes wrong if "success" is undefined until demo day?
A strong project begins with a sharp definition of user, task, data, success criteria, and failure modes. This week is about designing before building. Pick the platform(s) deliberately: cognition in Dify, plumbing in n8n, state in Postgres.
Three measurable success criteria means *numbers*: "answers questions in <5s on 90% of test inputs", not "is fast". If you can't measure it, you can't tell whether you succeeded.
A team designs a thesis-support assistant that compares related papers and generates structured reading notes — cognition (compare + summarize) → Dify; plumbing (scheduled fetch from inbox + write to Notion) → n8n.
▸ Use the instructor's finished build before you build yours feel what "done" looks like — then recreate it
Not loading? https://dify.32dots.de/chat/EI9fTJWWvopOea4S
- Internal project template
Produce a project blueprint (can be a document, can be an empty n8n canvas with labelled sticky-note nodes). Must include: - Problem + user - Data sources + sensitivity - Task shape (extraction / routing / grounding / review / generation) - Platform split (what's Dify, what's n8n, what's Postgres) - Success criteria (3 measurable) - Top 3 failure modes + mitigation
No execution required this weekSuggested placeholder layout: Trigger → [cognition boundary = Dify app via HTTP] → Storage → Output
The blueprint is about the *whole* system, not just the AI call — you must reason about triggers, external data, and storage. n8n's canvas forces you to name every piece of plumbing explicitly; Dify's canvas only shows the cognition slice. Design at the plumbing level first, cognition second.
- **Designing the UI first** — starting with "the user clicks here and sees…" skips the task definition. Define the task; the UI falls out.
- **Success = works** — "the workflow runs" is not a criterion. What does success look like for the user?
- **Invisible state** — if you haven't decided where data lives, it will end up in a Google Sheet or a prompt. Decide on purpose.
Why do projects fail when teams start with the interface instead of the task?
Write the final project card with problem, users, data, platform split, nodes/apps, risks, and MVP scope.
One-page project blueprint + a sticky-note n8n canvas showing end-to-end shape.
Of the three failure modes you listed, which one are you most tempted to ignore — and what would it cost you if it hit during the demo?