You don’t need frontier models for everything: a prototype with Mistral AI

Persona Stress-Tester is a small prototype for testing service points. You describe a service, and it generates three personas, walks one of them through the service step by step, and gives you a friction report.

I connected it to a small model to see how the idea works on something simpler and cheaper. It runs on Mistral’s ministral-8b-latest on the free tier. For this job, that was enough.

Demo url: https://persona-stresstester.vercel.app/

Step 1: describe the service

A sentence or two is enough. You also choose a channel: digital, physical or hybrid. For this run I used a self-service kiosk for prescription pickup at a hospital pharmacy, on the physical channel.

Step 2: pick a persona

The app generates three personas. Each one has a goal, a built-in friction trait and a different tag, so you get three different ways for the service to fail.

In this run I got Malaika, 32, who needs an inhaler before the school bus arrives. Rafael, 68, wants to stop asking a granddaughter for lifts to the pharmacy. Priya, 24, is collecting a first prescription and hopes nobody notices.

I followed Rafael, whose friction trait was very specific: glasses that fog up near the kiosk screen.

Step 3: watch the simulation

The app breaks the service into touchpoints, 4 to 6 depending on the service. This run produced six, from approaching the kiosk to leaving with the prescription.

The persona then moves through them one at a time. The narration streams in first person, and when a step finishes it gets a friction level (none, low, medium or high) and a one sentence note on the cause. The first step came back high, and the note pointed at the unshielded screen and the lack of anti-fog measures.

Step 4: read the report

The report lists every touchpoint with its friction level and note. Rafael’s journey came out as high, high, high, low, high, low.

Below that, a short summary names the biggest friction point and the type of problem. Here it was the kiosk’s lack of anti-fog measures or visual accessibility, classified as a clarity problem. “Try a different persona” runs the same service again with someone else.

Why a small model is enough here

The output was good enough for this kind of early service design work. It gives you a starting point to react to, and that is the job.

The structure did the work, more than the model did. Nothing asks the model to “analyse this service”. Each call is a small task with a strict format:

• Exactly 3 personas, each with a different tag from a fixed list
• 4 to 6 short touchpoint labels
• 3 to 5 sentences of narration for a single touchpoint
• One friction level from a fixed scale, plus one sentence on the cause
• A 3 to 4 sentence summary that has to name one biggest friction point

The app also carries the memory. Each step gets a short recap of the earlier friction levels and notes, so frustration builds up across the journey. You can see it in the run: the step where Rafael collects the medication is low friction, but the note still mentions lingering frustration from the earlier steps. The model never has to hold the whole journey, because the code hands it the part it needs.

So the design decisions move out of the model and into the prompts, the schemas and the sequence of steps. That is useful to know before you pay for the biggest model available.

What this doesn’t show

I didn’t run this next to a frontier model, so this is not a claim that the output is equally good. The claim is smaller: for a task this structured, a small model was enough to make the prototype useful.

The small model also has visible rough edges. In this run:

• The summary contains a raw **clarity**, because the model added markdown the app doesn’t render
• The notes for steps 2, 3 and 5 use almost the same sentence
• Rafael collects the medication in step 4, but in step 5 the instructions ask him to confirm the contents before picking up

It is also a design demo, not research. The personas are generated, so they can point you to questions worth asking, but they don’t replace talking to real people.

One practical note: on Mistral’s free tier, prompts and outputs may be used for training by default, so don’t put anything confidential in a service description.

Tech stack

• Next.js with the App Router
• Tailwind CSS
• Mistral’s ministral-8b-latest with JSON schema output
• One environment variable, LLM_PROVIDER, to switch to Claude Haiku with forced tool calls
• Streamed narration for the simulation
• A daily token budget per provider
• No database and no login: everything lives in the session
• Deployed on Vercel

Possible next steps

• Let you respond to friction during the simulation and see how the persona reacts. The Intervene button is already there as a placeholder.
• Compare the same service on a small model and a frontier model, to see where the extra cost actually changes the result
• Compare all three personas in one report