DEV Community: Cathy Lai

I Stopped Writing My Resume for Another Software Engineer. That's When Recruiters Started Calling

Cathy Lai — Sat, 11 Jul 2026 03:36:09 +0000

When an international recruiter recently asked for my CV, I instinctively started writing it the way many developers do:

A chronological list of companies,
Programming languages, frameworks,
Technical achievements.

Then it hit me. I wasn't writing this document for a senior engineer. I was writing it for the recruiter sitting between me and the interview. If the first person reading my CV couldn't immediately understand the value I brought, I might never reach the technical interview at all.

Knowing the Receivers

So I rewrote it from a different perspective. Instead of simply listing technologies, I described the business context behind my work.

10,000+ emails sent a day (in addition to "Using AWS SES/SQS")
800+ restaurants / POS everyday (in additional "optimised SQL speed").
Cut down waste to 1.3% from 10 ~ 15%
Critical updates often in 24 hours.
Increased revenue, reduced costs, improved reliability
Helped onboarded new clients

I still included the languages and frameworks I used, so the CTO can understand, but they became supporting evidence rather than the headline. I also highlighted the moments that demonstrated trust:

Delivering critical business updates under tight deadlines,
Resolving high-priority production issues,
Taking responsibility for systems the business depended on, and
Taking initiatives to write a mobile app using my own time.

That small shift completely changed how I viewed a CV. It's not a journal of everything I've done, and it's not a technical specification. Its job is to communicate your value clearly to the person reading it, and that person is often a recruiter before it's ever seen by an engineering manager.

One lesson I keep coming back to is this:

Write for my audience.

Outcome (for now)

After reviewing the rewritten CV, the recruiter was confident enough to forward it to Tata Consultancy Services for a role. Whether or not that particular opportunity works out, it reinforced an important lesson for me: recruiters need to understand your business impact before an engineering manager can appreciate your technical depth.

Sometimes the biggest improvement isn't gaining another skill—it's learning to communicate the value of the skills you already have.

Why Does AI Generate 500 Lines of Code in One Function...? (Part 1/2)

Cathy Lai — Wed, 24 Jun 2026 04:52:48 +0000

Summary

AI tends to generate the "path of least resistance" based on what dominates its training data and examples, not necessarily what is architecturally best for a long-lived codebase.
Knowing this, there are steps we can take as seasoned developers to improve the code in multiple passes (part 2).

"Amazing" AI Code?

So your non-technical friends have told you about creating a complete landing page in a few minutes! Everything works. They can modify, create, delete elements and AI executed each perfectly. And fast. They love the site, and will definitely create more pages/sites this way.

You have a look at the code, and it looks like

❌ Messy code:

