AI in practice · Mirko Olindo

the stack

Eighteen tools. Every one of them made something.

// flip a card to see what

build

Claude Code109 guides

build

Cursorshipped front-end

build

Codexreal react

context

MCP3 servers

pipeline

CC skillsthe guide skill

flow

n8n3 workflows

context

RAGanswers from the db

data

Apifymarket + competitors

flow

Webhooksstripe events

product

Next.jspraticheeasy

product

Reactprototypes that run

product

Postgresplans at the db

payments

Stripecheckout + webhooks

design

Figma100+ and 200+

craft

Illustrator94 marks

craft

Blender3d, in the toolkit

flow

Notiona scheduling trigger

flow

Telegrama command, a meeting

// flip a card for what it made. the full proof, tool by tool, is in the stack further down.

01Working method

I design the thing, then I direct the build.

I design the interface and the data model first. Then I sit inside Claude Code, Cursor and Codex and direct the model to build them in real React and Next.js. My time goes into reviewing and steering working code, not into handing a Figma file to someone else and waiting for it to come back wrong.

On NovaVista this changed how the design conversation works. I bring a running prototype to the engineering team instead of a static mockup, which turns a two-week alignment loop into a two-day one. On PraticheEasy it went further. I shipped the whole thing.

PraticheEasy home, live in production. Search Italian procedures in plain language and browse by category. — // live in production · designed, built and shipped solo in about seven weeks

What I own

The intent, the model, the correctness

Product shape, information architecture, the data model, every interface decision. And the final read on whether the output is actually right, which is the part the model is worst at.

What the AI owns

Volume, speed, the unglamorous parts

Implementation and repetition at scale. On PraticheEasy that meant database migrations, row-level security enforcing free and paid plans at the database rather than only in the UI, Stripe checkout and webhooks, and the scheduled jobs that actually send the reminder emails.

The AI owns volume and speed. I own correctness.

02Conversational assistants

The interesting part is what happens when the model doesn't know.

Anyone can put a chat box on a product. The design work is everything around the confident answer: what the assistant is allowed to talk about, what it is grounded on, and where a person ends up when the model is not reliable.

On NovaVista I took an assistant to production: conversation flows, prompt and context design, error and uncertainty states, with an explicit exit to a human operator when confidence drops. On PraticheEasy I designed the scope and grounded the assistant on 109 verified guides. Same problem, two different escape hatches.

Design decision

Confidence is a state, not a footnote

The interface changes shape depending on how sure the system is, and the user is told which one they are in.

confident

Direct answerShort, in plain language, grounded on a verified source rather than on general web knowledge.
Traceable sourceThe answer points back to the guide or the listing it came from, so the user can check it.
Ends in the productBook, save a deadline, open the guide. The conversation is a route, not a destination.

not reliable

Say soThe assistant admits the gap instead of filling it. On a bureaucratic domain a wrong answer costs someone a day in an office.
PraticheEasy: back to the verified guideThe user lands on the human-reviewed source instead of an invented answer.
NovaVista: out to a humanAn explicit handover to an operator, designed as a normal path with the context carried over, not as an error screen.

// the uncertainty model, drawn as a pattern. not a product screenshot.

Behind that behaviour there is a boring, mechanical question: what exactly goes into the model before it answers. This is the context assembly on PraticheEasy, where every source is public and you can go and check it.

context assembly · praticheeasy assistantper turn

// the violet path is the one that does the work. no grounded context, no answer worth trusting.

I chose admitting uncertainty over conversational fluency. It reads worse in a demo and works better in production.

alongside it · novavista

An AI matching flow between users and practitioners

Designed together with the people building the model. The design questions were never about the algorithm: what do we show, what do we deliberately hide, and how does the result get explained to the person reading it. A recommendation nobody understands is a recommendation nobody books.

alongside it · praticheeasy

Public, linkable, testable right now

