Your component works until someone puts real content in it

How I stopped finding layout bugs after handoff and started finding them in Figma.

Every component I’ve ever designed looked finished in the file.

Two tidy lines of placeholder text. A short name. A price with one digit before the decimal. I’d hand it off feeling good about it.

Then real content showed up.

A label got translated and ran straight past its button. Someone’s surname wrapped onto a third line and pushed the price off the card. And an empty field left a gap that nobody had ever styled, because in my file, that field was never empty.

None of these were hard bugs. They were just bugs nobody looked for. Including me.

My “process” (if you can call it that)

On a design system I worked on this year, I had a routine for catching this stuff. It went like this:

1. Screenshot the component.
2. Paste it into ChatGPT (at that time, OpenAI was the only major AI player in the market).
3. Ask it to code the edge cases. Long text, empty states, weird numbers.
4. Read through what broke.
5. Go fix it. In code.

Did it work? Kind of.

Was it slow? Very. So slow that I only did it for components I was already nervous about. The ones I trusted never got checked, which is funny, because those were the ones that broke.

And every single fix landed in code. The Figma file never found out. A few weeks later, the design and the build had quietly drifted apart, one hotfix at a time.

The check wasn’t wrong; it was just happening at the wrong place.

So I moved the check into Figma

This is where the Stress Test module in the CalibrateDS Figma plugin came from. It didn't start as a feature idea. It started as me being tired of steps 1 to 5.

You select a component, hit Run, and it copies the component onto a sandbox page. Your original is never touched. Then it runs that copy through a set of content cases:

• the original, as designed
• copy at +30%
• copy at +60%
• copy doubled
• one long unbroken word
• numbers
• empty

Each case reports how many issues it found, and each issue opens to the exact layer that broke.

The number I didn’t expect

I ran it on an activity card from a travel app I designed. 42 combinations in total.

Long word found 11 issues. Fine, I expected that one. Emails and product codes don’t wrap.

But the original, the version I hadn't changed at all, already had 5.

Five. Before anything was stretched.

That’s the part that stuck with me. I thought the stress cases would break things. I didn’t think my “finished” component was already broken.

Why such boring cases?

You might be wondering why the cases aren’t wilder. Where’s the 400-character name? The emoji-only username?

Honestly, because boring is what actually ships.

• +30% is roughly what happens when copy gets translated, or a writer adds one more clause.
• Doubled is a user who writes more than you planned for.
• A long work is an email address, a URL, a product code.
• Numbers are prices and counts that grow by a digit.
• Empty is the state everyone forgets.

These aren’t edge cases. They’re Tuesday.

If you want weirder ones, you can connect your own AI key, and it’ll write content-aware cases for that specific component, like long real names on a profile card or different currency formats on a price. That part is optional. The built-in cases run without any AI.

What I do with the results now

I treat the issue count like a failing test.

Fix the component in Figma (usually it’s a text box set to fixed height, a missing min or max width, or auto layout sizing that should hug instead of fill). Run it again. Only then hand it off.

The fix lives in the design now, not just in the code. So the file and the build stay in register instead of slowly drifting apart.

Does this replace a developer testing the real thing? No. It just means the obvious breaks get caught by the person who can fix them fastest, before anyone writes code against a layout that was never going to hold.

Try it on one component

Here’s my challenge for you. Pick the component you trust the most. A card, a list row, a button with a long label option. Run it through the cases above, by hand or with the plugin, and count how many break in the original.

I’d genuinely love to know your number.

I also put the exact checklist I use into a short Markdown file you can drop into Claude or Cursor while you build, so the AI checks the same cases in code. It’s free on my site.

CalibrateDS is free and runs locally in Figma. Search CalibrateDS in Figma Community, or read more at calibrateds.deepadalja.com.

If you prefer to watch.

Let’s talk

What’s the edge case that got you in production? Tell me in the comments. I’m collecting them.

Your component works until someone puts real content in it was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.