export default function XmasMugLandingPage() {
  return (
    <main className="min-h-screen bg-red-50 text-gray-900 overflow-hidden">
      <div className="absolute top-0 left-0 w-full h-full bg-gradient-to-br from-red-200 via-white to-green-200 opacity-70"></div>

      <section className="relative z-10 px-6 py-10">
        <div className="max-w-7xl mx-auto">
          <div className="flex flex-col lg:flex-row items-center justify-between gap-10">
            <div className="w-full lg:w-1/2">
              <div className="inline-block bg-red-600 text-white px-4 py-2 rounded-full text-sm font-bold mb-6">
                LIMITED CHRISTMAS EDITION
              </div>

// ... (messy code all in one function with 
//.      utility classes repeated 20 times)

The definition of "good" AI is obviously different from your expectation! ...!?

Why Does AI Generate Code This Way?

When we ask AI:

Build me a landing page with hero, pricing, FAQ and contact form.

The AI has several competing goals:

Get the answer correct
Avoid missing dependencies
Avoid introducing bugs
Fit within context limits
Produce something that runs immediately

Not because this is good architecture, But because it maximizes the probability of a correct response.

AI Has No Long-Term Ownership

A senior engineer thinks:

Someone will maintain this for five years.

The AI's priority:

I need to successfully answer this prompt.

Those are completely different optimization functions.

This explains: giant components, duplicated utility strings, repeated business logic and copy-pasted sections.

Tailwind is easier for AI to generate

With CSS Module:

// in a CSS file
.card {
  display: flex;
  align-items: center;
  gap: 1rem;
  padding: 1.5rem;
}

// in a HTML file
<div className={styles.card}>

In Tailwind

/// all in one file
<div className="flex items-center gap-4 p-6">

Obviously, AI will have less to worry about if it's all in one file.

Why AI likes shadcn

The AI can see the source code of:

components/ui/button.tsx
components/ui/card.tsx
components/ui/dialog.tsx ...

inside the project. No hidden implementation, and it can modify components directly.

With a library:

import { Button } from "@mui/material"

the AI cannot edit MUI's source code. It has to understand the MUI API - and that's harder.

Can We Improve On This?

With more and more apps written this way, it seems important that we developers learn to teach AI to tidy and refactor the code! Here are some outlines:

Generate The Page
Ask AI To Identify Repetition
Extract Components
Separate Content From Presentation
Establish Boundaries

In the next article, I will expand on each step and provide a walk through.

Do you have a similar experience with AI generated code? Does some of the AI tendencies surprise you??

Real World Tailwind CSS: Controlling the Special Cases (Part 2/2)

Cathy Lai — Sun, 21 Jun 2026 11:56:25 +0000

So in the last article, we have discussed the best practices for using Tailwind CSS4 in the real world - which is,

A dedicated team maintaining the components
The other teams just use them for creating pages
Linter to enforce boundaries, not good will

In this way we "hide" the long utility class strings from rest of the codebase.

Special Landing Page

What happens when marketing launches a new campaign and needs a gradient CTA button that deviates from the core design system??

The obvious choice might be to do something like this:

const variants = {
  primary: "...",
  secondary: "...",
  // The new marketing variant
  "ai-campaign": "bg-gradient-to-r from-emerald-500 to-teal-500 animate-pulse text-lg px-8 py-4" 
};

This looks clean today. But in a few years, it might grow to

<Button
  variant="primary"
  isMarketing
  isAnimated
  hasGlowEffect
  showConfetti
  campaignTheme="black-friday-2024"
  seasonalBadge="sale"
  size="xl"
/>

Now it's bloated again... this is called prop explosion.

What's the Best Way?

Option 1: Keep It Local with Tailwind Utilities

Sometimes a design is so specific that it's hard to imagine anyone using it again. So, just make the page live in a separate directory and use utility classes directory

////  Inside @/app/marketing/campaign/page.tsx ////
...
export default function CampaignPage() {
  return (
    <div>
      <h1>The Next Generation of AI</h1>

      {/* Custom, one-off visual classes are localized entirely to this page */}
      <Button
        className={cn("bg-indigo-600 text-white px-4 py-2", className)} >
        Get Early Access
      </Button>
    </div>
  );
}

Once the campaign ends, just delete the page. The component is left untouched.

Option 2: Add a Variant

If there are only a handful of visual styles and they genuinely represent something the business uses repeatedly, I'd probably just add another variant.

<Button variant="primary" />
<Button variant="secondary" />
<Button variant="cta" />
<Button variant="voucher" />

The props felt easy enough to understand, and it keeps the page code nice and clean. In a smaller codebase, maintaining a few extra variants would not be a big deal.

Option 3: Create a Specialized Component

There's also a middle ground. If I find myself copying the same styling around a campaign or a particular section of the application, I'd probably start wondering whether it's worth creating something like a .


function CampaignButton({ className, ...props }) {
  return (
    <Button
      className={cn(
        "bg-gradient-to-r ...",
        className
      )}
      {...props}
    />
  );
}

// Base component
<Button>
  Testimonials
</Button>

// Campaign-specific component
<CampaignButton>
  Get Early Access
</CampaignButton>

That way the shared Button stays focused on being a button, while the campaign gets its own reusable abstraction. It feels like a reasonable compromise when you're not quite ready to promote something into the design system, but you don't want duplicated styling everywhere either.

The goal is:

Keep shared components focused, understandable, and maintainable.

Do you agree with the tradeoffs? What are your tips for writing even tidier and more maintainable components? Please share your experience ~ :)

Real World Tailwind CSS: The "Gatekeeper" Architecture: A Senior Developer's Guide (Part 1/2)

Cathy Lai — Fri, 19 Jun 2026 09:25:12 +0000

So, armed with the knowledge of Tailwind and what it has to offer, how should we actually start our next large-scale project? To answer that question, it helps to look at how mature design-system teams structure frontend development in large organizations.

The Blueprint: Component Authors vs. Feature Developers

After a quick research, I've found that many successful design systems, including examples such as Shopify Polaris, are built around a simple idea: not everyone on the team is responsible for styling decisions.

Instead, styling responsibilities are often separated into two distinct roles:

The Component Authors (The Gatekeepers): This core team builds foundational UI primitives. They write the Tailwind classes, manage accessibility, dark mode, component states, and design-token compliance.
The Feature Developers (The Assemblers): This team builds product features, workflows, and dashboards. Their primary focus is business logic and page composition rather than choosing colors, typography, or spacing scales.

Many organizations reinforce this boundary through a combination of lint rules, code review standards, internal tooling, and shared team conventions.

✔ Allowed: layout and composition utilities (flex, grid, gap-4)

❌ Discouraged: introducing new visual styles such as bg-indigo-600 or text-lg directly inside feature pages when an approved component already exists

Code Example: The Standard Corporate Button

To see this boundary in practice, let's look at how a standard corporate button might be built and consumed.

1. What the Component Author Builds

The Component Authors create a reusable primitive inside @/components/ui/button.tsx. The visual styling is centralized behind a clean TypeScript API:

// Managed by the Design System Team (@/components/ui/button.tsx)
import React from 'react';

interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
  variant?: 'primary' | 'secondary';
  className?: string; // Intended for layout adjustments when needed
}