The PraticheEasy assistant is live. You can open it, push it off-topic, and watch it fall back to the verified guide instead of guessing. That is the whole point of building in public.

The NovaVista marketplace: 47 services, filterable, with the find your match entry point at the top. — // the surface the matching flow opens from. "trova il tuo match", top centre, next to plain browsing. the AI is one route in, never the only one.

A NovaVista service detail page with packages, price, what is included and reviews. — // where a recommendation has to land. price, packages, what is included, reviews. explaining the match is pointless if this page cannot back it up.

03AI that runs the company

Most AI in a design portfolio stops at the feature. At NovaVista there is a second layer.

This one is not in the product. It sits behind it, and it keeps a small team running a two-sided marketplace across three surfaces. We built it in n8n, and I designed what it says, when it fires and who it is talking to. Two of the three workflows funnel many signals into one action. The third does the opposite.

workflow 01 · lifecycle email

Personal because of the data, not the merge tag

Sending is triggered by what a person actually did on the platform. The content is then assembled from three sources: their stated preferences, the kind of service or practitioner they were browsing, and what they have bought before.

The email arrives about a thing they were already looking at. Not a template with a first name in it.

workflow · lifecycle-emailn8n

// workflow diagram, not a screenshot of the canvas. the personalisation is the three inputs on the left.

workflow 02 · scheduling

The calendar fills itself from our conversations

Agendas and internal meetings get booked by a workflow that reads our internal chats and takes commands we send from WhatsApp, Telegram or Notion.

The design decision was the surface. We schedule from where we already are, not from a tool someone has to remember to open.

workflow · schedulingn8n

// the design decision is the left column. we schedule from the surfaces we are already on.

workflow 03 · analytics

Three readers, three different outputs

Data collection and reading run through AI, and land in three places on purpose. An alert when a number moves. A dashboard the team watches. And the reports our investors read.

Same pipeline underneath, three formats, because a founder scanning a phone and an investor reading a quarterly need very different things.

workflow · analyticsn8n + ai

// the only workflow of the three that fans out. same data, three audiences, three shapes.

This is the part that surprises people in interviews, and it is why it gets its own page. It is evidence of something a portfolio of screens cannot show: I can look at how a business actually operates and automate the parts that were eating the team's week.

04Pipelines, not prompts

109 guides is not something a designer writes by hand.

The instinct with a content problem this size is to prompt harder. I did the opposite. I designed the shape of the output first, then built a small machine that fills it. Every guide is structured data, which is also why the JSON-LD Google needs comes out for free, in five languages.

guide.schema · the shape I designed once

{
  "slug":         "pagare-f24",
  "intro":        "one short paragraph, plain language",
  "requirements": [ "what you need before you start" ],
  "steps":        [ { "n": 1, "title": "...", "detail": "..." } ],
  "faq":          [ { "q": "...", "a": "..." } ],
  "office":       { "name": "...", "phone": "...", "pec": "..." },  // a real office, not a link
  "related":      [ "slugs" ],
  "locales":      [ "it", "en", "ro", "es", "fr" ]
}

// design the shape once, the pipeline fills it 109 times, i review all 109

input

Raw bureaucratic source

Government pages, forms, circulars. Fragmented, jargon-heavy, often contradictory.

sourced

step 01

A content schema

The shape above. What a guide always contains, and in what order.

my design

step 02

A repeatable Claude Code skill

Built to turn raw information into a guide in that exact shape, every time.

my design

step 03

109 guides, 5 languages

Volume the model handles well, plus the JSON-LD that comes free from structure.

ai output

step 04

I review every one

One deadline template calculated a licence renewal from the expiry date instead of the last renewal. Wrong for every single user. I caught it.

my review

The PraticheEasy guide library, the output of the content pipeline: 109 guides, same structure every time. — // the pipeline output, live. same shape every time, because it is structured data.

The deadline reminder engine that the gamified journeys write into. — // completing a journey step writes a real deadline into the reminder engine

