Your Users Will Break Your App (and That’s a Good Thing)

As the new year approaches, I find myself reflecting on what has been an intense, rewarding, and occasionally uncomfortable journey. This past year was about building, breaking, learning, and rebuilding, often in that exact order.

We built a SaaS product from the ground up. I stepped into a team lead role. We ran lean, planned milestones, missed some, hit others, and learned quickly that reality has a way of ignoring even the neatest roadmaps. We made mistakes, many of them, and learned to treat those mistakes as data rather than failures.

This is the kind of learning no book or course can give you. You only really understand it when you're in the trenches, dealing with real users, real constraints, and real consequences.

The Starting Point: An AI Tool for Teachers

It all started with a conversation. The head of a university department shared their problem statement with us, a challenge they were facing in their day-to-day work. As we listened, we envisioned something bigger. We saw the potential to transform their specific problem into a solution that could help educators everywhere.

We set out to build an AI-powered ed-tech product focused on making assessment creation easier for teachers. The idea was straightforward: use LLMs to help educators create better assessments, faster.

On paper, it made sense.
The tech stack was exciting.
The roadmap looked reasonable.

The real education began once real users showed up.

The UX Confidence Trap

Early on, we were confident about our UX.

The designer reviewed it.
We reviewed it.
We walked through the flows and agreed: this works.

"This makes sense."
"Users will get this."
"This is a good flow."

They didn't get it. At least, not in the way we expected.

Users ignored buttons, misread instructions, skipped steps, and did things in orders that never crossed our minds. Sometimes all we could do was sigh, fix the issue instantly, and help them move forward.

At first, it's tempting to think users are careless or inattentive. That illusion disappears quickly when the same issues show up again and again across different people.

That's when our mindset had to change.

"Users Don't Make Mistakes"

One rule became central to how we build:

Users don't make mistakes.

If someone is confused or stuck, the product allowed it, or worse, encouraged it. User behavior inside the app routinely contradicted our assumptions. Hearing their feedback through chat support or quick online meetings was humbling. People didn't behave the way we designed them to behave. They behaved the way that made sense to them.

Some of the strangest user actions turned out to be the most valuable signals. They forced us to re-examine flows we were proud of, uncover complexity we had normalized, and see friction we were blind to, because we already understood the system.

UX stopped being about aesthetics and started being about cognition.

UX Is Not Separate From Engineering

Over time, UX stopped feeling like a layer on top of the product and started feeling like part of its foundation.

Small UX changes often required rethinking data models, APIs, and assumptions baked deep into the system. We learned sometimes the hard way that good UX isn't paint on top of engineering. It is engineering.

Every technical shortcut eventually shows up as user friction. Every unclear interaction usually traces back to a technical decision made earlier.

From Stealth to Reality

There's a huge difference between building something that works and building something that works for real people.

We're still in stealth mode, but we've been fortunate to connect with a university specifically, the head of one of the departments. When they shared their problem statement with us, we envisioned that it could be something much bigger. That conversation sparked the vision for what we're building today.

Even before a full public launch, having real users, actual teachers and educators, interact with our product has accelerated everything. Feedback became sharper. Priorities became clearer. The product started pushing back.

That pressure was uncomfortable, but necessary.

The goal crystallized quickly: make the product as close to dummy-proof as possible.

Not because users are dumb. Because cognitive load is real. Teachers are busy. They don't want to learn software. They want software to quietly help them do their job.

Designing for fluency, not just functionality, changed how we build.

Growing as a Team Lead

This year wasn't just about the product. It was about learning how to lead.

Learning when to step in and when to step back. Planning milestones that survive contact with reality. Managing a lean team without burning people out. Treating mistakes as inputs, not failures.

Building for real users forces honesty, not just about your product, but about your processes and your leadership.

What This Year Taught Us

• User behavior is unpredictable, and that's the point
• UX and system design are inseparable
• Real feedback is uncomfortable and invaluable
• "Dummy-proof" means respectful, not simplistic
• Every user issue is a design problem waiting to be solved
• User problems can spark bigger visions, listening to real problems reveals opportunities to scale

Looking Ahead

As the year wraps up, I'm grateful for the rough edges, the wrong assumptions, and the uncomfortable lessons. They made the product better, and they made us better builders.

You can theorize endlessly about UX, leadership, and product development. Real learning happens when you're inside the problem, reacting in real time, and adapting under pressure.

The world is messy. Users are unpredictable. And that's exactly what makes building things worth it.

Here's to another year of listening harder, simplifying more, and respecting the quiet intelligence hidden inside good UX, one interaction at a time.