export function Button({
  variant = 'primary',
  className = '',
  children,
  ...props
}: ButtonProps) {
  const baseStyles =
    "px-4 py-2 rounded-lg font-medium text-sm transition-all focus:outline-none focus:ring-2 focus:ring-offset-2";

  const variants = {
    primary: "bg-indigo-600 text-white hover:bg-indigo-700 focus:ring-indigo-500",
    secondary: "bg-slate-100 text-slate-700 hover:bg-slate-200 focus:ring-slate-500"
  };

  return (
    <button className={`${baseStyles} ${variants[variant]} ${className}`} {...props}>
      {children}
    </button>
  );
}

2. How the Feature Developer Uses It

When a Feature Developer builds a dashboard page, they primarily assemble existing building blocks and focus on feature logic:

// Inside @/app/dashboard/page.tsx
import { Button } from "@/components/ui/button";

export default function Dashboard() {
  return (
    <div>
      ...

      <Button variant="primary" className="mt-4">
        Save Changes
      </Button>
    </div>
  );
}

The visual design remains centralized in the component, while the page controls placement and composition.

Scenarios

Deleting a Button

The developer who originally created a page has moved on, and another developer needs to remove a button.

Because the visual styling is already encapsulated inside a shared component, there is no need to search through multiple CSS files looking for button-specific styles. The page simply stops using the component.

This reduces the risk of obsolete styling logic lingering in the codebase and makes long-term maintenance easier.

Colour or Theme Change

Suppose the company decides to move from Indigo to Violet as its primary brand color.

In many design-system architectures, the update happens in a single shared location (or design-token layer). The change then propagates consistently across the application without requiring developers to update individual pages.

A Bigger Lesson

The important idea is not Tailwind itself. The key architectural concept is the boundary between component authors and feature developers. Tailwind is simply one effective tool for implementing that separation while keeping styles close to the components that own them.

In the Next Article...

This approach covers most day-to-day product development. But what happens when the marketing team wants a one-off campaign page with a glowing, animated gradient button that doesn't fit the design system? Do we extend the component library? Create a special exception? Relax the rules?

In Part 2, we'll explore practical ways to handle architectural exceptions without turning the codebase into a free-for-all.

Tailwind CSS4: Why Those Inline Styles Are Actually More Scalable - A Senior CSS Developer's Guide

Cathy Lai — Tue, 16 Jun 2026 05:09:55 +0000

So you have heard about the Tailwind CSS and want to incorporate into your new project. But those inline styles look so polluted - they look similar to the old "style="font-size: 12px; color: green; font-style: italics" stuff we are told to avoid. What is going on here? Are we going back??