I didn't use AI to produce output. I designed a small pipeline with it, then stayed the editor.

05Setup

MCP, so the model reads real things.

A model working from memory invents plausible answers. Most of the failure modes people blame on AI are really a context problem. I run my tooling over MCP so the model queries actual sources instead of guessing at them. Claude Code, Cursor and Codex all sit on the same set of servers.

my daily setup

  model
    │
    ├── design-system   →  real components + tokens   // stop reinventing the button
    ├── product-db      →  rag over production data  // answer from the db, not from memory
    └── apify           →  market · competitors · news

// the gain is not speed. it is that the answer is grounded in something i can check.

topology · what sits behind each servermcp

// green column on the right is the point. every claim the model makes can be traced to something that actually exists.

design-system

Exposes the real components and tokens, so generated interface uses what already exists instead of reinventing a button. The design system stops being a document nobody opens.

product-db · rag

Retrieval over the product data, so a question about what is actually happening gets answered from the database rather than from a guess.

apify

Market research, competitor data and news, pulled in structured form. It turns "what is the market doing" from a two-day desk exercise into a query.

why it matters here

Grounding is a design problem before it is an engineering one. The same instinct that puts an MCP server between a model and the truth is the one that puts a verified guide behind an uncertain answer.

One small proof that this is a practice and not a slide: the icons on this page come from my own set, and four of them exist only because of this work. No library has an icon for a model admitting it is unsure, or for the handover from an assistant to a human. I had to draw them. See the icon system →

06The stack

Every tool here, and the thing it actually made.

A list of logos proves nothing. So this one is paired: on the left the tool, on the right what came out of it. Nothing on this page is here because it looks good in a slide.

Claude Code

build partner

→

109 guides, in 5 languages

Produced by a repeatable skill I designed against a content schema. I reviewed all 109 for accuracy.

Cursor · Codex

in-editor build

→

Front-end shipped in real React and Next.js

On NovaVista it turns a two-week alignment loop with engineering into a two-day one, because I bring a running prototype.

MCP

context, grounded

→

3 servers wired to real sources

The design system, RAG over the product database, and Apify for market and competitor data. The model queries, it does not guess.

n8n

process automation

→

3 workflows running a company

Lifecycle email off real behaviour, meeting scheduling from our own chats, and analytics split into alerts, a dashboard and investor reporting.

Postgres · RLS

the unglamorous part

→

Free and paid plans enforced at the database

Row-level security, not a check in the interface. A designer usually never touches this. That is the point.

Stripe

payments

→

Checkout and webhooks, shipped solo

Together with the scheduled jobs that actually send the reminder emails. PraticheEasy took money from day one.

Figma

design systems

→

Two systems from zero: 100+ and 200+ components

YELDO and NovaVista, including the icon sets and the visual language behind them. The third one lives in code instead, 57 components in production.

also in the toolkit

Claude Code skillsRAGJSON-LDScheduled jobsWebhooksTelegram · WhatsApp · Notion triggersIllustratorBlenderComfyUI

I don't use AI to draw faster. I use it to ship, and to run things.

Eighteen tools. Every one of them made something.

I design the thing, then I direct the build.

The intent, the model, the correctness

Volume, speed, the unglamorous parts

The interesting part is what happens when the model doesn't know.

An AI matching flow between users and practitioners

Public, linkable, testable right now

Most AI in a design portfolio stops at the feature. At NovaVista there is a second layer.

Personal because of the data, not the merge tag

The calendar fills itself from our conversations

Three readers, three different outputs

109 guides is not something a designer writes by hand.

Raw bureaucratic source

A content schema

A repeatable Claude Code skill

109 guides, 5 languages

I review every one

MCP, so the model reads real things.

design-system

product-db · rag

apify

why it matters here

Every tool here, and the thing it actually made.

The two case studies where all of this lives.

NovaVista

PraticheEasy

see it working

praticheeasy.it