The Problem with Plain CSS Classes

Before you run the other way, I think we have all encounter this problem maintaining a large codebase:

/* Developer A wrote this 2 years ago */
.card-variant-3 {
  background-color: #f3f4f6;
  padding: 1rem;
  border-radius: 0.5rem;
}

After 2 years, the stylesheet is 5,000 lines long. And this class could be used anywhere in the codebase of millions of lines.

Developer B is too scared to modify .card-variant-3 because they don't know if it's used on some obscure marketing page... So they just append a new class to the bottom of the file.

.card-variant-3-updated {
  background-color: #f3f4f6;
  padding: 1.5rem; /* <--- Only changed the padding! */
  border-radius: 0.5rem;
}

The Problem: Bundle sizes grow linearly with the app. You have to spend your time naming things (.main-content-inner, .card-body-flex) and jumping between HTML and CSS files.

What Tailwind Gives Us

Tailwind solves this problem by creating "utility classes" such as "bg-mint-500", "text-mint-500", and "border-mint-500" from CSS variables which one can use in the HTML like so

<h1 className="text-mint-500"> Introduction </h1>

This restructure gives us two advantages:

The Reduced CSS Bundle Size: Because you reuse bg-mint-500 or p-4 over and over, you stop writing new CSS lines. Whether you have 10 pages or 10,000 pages, your production CSS stays virtually the same size (often a fraction of traditional stylesheets).
Dramatically Lower Risk in Refactoring: Everything that makes this element look the way it does lives exclusively inside this component block. If you delete the component, the styles are deleted instantly alongside it. There is absolutely zero risk of breaking a sidebar on the other side of your application.

What about Readability??

The biggest reason this is okay is that you only have to look at it occasionally.

In modern web development, we rarely write raw, static HTML pages anymore. We use component-based architectures (React, Vue, Svelte, Blade, Astro, etc.).

When you style an elements block like this, you immediately encapsulate it inside a reusable component. E.g.,

<Card variant="premium">

Once that component is saved, the "ugly" implementation details disappear behind a clean, semantic custom tag. Your main layout code remains pristine, while the styling mess is safely quarantined inside a single file.

Conclusion

We traded pretty markup for bulletproof maintainability. We allowed our HTML to look messy in development so that our production architecture could remain perfectly clean, predictable, and isolated.

I will discuss more about Tailwind CSS in real projects. Follow me for more such articles!

Please comment below - how do you manage your CSS and do you think utility classes is a good idea??

What Are Customers Already Asking For That I'm Ignoring?

Cathy Lai — Sat, 13 Jun 2026 10:46:08 +0000

Another Cool Tech to Add?

After playing with some AI-generated garden mockups, I thought it'd be cool to let users choose the styles they want, eg. Scandinavian, Mediterranean, or Japanese gardens... It is technically interesting. I could imagine a dropdown, a scrollable style gallery? And I can tweak the prompts to make sure AI generate a good suggestion...

But before I went on a tangent, which could be weeks down the track, I remembered The Mum Test book I've read. So I've decided to do some research on the users online and what they actually already doing?

Observation 1: Successful YT Landscape Channels

Many of the most popular garden-related videos were not focused on luxury landscaping or designer gardens. Instead, they focused on practical topics:

A recurring theme was that viewers seemed to appreciate realistic improvements rather than perfection.

The message was often:

"You don't need a $20,000 renovation. Here are a few simple changes that make a noticeable difference."

This suggests that many homeowners are looking for confidence and direction rather than professional-level landscape design.

Observation 2: Reddit Questions

Many posts were not asking for specific garden styles. Instead, they looked more like:

Many homeowners appeared overwhelmed by the number of possible choices.

In some cases, they could not clearly identify what was wrong with the garden. They simply knew that it didn't feel right.

Working Hypothesis

Based on these observations, my current hypothesis is:

Homeowners may not be looking for perfect gardens.

Instead, they may be looking for:

Reassurance
Direction
Confidence
Visualization of realistic outcomes
Affordable improvements

In other words, the problem may not be:

"Design me a Japanese garden."

The problem may actually be:

"Show me what this could look like if I spent a few hundred dollars and a weekend improving it."

Proposed Experiment

What is the cheapest and the easiest way for me to test this theory? Probably not

❌ Building more tools on my website,
❌ Nor is it creating more static pages.

I just need to reply to users who are actively anticipating answers. Instead of promoting a product or linking to a website, I will try to be genuinely helpful by:

✔️ Answering their specific question
✔️ Suggesting a few practical improvements
✔️ Attaching relevant before-and-after visual examples
✔️ Showing realistic transformations

The goal is not to sell anything. It is to observe whether visual examples help people understand and evaluate potential improvements more easily.

Success Criteria

Some signals that would support the hypothesis include:

Positive replies and engagement
Follow-up questions
Users saying the images helped them visualize possibilities
Requests for similar examples
Discussions shifting from confusion to specific decisions

Conversely, if people ignore the images or focus on entirely different concerns, that would provide valuable feedback as well.

Would I Keep Building My AI Tools?

Yes, I definitely will keep building and learning. But I now am more clear that those are for my own learning, not necessary for the customers. This will keep me from feeling discouraged when there are no user signups.

So Nobody Told Me that Prompting Is Not Programming...

Cathy Lai — Wed, 10 Jun 2026 06:38:36 +0000

Now I've got the GUI of the app, it's time to "program" the prompt! Without much knowledge, I treated the prompt exactly like an API call. I uploaded a photo of a messy yard, and start typing the prompt.

The Sample Before Image

After a set of instructions (add lawns, furniture, mulch, native evergreen shrubs, furniture, and solar and string lights), I have got this

It looks okay, but the texture feels washed out and uninviting... I have tried several other examples, and they all had the same problem. No matter how many times I asked it to add vibrant lawns, nice lighting, it gave me worn out lawns, washed out feeling, grey sky, and may or may not include lighting...

How About Just Describe the "Mood"??

So I asked GPT how to solve this problem? It told me that I should just describe the "mood", eg. homely, motel-like, morning sun, neat, tidy, simple, and elegant. And let it arrange the objects. So I've got something like this:

Looks better... however it is too much like a neat hotel, a concrete jungle, and the materials look expensive with a lot of construction work. I keep asking it to be "homely", "affordable"; but it seems to ignore those.

The Real Meaning of Prompt

So I started from scratch, using another model (Gemini) and describe the project and the problems I encountered.

Gemini told me something surprising...! That is Prompt engineering is not programming. I had my mental model wrong all along.

The Probabilistic Compiler vs. Latent Space

When I write traditional code, I am issuing commands to a deterministic CPU. When I prompt, I am interacting with a statistical weight matrix.

The AI doesn't compile my text instructions; it navigates a massive, multi-dimensional mathematical map of human concepts called latent space.

Every word, phrase, and visual style in the model's training data lives on this map as a set of coordinates. Concepts that are similar sit in the same geographic neighborhood.

My prompt isn't an imperative command—it is a vector coordinate pulling the generator toward a specific statistical zip code.

The Taxi Analogy:

Traditional coding is giving a driver exact GPS coordinates: "Drive 400 meters, turn left, park at Spot #42." The outcome is identical every time.

Prompting is calling a cab and saying: "Take me somewhere cozy in the Arts District." Because the neighborhood is huge, the driver drops me off at a completely different alleyway every single time.

Both spots technically fit my description, but the visual layout changes entirely. If I leave my prompt loose, the model wanders around that neighborhood, causing the massive variance I see.

My Solution: Structuring the "Config File"

The fix for me was to pass the AI a clean, structured pseudo-schema rather than a paragraph of text. By defining strict parameters, I forced spatial and material continuity.

Here is the structured approach that finally tamed the variance for me:

[Environment Map]: Use the uploaded backyard photo strictly for spatial boundary context.
[Style Const]: Bright morning sunlight, high-contrast architectural photography, homely vibe.
[Financial Guardrails]: Show only low-cost, DIY-friendly materials. 
  - ALLOW: Dark bark mulch, timber edging, river gravel.
  - EXCLUDE: Masonry, expensive stone pavers, structural retaining walls.

Why this works:

Locks the Environment: Defining the lighting and camera angle upfront eliminates the AI's tendency to randomly shift from midday sun to moody twilight.
Hardcodes the Constraints: Instead of letting the AI guess what "low budget" means, I explicitly whitelist cheap materials (mulch, gravel) and blacklist expensive ones (paving, walls).

By shifting my mindset from "solving a spatial puzzle with code" to "setting strict boundary parameters on a statistical matrix," I stopped fighting the randomness and started leveraging the inspiration.

The Result

It is much closer to the homeliness I wanted, with inspiring lighting, vibrant lawns, low maintenance shrubs, and achievable garden beds.

How Suddenly ChatGPT Understood Me - by Me Changing One Word

Cathy Lai — Fri, 05 Jun 2026 01:16:41 +0000

This morning I was trying to generate a simple accessibility modification for a backyard deck.

I wanted something like a small gentle ramp so an elderly person in a wheelchair could get onto the deck more easily.

Instead, I kept getting images like this:

The ramp is technically correct, but completely wrong for the homeowner!

My First Assumption: The Model Isn’t Good Enough

After about 10+ trials, I concluded that ChatGPT is just not good enough. Perhaps I should find a better model that's especially designed for image generation?

After sleeping on it for a day or two, I have decided to "think like AI". If it has been trained by ramp images, what would general ones look like?

Even though the incorrect images are all different, they all had the same underlying idea:

long pathway
extensive handrails
institutional appearance
accessibility-first design

The AI wasn’t being random. It was being remarkably consistent. That meant the problem might not be the model at all.

Investigating the Word “Ramp”

I searched Google Images. Most results looked surprisingly similar to the AI outputs.

The common theme was: long, extended slop, large handrails. It spells safety and accessibility, not residential elegance.

At that point I started wondering: if image models learn patterns from large collections of internet images, perhaps “wheelchair ramp” strongly correlates with these kinds of designs.

Changing the Prompt

So I made two changes.

First, I removed the word: ramp and replaced it with: slope

The goal was to remove the strong association with commercial accessibility infrastructure.

Second, I supplied a reference image showing the kind of small timber transition I actually wanted.

The generated design became much closer to my intent! Not because the model suddenly became smarter. Because the instructions became clearer. The AI no longer had to guess what kind of ramp I meant.

Final result:

And then I asked it to match the colour of the deck and put the handrail on the other side:

Now it’s perfect:)

What I Learned

The interesting lesson wasn’t about landscaping. It was about how AI systems interpret language.

When I used the word “ramp”, the model wasn’t hearing “elegant backyard modification”. It was hearing: “the average concept of a wheelchair ramp found across millions of images”. Once I understood that, the solution became obvious:

choose words carefully
look for patterns in failures
provide examples when possible

Conclusion

I almost dismissed GPT and tried to signed up for a more expensive app. Instead, I solved it by understanding how the model was likely interpreting my prompt. Sometimes the next step isn’t a better model. Sometimes it’s spending ten minutes asking:

“What does this word mean to the AI?”

My Potential Users are Just Busy… Or Are They?

Cathy Lai — Wed, 03 Jun 2026 14:33:01 +0000

When I first told a friend about my AI garden visualization idea, she said

What a great idea! Sounds interesting!

So I asked her to send me her backyard photos for testing! Then a week went by, she didn't send any photo. I assume: "she’s a busy doctor. She works long shifts, late nights, and weekends."

But after reading The Mom Test, I’m starting to think there was a simpler explanation: The problem wasn’t painful enough.

"Can You Help"?

About a week later, she contacted me again. This time, she sent photos of her parents’ backyard.

Not just the photos - she explained the layout, described the constraints, and talked about wheelchair access for her elderly parents.

I then did a AI mockup for it. She reviewed it, thanked me and asked for more changes. And, she mentioned something I never asked about:

A landscape designer had quoted approximately $3,600 just for the design work.

Actions vs. Words

One of the biggest lessons from The Mom Test is that people are poor predictors of their future behavior. What they do is always more informative than what they say.

Looking at my friend’s actions, the data points were clear:

What I Know:

She has a real problem and is actively trying to solve it.
She is willing to spend money to solve it but $3,600 is too much.
She wanted to see what AI could do without the designer.
She is interested enough to come back with more requests.
The mockup made it clear for possible outcome, and provided ideas for additional improvements and other considerations.

What I Don’t Know:

Whether people like her would pay for an AI visualization app. There is no validation from her actions.

A More Defensible Hypothesis

Based on the evidence, a more reasonable hypothesis might be:

Homeowners planning significant outdoor renovations want a low-cost way to visualize ideas before committing to expensive design and construction decisions.

That’s not necessarily:

People want an AI garden design app.

The first statement comes from observed behavior. The second statement is still an assumption.

The Art of Staying Detached

To actually see these insights, I'm realizing the most important thing is to approach these conversations as a blank slate.

I have to remain completely detached from the outcome.

Without that detached attitude, it is still incredibly easy to be biased and read into a situation something that isn't actually there. It requires a lot of practice and a constant shifting of perspective.

I am still learning. But with practice, I know I can get better at it over time.

My Biggest Takeaway

The most valuable thing I gained from this experience wasn’t validation for my product. It was learning to watch actions instead of listening only to words.

When someone says "Interesting idea," it tells me very little. But when someone spends money, sends photos, reviews mockups, and keeps coming back - that's evidence that the problem is serious enough to even began the conversations.

Because people don’t make time for what sounds interesting.. They make time for what hurts

My Biggest Fear In Talking to Users – What If They Just Want a Static Website? (Part 1/2)

Cathy Lai — Tue, 02 Jun 2026 06:07:31 +0000

Reading Notes From the Book "The Mum Test"

Now that I've build a clever AI image generation app, everybody will just jump on the chance to try it... Right?

As a developer, that's what I'd like to think.

I imagine sophisticated architectures, AI integrations, user accounts, databases, cloud infrastructure, clever AI image generation pipelines, system prompt and context engineering, and all the exciting technology that will solve users' problems.

Is that What the Users Want?

Maybe:

They just want to browse a collection of garden makeover photos?
They don't want to upload their own property photos? For privacy concerns?
They don't want to wait 60 seconds for an AI-generated image?
A simple gallery of before-and-after examples solves 90% of their problems?

As a developer, that's a surprisingly difficult thought to accept. After all, generating AI garden transformations sounds much more exciting than displaying a set of static images.

And that's exactly why it makes me uncomfortable. Because if a simple solution provides more value to users than a complicated one, then I've spent a lot of time solving the wrong problem.

A boring solution with real users is infinitely more valuable than a clever solution with none.

The Book "The Mum Test"

That's one reason I've started reading The Mom Test by Rob Fitzpatrick before launching my site.

The book challenges a mistake many founders make:

Asking people what they think of an idea instead of understanding what they already do.

Here are my notes in the key points:

Takeaway #1: Talk About Their Behaviour, Not Your Product

A homeowner might tell me:

"An AI garden design tool sounds useful."

But that's not the question that matters.

A better question is:

"What did you do the last time you wanted ideas for your garden?"

Maybe they browsed Instagram? Maybe they asked a question in a Facebook or Reddit gardening group. Or just ask their parents? Friends? Do they hire a landscape designer instead. What about gardening magazines? Or most people just buy plants without planning? Because they look good?

If that's how they currently solve the problem, then that's where I should start paying attention.

Takeaway #2: Past Actions Are More Valuable Than Future Promises

People often overestimate what they will do in the future. The Mom Test argues that future promises are weak evidence. Past behaviour is much stronger.

Instead of asking:

"Would you use an AI visualizer?"

I should be asking:

"How many hours did you spend looking for garden ideas last month?"

Or:

"Have you ever paid for landscaping advice?"

Those answers reveal whether the problem is important enough for people to spend time or money solving.

Takeaway #3: Look for Actions, Not Compliments

As developers, we love positive feedback. But compliments can be misleading. The strongest signals are actions:

Do they reach out for advice?
Do they checkout gardening materials?
Do people share photos? And like makeover images?
Do they bookmark examples?
Do they trust the landscape/garden advice?

These behaviours tell a much clearer story than:

"That's a great idea."

Action Points for Me

Having these 3 takeaways in mind, I will start listing out the practical actions to take to understand the users more. I will share them in the next part of this series!

Spending Hours Designing the UI? Or Just Telling AI the Pain Story

Cathy Lai — Sun, 31 May 2026 05:21:45 +0000

Now that I get my backend API services in place, it's time to design a frontend! Just describe the mood to AI, right? I did, and it looked... fine. But it didn't feel right. It didn't match the soul of why I was building it.

So, instead of looking at font pairing blogs for three hours, I sat down and told Gemini the personal story and frustration behind the app.

Outdated Garden Styles

I explained that as a busy professional, I felt completely alienated by the gardening world. Every time I looked up gardening advice on YouTube or blogs to fix up my yard, I was met with slow acoustic country music, rambling lectures full of jargons, and an aesthetic that felt like a grandmother giving advice.

It felt old fashioned, inefficient, and totally out of touch with how my peers and I live. For example:

❌ Old fashion garden style

We don't want a chaotic cottagecore wildflower patch that takes six hours a week to prune. Our design references are the sleek tech offices we work in, the boutique hotels we visit, or the trendy cafes with clean gravel, square lawns, structural plants, and warm outdoor lighting. We just want a beautiful, low-maintenance outdoor lounge where we can turn on some music, host a weekend barbecue, and have drinks with friends on a summer evening.

✔ Modern outdoor courtyard

I told Gemini: “I built a tool that takes a messy yard and instantly visualizes that clean, hotel-grade hosting space. Help me pick a font system that talks to these busy professionals, not their grandmothers.”

10 Seconds to the Right Font...!

Main title font "Fraunces"

Subtitle and body text "Inter"

Tailwind Changes

Load Fraunces from Fontshare in global.css

@import url("https://api.fontshare.com/v2/css?f[]=fraunces@500,600,700&display=swap");

  --font-inter: var(--font-inter-family), ui-sans-serif, system-ui, sans-serif;
  --font-fraunces: "Fraunces", ui-serif, Georgia, serif

Apply it on the page title (page.tsx)

            <h1 className="font-fraunces text-5xl leading-[0.95] font-semibold tracking-tight text-[#1f321d] sm:text-6xl">
              GardenViz
            </h1>
            <p className="font-inter mt-2 text-lg font-medium tracking-tight text-[#3a4f35] sm:text-xl">
              Garden Design Visualizer for Busy Homeowners
            </p>

The result

I think it looks quite good! :)

AI as a Collaborator

By treating the AI as a creative collaborator and feeding it the context of a real human frustration rather than just a technical prompt, I got a design system that feels incredibly intentional.

OpenAI Image Generation: Would Results Improve with Positive& Negative Example Images? (Screenshots Included)

Cathy Lai — Thu, 28 May 2026 04:17:38 +0000

Perfect Prompts Needed?

In creating a garden visualizer to help home owners with their landscape decisions, I assumed that I needed to "program" the text prompt perfectly in order to give good results. So spending time tweaking the text descriptions seems natural.

However, after a few days learning about context engineering, I realised I could just send example images and describe what I like or dislike about them. That makes it a lot easier!! Both for me and for GPT!

"Before" Image

Text prompt

Could you give me an idea of how I could transform this area of the property to have a nicer garden?
Please don't change any of the layout and proportions nor points of view.
Please don't add extra buildings or structures either.

Result

Conclusion: it looks very nice, but quite unrealistic... home owners probably won't be able to know where to start to achieve it!

Prompt with 2 Images as Positive and Negative Examples

Positive example image

Use it as a style guide, eg the realism style, the lawns (restricted and tidy), the sunlight, the homeliness, and simple yet elegant furniture. Not expensive. And not gardening magazine fantasy.

Negative example image

Do not match its unrealistic look, expensive furniture, perfect edges, storybook-like texture.

With 2 images as part of the parameters, I got a more achievable, yet still inspiring image:

I think it has picked up from the positive example: lawns, lighting, realism, and the simple furniture. From the negative, it got rid of the large qualities of flowers, and exclude expensive furniture.

Reference

To easily test different variations, I have a test script

test-image-edit.mjs

// And run it like so:
npm run test:image-edit -- -i public/images/messy_garden2.png --positive public/images/positive.jpeg --negative public/images/too_perfect.jpg -o scripts/output/test_output

This enables me to add images as parameters, so in the future I can play with different variations easily, without changing the source code constantly!