DEV Community: Danny Chen

UX Engineering: From the Eyes of a Field Pioneer (2026 Edition)

Danny Chen — Tue, 07 Oct 2025 06:30:14 +0000

What is UX Engineering?

UX Engineering is the technical discipline of building and validating a product's user interface with a primary focus on the quality of the user's experience. It is the crucial architectural practice that serves as the binding agent between the worlds of design and backend engineering. More than just an evolution of the traditional front-end developer role, UX Engineering represents a fundamental shift in responsibility—from simply implementing a design to becoming the steward and hands-on builder of the final, interactive user experience.

The Architect and Gatekeeper

At its core, a UX Engineer operates like a building architect. They are the master translators, fluent in both the language of design intent and the language of technical feasibility. They don't just receive a design blueprint; they act as a critical "checkpoint" or "gatekeeper", providing essential validation to ensure that the vision is not only beautiful but also technically sound, scalable, and capable of integrating smoothly with backend systems.

This central role allows them to bridge the classic communication gap where designers and backend engineers often struggle to connect, preventing costly rework and ensuring the final product remains true to its intended user experience.

The Three-Layer Model

In a modern product team, the UX Engineer sits as the essential middle layer, connecting the other two:

UX/UI Designers: Who define the product's vision, feel, and user journey.
UX/Design Engineers: Who translate that vision into a high-fidelity, interactive, and technically validated reality.
Backend Engineers: Who build the foundational logic and data systems that power the experience.

Without the UX Engineer, a critical gap exists. With them, the entire development process becomes more integrated, efficient, and de-risked from the start.

Why Your Team Needs a UX Engineer?

Let's talk about the most common point of failure in modern product development: the expensive and ever-widening gap between your design vision and your final, shipped product.

Every team in this industry experiences the same friction. Your talented UX designers create intuitive, user-centric visions. Your skilled backend engineers build powerful, robust systems. And in between, there's a chasm. This is where projects go to die. It's where timelines get bloated with endless rework cycles, where your final product becomes a compromised version of the original idea, and where your investment in a great user experience evaporates during a painful implementation phase.

For years, we've tried to patch this gap with more meetings, more documentation, and more project managers. But you can't patch a foundational problem. You need a bridge.

That bridge is the UX Engineer.

It’s an Evolution, Not Just Another Role

This isn't about adding another headcount to the roster; it's about a strategic evolution of your front-end capability. A traditional front-end developer is often tasked with simply implementing a design. A UX Engineer is tasked with being the steward of the user's experience at the most critical junction—where design and code become one. They are the hands-on architects who ensure the product you envisioned is the product your users actually get.

The Strategic Value of a UX Engineer

Here is the tangible impact they will have on your team and your product from day one:

They De-Risk Your Investment Before a Line of Code is Written. A UX Engineer acts as a critical "gatekeeper", validating designs for technical feasibility from the very beginning. This proactive step alone eliminates the most common cause of rework, saving you countless hours of wasted engineering and design time.
They Build a Scalable Foundation for Future Growth. Their primary output is often a robust Design System. This isn't just a style guide; it's a library of pre-built, reusable, and experience-tested components. It's a force multiplier that makes all future development faster, more consistent, and cheaper.
They Engineer a Superior 'Feel' for Your Product. In a competitive market, how a product feels is a key differentiator. A UX Engineer is a specialist in Interaction Design & Development (IxD). They engineer the fluid animations, transitions, and micro-interactions that make a product feel intuitive and delightful, not just functional.
They Create a More Efficient Engineering Workflow. By defining the API requirements for the front-end before the backend team begins their work, the UX Engineer removes the classic bottleneck where the front-end is forced to wait or work around a backend that wasn't built with their needs in mind.

In short, a UX Engineer doesn't just write code. They align your teams, eliminate friction, and ensure that the quality of your user experience is a foundational part of your engineering culture, not an afterthought.

What is a UX Engineer?

A UX Engineer is a hands-on technical leader and specialist who operates at the precise intersection of design and engineering. Their primary responsibility is to ensure the user's experience is flawlessly translated from a conceptual design into a high-quality, interactive, and technically sound product. They are not passive implementers; they are proactive architects and stewards of the front-end experience.

Core Competencies & Skillset

A UX Engineer possesses a unique, niche skillset that allows them to bridge the gap between design and engineering:

High-Fidelity, Interactive Prototyping: They are masters of engineer-focused prototyping tools (like UXPin) that allow them to build more than just static images. They create functional blueprints that simulate complex interactions and states, validating the user experience before development begins.
Mastery of Front-End Frameworks: First and foremost, they are expert engineers with a deep command of modern front-end frameworks and technologies. This is the foundation upon which all their other skills are built.
Deep Familiarity with Design Systems: They are both students and creators of design systems. They have an expert understanding of established systems like Material Design and Apple's Human Interface Guidelines, allowing them to build upon best practices and maintain consistency.

Key Responsibilities & Activities

On any given project, a UX Engineer's time is focused on these four critical, value-driving activities:

Design Validation & Feasibility Analysis: Acting as a critical "checkpoint" or "gatekeeper," the UX Engineer partners with designers early in the process. They assess technical constraints, validate the feasibility of interaction concepts, and ensure the final design is buildable without compromising the integrity of the user experience or the stability of the underlying system.
Design System Engineering & Maintenance: A primary responsibility is the architecture, construction, and maintenance of the product's Design System. They build the library of robust, reusable, and accessible UI components that serve as the single source of truth for both designers and other engineers, accelerating development and ensuring product-wide consistency.
Interaction Design (IxD) & Development: The UX Engineer is responsible for bringing the interface to life. They engineer the fluid animations, state transitions, and micro-interactions that define the product's "feel." This focus on IxD is what elevates an interface from merely functional to truly intuitive and delightful.
Front-End API & Data Contract Definition: Working proactively, the UX Engineer analyzes the needs of the validated user interface and communicates the specific data requirements to the backend team before they begin development. This ensures the backend is built to serve the user experience from day one, eliminating bottlenecks and preventing the front-end from being constrained by a misaligned data structure.

Here's Why I Have Chosen to Leave the Design Industry in Singapore

Danny Chen — Thu, 21 Aug 2025 04:49:26 +0000

Hey everyone! I suppose you can say that this article has been in the works since 2016. Yeah, I began noticing those early signs and patterns in the industry years ago, but it seemed like at that time, no one in the design industry was ready to listen or hear what I have to say yet (even as a certified Thought Leader 🤦‍♂️🤷‍♂️). And so, I continued to remain in the shadow for the years to come, quietly making notes and observations about where the wind was going to blow 🌬.

Now, almost a decade later, I am ready to draw some conclusions. I believe the timing is also right. I believe this is perhaps the time that the design industry is READY to sit up and finally listen.

I've spent nearly 20 years of my career in Singapore. I've always considered it a privilege that I was born here and have remained here for most of my life. We have amazing government leaders and systems that are considered to be the best in the world. In fact, I am proud to call myself a Singaporean for many of those reasons. But that doesn't mean that everything about us, as a country or society, is great. And that is especially true when it comes to our design industry.

Singapore's Design Industry has Lost Its Edge

Here's the reality that we often don't want to face or admit to. Forget about the media for a moment and consider the facts on the ground. For years, we have enjoyed relative success and have earned the prestigious title of being called the "Innovation Hub" of the world. When it comes to the design industry, man, we are at the very top of the world. Okay, may not always, but consistently, Singapore's design industry has always been among the top in the world.

We might not have natural resources, but the one thing we've always had, was the pool of TOP Design Talents. The reason why so many businesses and companies want to invest here isn't just because of our stability as a nation, but because of the talent pool that we provide. If we took the world's combined top design talents (not wealth, but knowledge and skills), Singapore would be among the top 1% of the world. Well, at least that is what it used to be. That has stopped being true for a few years now. Signs that we are already slipping.

And it's true. We've enjoyed that success for some time now. But sadly, it is also true that we are quickly losing our edge. In fact, we might've already lost it for a while and we just didn't want to face that reality. It's almost like living in self-denial.

Going From a Talent Destination to a Waystation

In the past decade or so, I have witnessed and observed our tiny, little prosperous nation go from being a talent destination to a waystation. Most of the Top Design Talents I know aren't interested in staying anymore. They see Singapore as the place to grow, to learn, to discover their fullest potential. And once they have gotten what they needed, they would leave. The same is also true for a lot of our local top design talents.

After nearly a decade of observing those patterns and trends, I'm here to give the Singapore Design industry a warning message:

"If we do not change course and make the necessary adjustments soon, by 2030, Singapore will experience a 60% turnover rate of our top design talents (both local and foreign)."

Time to Welcome the Top Emerging Markets in Digital & Product Design

For the past decade or so, I have been seeing the early signs of design communities around the world picking up pace. While Singapore was leading, it was getting complacent at the top and slowing down. But for these other markets, they are much hungrier, and have the kind of drive that we, Singapore's design industry has lost along the way.

That is also why I've chosen to focus the next stage of my life's work on these emerging markets from Sao Paulo, Brazil, all the way to Lagos, Nigeria. It is NOT a matter of IF, they will exceed Singapore's design industry in innovation and new design ideas, it is only a matter of WHEN. And from what I can tell, that can happen very soon. All they needed is a BOOST. Frankly, since I'm no longer needed here as much, it seemed like the right time to finally shift my focus elsewhere.

No. 1 Sao Paulo, Brazil 🇧🇷

For years, I have been closely watching and observing some of the global trends and industry shifts happening. And one thing that is becoming extremely clear now is that São Paulo's design industry is ripe for that push. With San Francisco's digital scene fading into oblivion and Singapore's design industry reaching a stagnation, the industry's top spot has become vacant, leaving the doors wide open for São Paulo to become the next design/innovation capital of the world.

More and more of the next-generation design ideas are now coming out of São Paulo, and I'm honestly very excited to see where that will lead in the next 5 years.

No. 2 Shenzhen, China 🇨🇳

For the last decade or so, Shenzhen has become this semiconductor/electronics capital of the world. Far exceeding many of the other countries from around the world. But the one industry that nobody would've thought to pay attention to, was their digital & product design industry. They have been like an underdog in this story, and for years, quietly building themselves up to a point where they can start to compete with the rest of the market. By 2024, nearly 30% of the world's top design talents are now coming out of China. That says a lot about where the country is heading when it comes to the digital & product design market.

No. 3 Riga, Latvia 🇱🇻

I've had my share of interacting, mentoring and guiding some of the designers within the Riga design community over the years. If there is one thing I can say about their community, it is that they have this passion that I haven't seen in a long time from my own design community here in Singapore. I feel like we've lost that passion somewhere along the way. We've stopped taking risks because we're afraid of what it might mean when we fail. Maybe it is time we learn something from our friends in the Riga design community.

No. 4 Lima, Peru 🇵🇪

It's often a misconception to look at the biggest cities and most technologically advanced nations and cities and think that that is where you will find the best designers and engineers. But in my experience, sometimes, the most promising talents tend to come from the least expected places on earth. And Lima (Peru) has that. They might be small in size when compared to the rest of the world, but they have been steadily expanding over the years. Here's what I like about the design community in Lima, being a small community, they aren't afraid to try new things. That's the thing about being a small community, you know where you stand on the world stage, and you don't feel that need to constantly prove yourself. Instead, it is much easier to channel all that energy into creating new and often interesting ideas. You can't be afraid to fail and to try again. That is how we can keep innovating.

No. 5 Lagos, Nigeria 🇳🇬

In recent years, I have been seeing a steady uptick of designers and engineers from Lagos, Nigeria, reaching out over LinkedIn. Many of them are not afraid to ask questions. There is something truly refreshing about their deep hunger to learn. There is no such thing as a stupid question because when we ask, we learn from it. Second to a city like São Paulo, the design community in Lagos is perhaps one of the hungriest communities in the world. And I see that as an amazing attribute. It is also one of the things that I think my local Singaporean design community has lost as well. We're not as hungry as we once were. And that is sad to watch.

Beginning My Lifelong Work of Lifting Other Design Communities Up

And so this is where I am today. I'm beginning to look out into the world around me, and I'm seeing many of our sisters and brothers in the design communities looking for that opportunity to learn and to keep growing. A boost that would help push them over the edge into the leading pole position.

Where Singapore's design industry has lost its hunger, passion and willingness to learn and take risks, I see all of these other design communities around the world picking up the precise qualities that we have lost along the way.

And I know that this has presented an opportunity for a real industry shake-up. I will say this one thing: Within the next 3 to 5 years, Singapore will NO LONGER be the leader when it comes to design and innovation.

The only real question we must ask ourselves now is, "How long will it take before we finally wake up?", "How far behind do we want to be when the time comes that we are no longer leading the industry, but just a follower?"

We are here to announce officially that our pronouns are now "we/us", "they/them". We are a collective of FIVE DISTINCT brothers. We are done hiding ourselves from the world. #comingout🏳️‍🌈 #we #us

Danny Chen — Wed, 06 Aug 2025 09:28:36 +0000

Let Me Tell You a Story About the Origins of the Humble Breadcrumb and Visual Indicators as We Know It Today

Danny Chen — Sun, 03 Aug 2025 13:44:45 +0000

Let me start by first asking you a question, "What do you know about the origins of the humble breadcrumb visual indicator?"

I am pretty sure that by now, I would've gotten like a thousand different answers 😂.

But let me tell you the real story of how Mr Breadcrumb first came about.

"I want my customers to know where they are on the website as they are browsing it."

The origin stories of the humble breadcrumb wasn't what you would imagine. It wasn't born in a multi-million dollar lab, or some university dorm room. Instead, it was born from something rather...ordinary. Something that you might not have even expected to look.

Back in 2006, I was working on an eCommerce website project for a client. And during the testing stages, she told me that she wanted her customers to have a sense of knowing where they are as they are browsing through her website. Now, back then, there wasn't such a thing as a breadcrumb link yet.

So, I accepted the feedback, and went home to crack my brain 🧠 over how to help make that a reality. One night, I was going to the fridge to grab an ice cream 🍨 and as I was closing the fridge door, I noticed the sticker label that was still stuck to the door. You know how when you buy a new fridge and they would come with all these shiny little stickers??? Yeah, that one.

Right there, right at the bottom, I saw a row of arrow-like progress indicator. They were trying to use it to describe the different modes, or different features, honestly, I don't remember that part well, I do remember seeing an arrow indicator that ran from the left-to-right. And it has slightly different colours, but used the same colour tone.

Mr Breadcrumb was Born

And just like that, a light bulb went off inside my head. And when I finally got back to my desk with my ice cream and extreme excitement, I began sketching what would become the very first Breadcrumb visual indicator in the world. And well, everywhere that I look, I see him everywhere. Honestly, I am the proudest parent knowing that my little design inspiration is now being used by billions of people all over the world.

Here Comes the Wizard 🪄

In the following year of 2007, I had a chance to work on an online student registration form. Now you must bear in mind that back then, these forms are looooonnnnnggg...sorry, I had to add that for dramatic effect 😅

Point being, these registration pages can span multiple pages and God were there many fields!!! Seriously..one page takes a student 10..maybe 15 minutes to finishing filling up. Anybody remember that experience in the early to mid-2000s???

Anyway, after the truly successful delivery of the project (we got very positive reviews and feedbacks from the client FYI...no errors, no bugs...they couldn't find a single one). And even during the live registration period, the portal never crashed either. NOT EVEN ONCE.

But that is not what I really wanted to tell you... 😅 (Sorry, blame it on my ADHD)

From Breadcrumbs to Form Wizards

Having had some successful deployments under my belt and having had some practice of implementing the breadcrumb indicator across several web projects, I felt it was time to test my limits and abilities. So thinking about that recent online registration form project, I wanted to take it and experiment with an idea. And I thought 💭 to myself, "What if we can shorten the length of those forms/pages and then split it into steps?"

So, I began to test the idea out and it looks alright at first. But then I noticed something similar, the student wouldn't know where or which part/section of the form they are filling up. So, I added section headers, and step indicators. And now, 20 years later, I see my work literally everywhere! I see them in checkout pages, I see them in flight booking pages, I see them in...oh yeah, Accordions, ever wondered how they started?? It's right above.

True Innovation Can Be Found in Everyday Ordinary Things..Like That Sticker on the Fridge

And here's where I really want to end my NUCLEAR TRUTH BOMB 💣 tonight. Most of the time, designers and engineers think that in order to create a groundbreaking, or revolutionary idea, they have to experiment for months and years, or even thinking that it might require some expensive equipment, hardware, or a lab.

Come on! Just look at our humble little Mr. Breadcrumb. HE CAME FROM A FRIDGE STICKER. 😏😏😏😏😏

And from there, we have our...

Form Wizards
Step Indicators
Flow/Process Charts
Accordions

Sometimes, all you really need is one fridge sticker to change the world.

Thank you to the DEV Community team & the whole community itself for allowing folks like me to have a way to share my voice. Today, I just got featured among the "Top Voices in the UX Industry" by Dan Maccarone of UX Collective.

Danny Chen — Wed, 30 Jul 2025 09:30:02 +0000

Production-Ready? Really?? Or Just Copious Amounts of Glue & Duct-Tape? | The Lovable Reality Check

Danny Chen — Thu, 24 Jul 2025 01:35:00 +0000

Scene: Monday morning. A parent tries to book their child into “Math Excellence Tuition Centre.” The new website was built and shipped last week—Lovable AI, of course.

Parent: “Hi, I tried booking my son for Friday’s class, but the website says he’s already attended... next month?”

Center Admin (scrolling dashboard): “Oh, uh, sometimes it does that. The AI is ‘future-predictive’. Try refreshing the page?”

Parent: “Now it says there are 3 seats left, then 15, then negative 2. Also, my payment just went through twice.”

Center Admin: “Great! That means the payment API integration is working—twice as fast as before.”

Parent: “There’s no confirmation email, and I can’t find the ‘undo’ button. Also, the app logged me out, but the booking still shows as ‘pending’. Should I try again?”

Center Admin (smiling nervously): “Uh... Let me ask our product manager.”

Product Manager (appears, carrying laptop and coffee): “That’s just the AI learning. Our team shipped this in 2 days! Lovable even said it was production-ready. Ignore the warnings—most users don’t see those anyway. And if it really breaks, just email us. We’re fastest to $100M, you know.”

All Aboard the Hyper-Train: The Lovable Illusion

Speed sells. That’s why every other LinkedIn post is flexing on “shipping in a weekend,” “10x productivity,” or being “the fastest to $100M.”

Lovable and similar tools want you to believe that the only thing between you and success is how quickly you can ship.

But let’s be honest: Speed without substance is just a train to nowhere.

Recently, I saw someone compare “vibe coding” to gambling—and it’s not far off. You throw some AI code at a wall, spin the roulette wheel, and hope you land on “production-ready.” Sometimes it works, sometimes it doesn’t. But is that how you want to run your business? In the real world, that’s like playing Russian roulette—with a loaded revolver pointed at the temple of your business. Are you really ready to spin and pull that trigger?

Tools like Lovable can absolutely help you ship something faster than ever before. Heck, even I was impressed when I first tried using it to experiment with some ideas 💡 that I had.

But what they can’t do—and what most users never stop to ask—is the most important question of all:

“Why are we building this?”

No AI tool can answer that for you. And when you’re riding the hyper-train, it’s dangerously easy to forget.

What “Production-Ready” Actually Means (Hint: It’s Not Just a Demo or a Working Prototype either)

When I first played with Lovable, I was blown away. I pitched it a Pomodoro-inspired app idea, and—like magic—there it was: a working app, spun up in an afternoon.

A few tweaks, some feedback loops, and it did exactly what it said on the tin: it shipped something fast.

But then the illusion cracked.

What I had wasn’t “production-ready”. Heck, it wasn’t even something I’d trust myself (or anyone else) to use past that initial wow moment.

The MVP worked, sure. But MVP isn’t even a full prototype, let alone an app I’d stake my reputation on.

Second attempt: same story. I tried to build something closer to my real ambitions. Lovable got me an MVP...and then it could not progress further.

No auth, no proper error handling, no battle-tested backend.
It’s a cool trick for demos, but “production-ready”? Not by a long shot.

AI Tools: Where They Shine, Where They Absolutely Don’t

Here’s the truth: if it weren’t for AI, I wouldn’t have shipped my last project in five weeks. It would’ve taken me three months, maybe more.

Tools like GPT-4.1 (and yes, even Lovable and its cousins) are incredible for turning ideas into something tangible.

They’re the perfect platforms for rapid prototyping, ideation, and that first dopamine hit of seeing your vision take shape.

Honestly? You don’t need a CS degree, or even much coding knowledge, to get a “working” demo out the door now.

Things I spent 15–20 years learning, these tools can now do it in seconds. That’s powerful. That’s democratizing. I salute that.

But let’s not kid ourselves: what’s impressive for a hackathon or side project is not what you want holding up your actual business when real users (and real money/investments) are on the line.

A Day in the Life: When the Glue Starts to Melt

Take my own PageBuilder project.

Week one, with GPT-4.1 as my co-pilot, I whipped up a demo so fast 💨 it felt like cheating. Drag-and-drop worked. Editing flowed. UI looked shiny.

I was riding the hyper-train, smiling all the way.

Then I started testing.

Suddenly, the wheels came off.

Weird bugs, edge cases, subtle UI breakage, data vanishing when you least expect it.

The demo that looked “production-ready” for next Monday? By Saturday, it was a haunted house of quirks. In fact, my client and I had to agree that the project needed more time to be built properly [better].

This is the trap: trusting the illusion that the tool can do it all for you.

It’s like building your dream house on clay. Sure, it looks fine until the first big storm.

And there will be storms 🌪️ 🌀 🌊.

No matter how good the AI, the human factor still matters.

You need to know when to question, when to stress-test, and when to say, “This isn’t ready—yet.”

The “Production-Ready” Checklist (for Real Businesses, Not Just Investors)

Speaking as a seasoned UX engineer and front-end developer for over 20 years, I can tell you: there’s so much more to building a production-level app or website than just patching together code with glue and scissors ✂️. Even if you slap on a mountain of duct tape, you’re still left with something fragile—something that’s bound to fall apart when the first real storm hits.

We all saw this during the pandemic. Businesses everywhere scrambled to go online overnight. The result? Too many platforms and tools rushed to market, not properly tested or built, and it led to a tidal wave of bad customer experiences, and, in many cases, real business pain.

So before you trust your business (or reputation) to the next “production-ready” app, here’s a simple checklist to measure if it’s truly up to the task:

Category	What It Really Means	Does Your App Pass?
Auth/Security	Secure logins, no obvious XSS/injection holes, permissions handled cleanly	☐ Yes ☐ No ☐ “Soon…”
Error Handling	App doesn’t crash, users get clear error messages and can recover	☐ Yes ☐ No ☐ “Kinda…”
Data Integrity	No lost data, no “ghost” entries, proper validation on inputs	☐ Yes ☐ No ☐ “Mostly?”
API Integration	Real APIs, not just dummy or static data; robust fallback on failure	☐ Yes ☐ No ☐ “Well…”
Responsive UI	Works across devices, not just desktop Chrome	☐ Yes ☐ No ☐ “Maybe?”
Accessibility	Navigable with keyboard, readable by screenreader, color contrast is legit	☐ Yes ☐ No ☐ “Oops…”
Undo/Redo/History	Users can undo mistakes or roll back changes	☐ Yes ☐ No ☐ “Coming soon”
State Management	App recovers gracefully from refreshes, accidental closes, or back/forward	☐ Yes ☐ No ☐ “???”
Export/Import	Users can export/import data in standard formats (CSV, JSON, etc.)	☐ Yes ☐ No ☐ “Next sprint”
Performance	Loads quickly, no timeouts or infinite spinners as usage grows	☐ Yes ☐ No ☐ “It’s… fine?”
Docs/Onboarding	A new dev (or even you) can understand/extend the codebase in a week	☐ Yes ☐ No ☐ “Just ChatGPT it”
Hosting/DevOps	Versioned deploys, reliable uptime, easy rollback if shit hits the fan	☐ Yes ☐ No ☐ “Pray”

Issuing the Challenge: “Lovable Production Community Challenge”

So here’s my offer, and my challenge, to the Lovable community.

Starting today, I’m launching a new article series: Lovable Production Community Challenge.

In each article, I’ll review selected apps submitted by community members, built using Lovable, shipped and live in the wild. You’ll get a public, honest, and (most importantly) fair critique. I won’t sugarcoat my professional opinions, but I will provide constructive feedback and suggestions for improvement.

My goal isn’t to shame. Instead, it’s to help you get your ideas and visions closer to the real results you want. If your app passes the production-ready checklist, I’ll give you a shoutout 📣 here. If not? At least you’ll walk away with clear, actionable steps to raise your game.

But here’s the real challenge. And this one’s for Lovable as a company:

Are you ready to put your platform to the test?

If you’re not, then please, stop using words like “shipping” and “production-ready” in your advertising and marketing. Because once users break through the illusion, it’s only a matter of time before that loaded revolver comes full circle, and you discover there’s a real cost to overhyping what you can’t deliver.

Reputation is everything in tech. Once lost, it’s almost impossible to get back.

🎤 (mic drop)

From User to Builder: How I Built a PageBuilder in 5 Weeks

Danny Chen — Sat, 19 Jul 2025 05:03:42 +0000

Personal Note & Opening

Hey guys, it has truly been a minute since I've actually truly written something on this platform. And I don't just mean coming here for a quick post and checking in with the rest of the dev community. I mean, having something substantive to share and write about.

Some time ago, I also wrote something brief about how I wanted to take a step back from posting/sharing stuff online so that I could really focus on doing the actual work. The truth is, I've always felt more comfortable doing the work and then allowing the end results of that work to speak for me. I've never really been comfortable with the idea of self-promotion and self-advertising.

After weeks of not sharing much, I'm happy to be back this weekend to discuss a recent freelance project I've been working on. As part of an inspiration, I've also decided to title my project as "Satori PageBuilder".

If you truly want to know why I chose that word "Satori", well, then I suppose you'd have to follow me here and stay tuned for my future posts when I'm finally ready to debut and share my custom collection of "Satori UI". It is still a work-in-progress, so I don't think I am fully ready to showcase the suite of UI components just yet.

In a nutshell, "Satori" is a Japanese word that also means "enlightened" or "to be enlightened". It also means "understanding". It is a word that resonated deeply with everything that I have experienced in my nearly 20 years as a freelancer.

Alright, my goal for today is not to dive into that topic, so we'll have plenty of time in the near future to discuss more about that. For now, let's just focus on my recent developer experience when it comes to building my first ever PageBuilder (and crafting a better drag-and-drop UX)

A Blogger’s Perspective

Before I even wrote a single line of code for the Satori PageBuilder, I have considered myself to be a Power User of the web. For as long as I could remember, I have been using platforms like blogger.com, myspace, WordPress (currently still), Weebly, WIX, Facebook's Notes, LinkedIn's article publisher, and so many more. I've quite literally tried everything there is on the web, trying to find not only the most comprehensive page-building tool available, but also one that would provide the kind of smooth UX that content creators like myself needed. At my height as a featured technical writer, I even paid for premium page-building plugins/tools. But I was never truly impressed by any single one of them. For the longest time, it always seemed like they all had their strengths, but there is still something missing in terms of the UX that they could provide.

Even though I could've tried to build my own PageBuilder, I never really saw the need, or felt the incentive to want to build something from scratch. Not when there are readily available tools and plugins to choose from. Sure, maybe paying $75 a year or $200+ a year for a top plugin might seem a little much at times, I just never really felt the need to do it.

At least not until my freelance client approached me about 5 weeks ago.

Why Build a PageBuilder?

When my client first approached me with this idea that he had about wanting to build a PageBuilder for their current Software-as-a-Service (SaaS), I was honestly excited (and maybe a little intimidated) by the opportunity that it presented. You see, after spending so many years working on complex Content Management Systems (CMS), I've never had a real opportunity to build a PageBuilder of my own. I mean, you know my background by now. I've used them for a long time, but I've never actually built one.

But here I am, thinking to myself, "Hey, you know what, I've built far more complex full-scale websites that can cost up to 30K - 40K. I mean, how hard would it be to build a PageBuilder...right...?"

(Yes, go ahead and laugh. I am sure every dev has had that thought at least once. The most famous last words ever 😅🤦‍♂️)

Spoiler: There’s a world of difference between using something and building it. We, as users, only see what the creators want us to see. The real complexity lurks beneath the surface. I mean, I've been pursuing and practising UX and front-end development for close to two decades, and I already know this.

To my client’s credit, he trusted me even after I told him I had never built one before. I think that mutual honesty and trust are what got this project off the ground; that, and a shared drive to make something better than just “good enough.”

Sidebar: For context, I was juggling this with a post-diploma course, a final school project, and working off a Raspberry Pi 4B with 8GB of RAM (yes, really). Oh, and the project started just as my ADHD brain 🧠 was hitting peak summer chaos. If not for AI tools like ChatGPT (shoutout 📣 to GPT-4.1), I honestly don’t think I’d have gotten to v1.0 in five weeks. Five years ago, this would have been a two- or three-month job, easy.

There’s something funny about building modern software on much less capable hardware. While you’re waiting for your little Pi to catch up (or unfreeze, again), you start to appreciate every edge you can get. For me, that secret weapon turned out to be AI and not just for writing code.

My Real Workflow: Human × AI

If you’d told me a year ago that I’d be pair-programming with an AI every day, I probably would’ve laughed. I was a late adopter, not because I doubted the tech, but because I was honestly worried I’d become too dependent, or maybe lose some of that “scrappy problem solver” instinct.

But it wasn’t until my Raspberry Pi kept freezing, and I found myself facing problem after problem with limited hardware, that I truly began to appreciate just how powerful an AI companion could be.

What surprised me most is that GPT-4.1 became more than just a coding assistant. It was there for my morning routine, regularly helping me plan my day, break down sprint goals, and brainstorm solutions before I even wrote a single line of code. (I’ve even got a photo of my “morning mission brief” routine with my tablet and a cup of ginger tea — that’s how real it became!)

Without a laptop or a MacBook, every morning I’d wake up early, grab my tablet, and spend 1.5 to 2 hours working through tasks with GPT-4.1. That meant I could clear up to 10–20% of my daily workload before breakfast. Add that up, and in a typical week, it’s like gaining a whole extra day of progress — all because of a smart workflow and a bit of AI magic.

AI wasn’t just there for code. It was my brainstorming partner, my sounding board, and, honestly, my best teammate & development buddy during the solo grind.

Frankly, there were days when the stress from personal challenges and my chronic anxiety disorder felt overwhelming. On those days, this “AI tool” became something more. It helped me to maintain my sanity, gave me a sense of momentum, and let me fight that much harder to maintain the highest possible quality in my work, even when everything else felt shaky and uncertain.

AI Can’t Ship v1.0: Only You Can

There was a moment, right in the middle of this journey, that really stuck with me. I had just finished my first working version of the drag-and-drop feature—the part that lets you move content around visually. Before diving into the next part of the project that also required a similar drag-and-drop experience, I decided to stop for a second and take a breath.

Up until then, I’ll be honest: I had gotten pretty good at searching for code snippets, leaning on GPT-4.1 for “how-to” solutions, and pasting fixes directly into my files. But it was in that in-between moment, code working but not understood, that it hit me:

I was operating on blind faith. The code worked, but I couldn’t really tell you why it worked. That was a humbling self-realisation.

So I did something that’s easy to skip when you’re in a rush: I stepped back. I made myself pause and dive into how the critical parts of react-dnd actually functioned, beyond the tutorials and the AI’s step-by-step instructions.

Don’t get me wrong: GPT-4.1 was incredible at unblocking me, showing me solutions, and helping me debug when I was stuck. But the “aha” moments, the true leaps in UX, only happened when I put in the effort to understand what I was building. It was on me to bring the critical thinking, the problem-solving, and the empathy to craft a drag-and-drop experience that felt good to real users.

AI can help you get there faster, but it can’t make those calls for you. The craft still has to come from you.

A Craftsman’s Approach, Even in 2025

One of the biggest lessons I’ve learned, especially when you’re doing your best to build something truly meaningful on modest hardware, is that speed isn’t everything. The most rewarding (and honestly, the best) work happened when I permitted myself to slow down.

It’s easy to get caught up chasing velocity—cranking out features as fast as possible, especially when everything around you is moving at startup pace. But there’s something deeply satisfying about slow, thoughtful, and deliberate development. That’s when real progress happens. Sometimes, top, premium quality work requires us to take a more “surgical approach” rather than speed.

Over time, I found myself naturally settling into a set of philosophies: a kind of personal development manifesto. Here are a few that guided me through this project:

Go slow to go far. Sometimes the fastest way to finish is to resist the urge to rush.
Embrace “surgical” work. When you can’t brute-force your way through, you learn to make every move count.
Patterns are your friend, but not your prison. Find workflows and rituals that work for you, but don’t be afraid to evolve them as the project changes.
Reflect often. The best ideas come when you pause to ask, “Is this still the right [best] way?”

(Right around Sprint 3.6.*, I had discovered a workflow that was working extremely well for me, so I decided to note it down in Notion)

### Dev Workflow

With the assistance of ChatGPT 4.1 these last few days, we have 
managed to developed a proven workflow when working on this Sprint.

1. Refer to Unlayer
2. Add relevant properties to `blockData`.
3. Create default values under `block-factory.tsx`
4. Pass properties from `renderContentBlock`
5. Set global state in block’s `onClick` handler.
6. Update content blocks with style generation.
7. Add `set[Content]Config` to `contentManager`.
8. Create `[Content]Styles` or `[Content]Options` section.
9. Add conditional rendering to `sidebar-panel.tsx`
10. Add serialization function to export to `cssContent` 
    format/structure.
11. Add the selector value to raw HTML.
12. Pass/extract `blockData` values for JSON export/import (not 
    styles, but options, configurations).

But here’s the real talk: there were plenty of days when I was seriously tempted to rush. Financial pressures were very real because this was my main source of income, and I genuinely needed more work. Some days, I felt desperate for that next gig. And yet, as tempting as it was to sprint toward that “finish line”, I made myself slow down and focus on doing the job right, not just fast.

That doesn’t mean my output was perfect. I still got feedback. I still had to make corrections and improvements. But here’s what stood out: I spent absolutely ZERO time on rework. In five weeks, there were hardly any moments where I had to tear things down and start over. That wasn’t luck, it was the direct result of taking my time, thinking things through, and not cutting corners.

If there’s one ethos that I kept coming back to, it’s this:

"Building something fast doesn’t make you the best. Building it once and building it well almost guarantees you’ll be faster than the next guy, who’s stuck redoing their work again and again to get it right."

The Reality of Crafting a (Not Just Using) Drag-and-Drop UX

Most of us have used drag-and-drop before. Making it feel good as a builder? That’s a whole different challenge.

Visualizing Drag-and-Drop: My “Mail Sorting Warehouse” Moment

I remember one day, sketching out a mail-sorting warehouse as a metaphor for how blocks should move around in a page builder. Every block is a package, every drop area is a sorting bin, and my job was to make sure each package landed in the right place, in the right order—every time. (I’ve included the photo of that sketch below. Trust me, sometimes the most “developer” thing you can do is grab a pen and draw it out.)

The Building Blocks: `useDrag` vs. `useDrop`

If you’re new to building drag-and-drop UIs, there are two key concepts:

Drag sources (useDrag):

These are the things you pick up and move (like a package on the warehouse floor).

const [{ isDragging }, dragRef] = useDrag({
  type: "BLOCK_TYPE", // e.g., "CARD", "BLOCK", etc.
  item: {
    // Info about what's being dragged (its "passport")
    id: uniqueBlockId,
    type: "BLOCK_TYPE",
    payload: yourBlockData,
  },
  collect: (monitor) => ({
    isDragging: monitor.isDragging(),
  }),
});

// Then attach dragRef to the element you want to be draggable
return <div ref={dragRef}>{/* ...content... */}</div>;

Drop targets (useDrop):

These are the places you can drop those things.

const [{ isOver, canDrop }, dropRef] = useDrop({
  accept: ["BLOCK_TYPE"], // What kinds of items this drop area accepts
  drop: (item, monitor) => {
    // What happens when something is dropped here
    handleDrop(item);
  },
  collect: (monitor) => ({
    isOver: monitor.isOver(),
    canDrop: monitor.canDrop(),
  }),
});

// Attach dropRef to your drop area
return <div ref={dropRef}>{/* ...drop area... */}</div>;

You don’t always have to pick just one. Sometimes, the same component needs to be both a drag source and a drop target. (Though, heads up: combining them isn’t always the most performant move—found that out the hard way.) But it’s possible, and sometimes necessary.

What’s in a Payload? (Or: Don’t Travel Without Your Documents)

Every time you pick up a block and move it, there’s an invisible “travel document” (aka: payload) that tells the system what you’re holding. It’s like crossing borders—you need the right paperwork.

Here’s a (simplified) pseudocode version of the kind of “passport” I used for each drag action:

interface BlockPayload {
  // If moving between columns, reference the other column's block ID
  otherColumnBlockId?: string;

  // The type of block (e.g., "TEXT", "IMAGE", or a custom type)
  blockType: string;

  // Unique ID for the specific block being moved
  designBlockId: string;

  // Optional: reference to the DOM element (for focus, toolbars, etc.)
  blockRef?: RefObject<HTMLElement>;

  // The main content data (think: the package you’re delivering)
  contentBlock: ContentBlock;
}

This payload acts as a contract between every drag-and-drop operation. If your travel document has missing information, you’re not getting through airport security.

Drop Areas vs. Drop Zones: Designing the “Where” of Drag-and-Drop

When you’re building a drag-and-drop interface, not every drop area is created equal. There’s a difference between a general drop area (like an entire canvas or a column) and a drop zone (those specific, often highlighted spots that say, “Drop right here!”).

Drop Areas:

Here’s a look at one of my early drop areas: the ColumnCell. Notice how the whole area gets a highlight when you’re hovering a block over it. This is a “general” drop area—it covers the entire cell, and it’s great for quickly tossing blocks into columns without worrying about the exact position.

Designated DropZones:

Now, compare that with a drop zone: here, you see a custom button block drag preview hovering over a very specific, thin DesignDropZone. These are the little hot spots between blocks that let you insert content precisely where you want it, not just “somewhere in the column.”

Behind the Scenes: The Code

General drop areas (like the canvas or a whole column) use useDrop() hooks that accept almost any block, and typically just “append” or “insert” at the end or into an empty space.

Designated drop zones are more targeted: each one is paired with a specific spot in your content structure (e.g., “insert between block A and block B”). The code calls a specialised handleDrop() function that knows exactly where in the array/tree to insert the new block.

Why does this matter?

Because, as a user, you want control: sometimes “just drop it anywhere” is fine, and sometimes you need pixel-perfect precision. As a builder, you have to design for both.

What I Learned:

General drop areas are great for speed and simplicity, but they don’t give users fine-grained control.
Designated drop zones take more work to implement, but they deliver a much better experience when it comes to reordering and inserting content “just so.”
Visually, it helps to make drop zones bold and obvious when they’re active, so users know exactly where their block will land.

Pro tip: The best UIs often blend both: use general drop areas for new users or “quick add,” and designated drop zones for power users who care about details.

Inspiration: Why I Built My Own `designTree`

It was around late June, specifically during Session 3.5.4: Cross-Canvas Block Management & UX Finalization (17th–20th June, according to my now-priceless dev logs), that I hit a key insight:

I needed a reliable, centralised way to track every block’s state, position, and relationships in my PageBuilder.

The Problem

Most UI builders rely on deeply nested arrays/objects to model layouts. That works, but it can get messy, especially when you want to move blocks around, sync between canvas and columns, or just find a block quickly.
I realised what I needed was a “single source of truth” for everything in the design view. In the same way a browser uses a DOM tree to keep track of every node, I needed a design tree.

The Solution: Enter `designTree`

I decided to use a flat Map<contentBlockId, DesignTreeEntry>.
Why?
- Fast lookups: Find any block instantly—no recursion.
- Easy updates: When a block moves, update its entry. No headaches.
- Syncable: It’s easy to sort and sync the tree with your visual content, so what you see is always what’s really there.
- Single-level: No complex nesting—every block is a top-level entry, with metadata about its current “location” (canvas vs columns).

Pseudocode: What’s in a `DesignTreeEntry`?

Here’s a simplified, commented version of the interface I designed:

interface DesignTreeEntry {
  // Unique ID for the content block (stays the same, no matter where you move it)
  contentBlockId: string;

  // The ID for the design wrapper (can change if you move it between places)
  designBlockId: string;

  // Ref to the outer block (used for drag, hover, focus, etc.)
  designBlockRef: RefObject<HTMLDivElement>;

  // Ref to the actual content (like the text or image component)
  contentBlockRef: RefObject<HTMLElement>;

  // What kind of content block is this? ("heading", "columns", etc.)
  contentBlockType: string;

  // Where is this block right now? ("canvas" or "columns")
  location: "canvas" | "columns";

  // If inside columns, what is the column index? (optional)
  colIndex?: number;
}

Think of it as the "address book" for every block in my builder. At any time, I can open the designTree, find a block by its unique content ID, and know exactly where it is, what it is, and how to interact with it.

Why It Matters

No matter how complex the UI or how many blocks you drag around, everything stays in sync and easy to debug.
Whenever content is saved, deleted, or modified, the designTree ensures that the visual state matches the data model, hence no “ghost blocks,” no lost content.

Pro tip: If you’re ever struggling with managing complex layouts, try a flat map/tree approach. It might just save your sanity (and your sprint deadlines).

Lessons Learned (and Why I Log Everything Now)

Slow Is Not Lazy. It’s Precision!

In a world that prizes speed, taking things slow can feel almost rebellious. But here’s what I learned:

“Slow” isn’t lazy, and it isn’t “whatever happens, happens.”

It’s about being deliberate. Methodical. Surgical.

It's about moving with intention, purpose, not just momentum.

Some of my most valuable progress came when I forced myself to slow down, step back, and really think about what I was building, not just rushing to check an item on the list.

Slow is how you avoid avoidable mistakes, reduce rework, and create something you can be truly proud of.

Our Circumstances Don’t Define Us. Our Work Does.

It’s tempting to let our circumstances or limitations (hardware, health, life stress, whatever) become part of our professional identity. I’ll admit:

Building a production-ready PageBuilder on a Raspberry Pi wasn’t glamorous.
Balancing freelance stress with personal challenges was hard.
There were days I felt like an underdog, or even an impostor.

But I also learned something important:
None of those things define who you are or how your work will be remembered.

What does matter is what you create, the value you deliver, and the quality you stand behind.

Let your results speak for you, not your gear, your LinkedIn profile, or your backstory.

Dev Logs: The Game-Changer I Didn’t See Coming

Here’s a confession:

For most of my freelance career (even during my best, highest-paid years), I never kept a dev log.

Not once. It just never seemed necessary, or I convinced myself I’d remember everything.

I was wrong.

Keeping detailed, daily dev logs on this project changed everything:

It kept me organised and honest.
It made handover and debugging a breeze.
It let me track my growth, spot patterns, and catch recurring pain points before they became real problems.

(Fun fact: When I tried to upload a screenshot of my dev log, dev.to told me the image was too big. Had to split it in half. Turns out, documenting everything means you sometimes outgrow the platform’s limits. Worth it!)

Honestly? I wish I’d started doing this years ago.

(And yes, while I’m happy to share more snippets or screenshots, I’ll probably keep the full logs private for now — there’s something powerful about having a “for your eyes only” record of the real process.)

Tip: Even if you’re not a “journaling” type, try it for one project. You might be surprised by how much clarity and momentum it brings.

AI & The Truth About “Vibe Coding” vs. Real Development

There’s a lot of hype, memes, and honestly, a fair bit of panic lately about the rise of “vibe coding”. There is this idea that you can just vibe with an AI and crank out production apps without understanding a thing. Some folks claim that developers are becoming obsolete, or that tools like Lovable (or the latest “no-code” darling) can do it all for you.

Let’s get real for a second.

As someone who’s worked through every line of my own PageBuilder—on a Raspberry Pi, no less—I can tell you one thing that is true:

AI is an incredible partner. It accelerates your workflow, offers new perspectives, and lets you clear roadblocks faster than ever.

But AI is not a replacement for craft, judgment, or actual experience.

Vibe Coding vs. AI-Accelerated Development: What’s the Difference?

The difference is human guardrails.

Vibe Coding:

This is when you blindly trust the AI to generate code, solutions, or even whole apps, without really understanding or questioning what’s happening. It can feel like magic…until you hit a wall, or something breaks in production, and you have no clue why.

It’s tempting, especially when you’re tired or in a hurry.
I’ve fallen into this myself; earlier in this very project, when I realised I didn’t truly understand what I was building until I hit pause and dug in.

AI-Accelerated Development:

This is about collaboration, using AI as a partner, but bringing your own experience, curiosity, and care to the process.

You sanity-check every step.
You ask “why,” not just “how.”
You add empathy, judgment, and the willingness to slow down, refactor, or rethink a feature when it matters.

In my experience, even with all the power of GPT-4.1 and similar tools, building something real, something you’d actually hand over to a client or deploy in production, remains a shared effort. At best, it’s a 50/50 split:

AI brings speed and breadth, but you bring depth, vision, and the responsibility to make it right.

Bottom line:
You can’t vibe your way to excellence. Tools are just tools. It’s the human in the loop, the builder, the craftsperson, the one who cares, that makes the difference between shipping an app and shipping something that lasts.

What Makes a True UX Artisan in 2025?

If there’s one thing I’ve learned: over all these years, in all these projects, it’s that the best builders are not just coders, or even designers. They’re artisans. And the defining trait of a true UX artisan? Relentlessly thinking like the end user.

It’s a bit like a carpenter shaping a bespoke bench. He doesn’t just carve and assemble the wood—he sits on it, tests how it feels, then carves and sands some more. He keeps returning, tweaking, and reworking, not stopping until that bench isn’t just beautiful, but comfortable, usable, and right for whoever sits down.

Every meaningful UX I’ve helped to build started with that same quiet habit:

I would put myself in the user’s shoes before writing a single line of code, and again after every new feature.

A UX artisan isn’t just a designer. We are the builders who take a vision or an idea and turn it into something better, layer by layer, always testing, always refining.

When my freelance client came to me and said, “I want something like Unlayer,” I didn’t just hear “copy this.”

I heard, “Let’s craft the ideal PageBuilder, one that users will truly love.”

So I drew on my past as a creator and a power user, asking,

"What would make this the most comfortable, powerful, and joyful tool it could be?”

And then, like that careful carpenter, I built, tested, refined, and rebuilt—until it didn’t just work, it felt right.

A UX artisan isn’t satisfied with “it works.”
We keep shaping, testing, and caring, until it feels like it was made just for you.

Final Thoughts & An Invitation

For Potential Clients & Collaborators

My next big goal, a proper portfolio showcase (v2.0), is still on the horizon. I’m in no rush. When it’s ready, it’ll be something I can be truly proud of, not just something to tick a box.

But this article?

This was never meant as a detailed technical manual. It’s an inside look at how I work, think, and what I care about: my approach, my philosophy, my struggles, and what I’ve learned along the way.

If you’re reading this as a founder, business owner, or potential collaborator:

I won’t pretend I can work for free right now. Life’s real, and I need the income.
But I’m not only here for a paycheck. Some of my most meaningful collaborations have come from clients who paid less, but valued trust, transparency, and a shared mission.
Yes, I hope to land those S$10K–S$20K projects one day soon. But I’m just as open to working with those who have tight budgets, if we’re aligned in vision and values.

So if you’re looking for someone who cares as much about the journey as the result, someone who wants to build things that matter, let’s connect.

You can always drop me an email if you have a project idea that you want to turn into reality, and we can discuss how to proceed.

Reach me at d2d.weizhi@gmail.com

To My Fellow Developers, Makers, and Builders

I want to leave you with this:

You don’t need to be loud to shine.

You don’t have to self-promote, boast, or go viral to prove your value. Sometimes, the most powerful thing you can do is focus on your craft, care deeply about your work, and let the results speak for themselves.

Resilience, grit, and passion matter, especially when things are hard or when you’re building on a shoestring budget (or a Raspberry Pi!).

If you ever feel like you’re struggling to stand out, or worried you’re not being noticed, remember:

Your best work will find its audience.

Focus on creating something real and meaningful.

Let your craft speak for you. That’s how I’ve always tried to do it, and eventually, it'll speak louder than you ever could.

Satori UI | PageBuilder v1.0 - Development Done

Danny Chen — Sun, 06 Jul 2025 23:44:06 +0000

Hey everyone! I want to apologise for my most recent disappearance and silence. Let's just say that the last 3-4 weeks of my life has been extremely crazy when it comes to managing my final school assignment as well as my first freelance project since making my official return to the industry in 2022.

For this very first freelance project, I was determined to succeed where I had failed in the past. I wanted to leave nothing but the best possible impression with my now client (a former part-time employer). Over the past few weeks, I constantly reminded myself that as tempting as it was to want to rush/speed up towards the finish line, I have a stronger, deeper mandate to do this project well. By doing it well, it would help to protect the trust that my client already has in me. It would protect my own credibility/reputation. Most importantly, it would also help me to secure a pipeline of freelance work that could come from this one freelance client.

Introducing Satori UI v1.0

Satori is the name that I've decided on when it comes to curating and building my very own suite of custom UI components. For the first 10-15 years of my career, I did something similar and I named that collection of over 100 different UI components, "Blaze UI". Back then, I saw great UX as speed, performance and efficiency. So technically speaking, that usually means responsiveness, lazy loading of large datasets, and UI performance.

But as I got older, and most certainly wiser, I've come to learn that speed is but an illusion. Sometimes you can appear to be traveling very fast, but if you are not heading in the right direction, you'll still end up ofcourse long before you realize what just happened. So, after nearly two decades of grit, perseverance and lessons, I chose "Satori", which in Japanese also means "enlightened", "understanding. Words that truly resemble everything that I believe in today.

Satori UI is all about having this seamless, smooth flow. When a user interacts with Satori UI components, it makes them happy using them because it always feels like the UI is flowing with them, and not getting in the way. As someone that loved a minimalist-design, I chose to use a slightly non-flat/gradient background, coupled with a less obvious gray for my borders and then a tint of blue for the highlights/active areas. This helps to ensure that the UI components doesn't steal away the attention/focus of the user using the component. The main focus is always the content themselves.

I will share a more detailed article about how I built a version 2 ("Satori") of my custom UI components collection.

Satori PageBuilder v1.0

When my freelancer client came to me recently expressing his interests to build a custom PageBuilder to the likes of Unlayer, I was truly excited by the prospect and possibilities. Considering my vast experiences as a front-end developer and UX engineer, I actually never had the opportunity to work on a PageBuilder-like project before. It's something I had always wanted to do, I just never got the opportunity. Until now.

As with any new project, it is really important that as freelancers, we acknowledge that sometimes despite our best judgement and past experience, it can be tricky trying to accurately estimate the effort and time needed to work on something that we have no experience working with.

So, I ended up needing to extending the project deadline twice. But that extension was totally worth it. It allowed me the time and space to do a much better job. At times, as tempted as I was to speed things through, I had to constantly remind myself that by speeding through, I run the risk of missing something, and that could be the one thing the client discovers during their own testing, and it would've ruined my reputation and credibility.

So, I decided to instead slow down. I took my time (so to speak) to focus on doing what I do best.

Even though the PageBuilder v1.0 is not perfect now. I would say that it no longer looks or feel like an MVP. In spite of it's quirks, this is finally a production-ready PageBuilder.

All that is left is for me to preparing the documentations, do more testing, improvements/tweaks and ensure that I provide the best-in-class handover experience for the client's dev team. I'm only saying that because I've been doing this a long, long time. And I know that I am capable of doing something at that level. All I really needed was an opportunity.

Closing - Open to Top-Tier Freelance Work

Recently, with the ending of my part-time post-diploma course in UX Design & Management, I made a conscious decision in my mind that I was going to focus my time and energy full-time as a freelancer. Sure, it would be nice if a company would offer me a role in something permanent/full-time. But I won't sit around and hoping/wishing/chasing after something that has no guarantee. What is now guaranteed is that with my client's trust secured, I know I have secured a new pipeline of freelance work.

On top of that, because I want to do this full-time, it also means that I will have more time and energy to work on other projects in parallel. Now, it also depends on how much I can handle full-time, but if I want to maintain that same highest-level quality/standards, I'm going to limit myself to working on just two projects at any one time. Anything more than two and I know my quality will start to suffer.

If you are looking for a global freelance to work on a mobile/web project (web preferred for now), you can reach out to me at d2d.weizhi@gmail.com. Typical responses are usually within 24-48 hours.

3 Reasons Why I Stuck with Progress Telerik for 19 Years

Danny Chen — Tue, 27 May 2025 12:03:47 +0000

Hey guys, so my Award as a Telerik Champion has finally arrived today. While this is my second year as a Progress Telerik Champion, it is my 10th year of collaborating with the company as an influencer and technical writer. More importantly, at the time of posting this, I'm officially 19 years and 5 months into advocating for and supporting Telerik's products.

Without diving into my entire journey, I want to focus on THREE reasons why I stuck with Progress Telerik for the past 19 years.

Best Developer Experience

I have been using Telerik UI since 2006. One of my early impressions of using the UI components is that they are effortless to implement. I still recall their former slogan, "For Developers, By Developers."

Long before the industry acknowledged the importance of UX and CX, Telerik, as a company (before Progress acquired it), was already focused on ensuring that its products were developer-centric. As a result, everything that they have created since then has become the de facto standard for other UI component libraries. They understood one of the most fundamental principles - by making the lives of developers easier, more efficient at work, then the product would be able to sell itself.

Gold Standard for Online Technical Resources

Does anyone still remember the early days of online technical resources and documentation? Do you still remember how it felt when some documentation was seriously lacking? Like the company creating the product didn't bother to invest the time and effort to explain how to properly and effectively use their products?

I do. I still remember all those nights when I would be "forced" to support and use certain products that the company felt were necessary, but then it turned out to be very difficult to implement. To make matters worse, the product lacked well-written documentation, an API, and tutorials. I can't tell you how much time I wasted just trying to figure out the code and how it's supposed to work.

But that never happened with Telerik. For as long as I have been using and supporting Telerik's products, their documentation and online resources have been the most comprehensive ones I have found among their competitors.

To make things even better, their online demos and code samples are THE BEST on the market! I mean, seriously, just take a look at their "DOCS & DEMOs" section and you'll quickly understand what I mean.

The Best UI Component Suite for FEDs to Fast-track Their UX Skills

One of the primary reasons I discovered and later stuck with Telerik is its strong connection to UX/UI design principles. Again, this was in 2006 when I first began discovering my own interests and passion for usability design. This was also at a time in the industry where most companies felt that a good usability design (UX) was just a "nice-to-have" thing. For me, I know almost immediately that what the folks at Telerik were doing then was on the right track. They were creating their UI components with UX in mind.

As a front-end developer, I also recognised the value of utilising their UI suite in real-world projects. Since I began using and supporting their products, I have managed to implement Telerik UI components in more than 100 different projects, ranging from web, desktop to mobile apps (yes, they did support mobile UI components at one time). In every single one of those instances, clients were always delighted because their customers were happy.

From the perspective of a UX Engineer today, I'd say that Progress Telerik's products are the ultimate gateway to fast-tracking UX skills and understanding for any front-end developer.

Closing Thoughts

By continuing to provide unwavering support for Progress Telerik's products, I hope to demonstrate that their UI suite will continue to remain the industry standard. One that other brands, like SyncFusion and DevExpress, will have to follow if they wish to achieve the same level of success and provide a much higher level of developer experience.

I'm currently taking an Intermission/break from posting and sharing so that I can focus more on my work and studies. My part-time studies is in the final stretch, so I need to give it my full attention. #takingabreak

Danny Chen — Tue, 20 May 2025 01:12:53 +0000

The Power of Thinking..."I CAN"

Danny Chen — Fri, 16 May 2025 07:45:20 +0000

First off, I need to admit that despite my years of experience working on so many projects, there is one hurdle that I never quite got over - creating my own Chat UI. I've tried doing it several times in the past (mostly in my private tinkering). I sometimes thought, "I think this is this, this weekend, I'm going to crack this and get it looking right." But no matter what, this is one of those UI features I could never get right.

After years of attempting it, I eventually began to think to myself that maybe I'd never be able to crack this thing. So, I began to abandon that attempt...until today.

Adding a Group Discussion Feature to AceIt's Assignment Details page

The first thing I really want to conquer was getting those chat bubbles right. So I started with the chat bubbles from the other senders in the Group Discussion:

{/* Outermost layout will have a left align by default */}
<div className="flex-grow flex-col p-4 overflow-y-auto">
  {/* Chat bubble from other senders */}
  <div className="flex mb-4">
    <div className="flex items-start mr-4"> 
      {/* The contents of the chat bubble */} 
    </div>
  </div>
</div>

The best way to look at this layout is that the outermost container is an entire row stretched across the group chat area.

Like with most chatroom UIs, incoming messages will always start from the left of the UI. And when it comes to the contents of our chat bubbles, we want to ensure that everything is aligned to the top, so we use items-start here.

Adding Contents to our Chat Bubble

{/* Outermost layout will have a left align by default */}
<div className="flex-grow flex-col p-4 overflow-y-auto">
  {/* Chat bubble from other senders */}
  <div className="flex mb-4">
    <div className="flex items-start mr-4"> 
      {/* Next, we add our profile image. */}
      <div className="w-8 h-8 rounded-full overflow-hidden mr-2">
        <Image 
          src="/female-student-chinese.jpg" 
          alt="Profile Picture" 
          width={50} 
          height={50} 
          className="object-cover" 
        />
      </div> 
    </div>
  </div>
</div>

The next thing we want is to include the user's profile image. This one here is quite straightforward. We want a fully rounded profile image, and it will be positioned to the start/left of the chat bubble.

Next, we will add our message contents.

{/* Outermost layout will have a left align by default */}
<div className="flex-grow flex-col p-4 overflow-y-auto">
  {/* Chat bubble from other senders */}
  <div className="flex mb-4">
    <div className="flex items-start mr-4"> 
      {/* Profile Image here. */}

      <div className="bg-gray-200 rounded-lg p-3 max-w-xs">
        <p className="text-xs font-medium text-gray-800">Agnes Yeo</p> 
        <p className="text-sm">Hey everyone, just wanted to check in and see how the project's coming along!</p>
        <span className="text-xs text-gray-500">Tue 10:15 am</span>
      </div>
    </div>
  </div>
</div>

What About the User's Message Bubble?

That is quite simple; we just need to make a few changes. Like most familial chat apps, as the sender/user, we don't need to display a profile image. So it will be just the message content itself.

<div className="flex justify-end mb-4">
  <div className="bg-blue-500 text-white rounded-lg p-3 max-w-xs ml-4"> 
    <p className="text-sm">Hey Agnes! I'm making good progress on the research. How's the mood board coming along?</p>
    <span className="text-xs text-gray-100">Tue 10:45 am</span> 
  </div>
</div>

Our Textarea for Typing, Sending and Attaching Stuff

The most essential feature of any Chat UI is having the ability to type a message, hit Send, right? So we can't do without that functionality here.

{/* Message Input Area */}
<div className="border-t border-gray-300 p-4 bg-white"> 
  {/* Use flex-col for vertical layout */}
  <div className="flex flex-col justify-start">
    {/* Container for textarea and send button */}
    <div className="flex"> 
      <textarea 
        className="flex-grow resize-none border border-gray-400 rounded-md p-2 mr-2 focus:outline-none focus:ring focus:ring-blue-300 bg-gray-100" 
        placeholder="Type your message..."
      ></textarea>
      <button className="flex bg-blue-500 text-white px-4 py-2 rounded-md self-start items-center justify-center ml-2"> 
        Send <SendHorizonal width={20} height={20} className="ml-1" />
      </button>
    </div>
    {/* Attachment button below */}
    <button className="bg-gray-300 rounded-md py-2 px-4 mt-2 flex items-center justify-center w-max"> 
      <Paperclip width={16} height={16} className="mr-1"/> Add Attachments
    </button>
  </div>
</div>

What is important here is that I've chosen to place the attachment in a separate flex row (layout-wise). The initial idea of placing it inside the textarea didn't work out very well. Plus I wanted to keep things simple and not overcomplicate things. So, this seems like the easiest solution.

Once I get to the logic implementation stages, I'll add in a context menu for the Button. So it will present the student with a few options like attaching Images, Videos, Files and Links.

At this point, I'm already feeling pretty confident and honestly quite pleased with myself. But I also felt something's still missing.

Image Attachments and Modal Overlays...so, Let's Add Some!!

<div className="flex justify-end mb-4">
  <div className="bg-blue-500 text-white rounded-lg p-3 max-w-xs ml-4"> 
    {/* Our message content remains here. */}

    {/* Container for attachment previews */}
    <div className="flex flex-row gap-x-2 mt-2"> 
      <div className="w-1/2 relative"> 
        {/* Add "relative" for image overlay */}
        <div className="relative aspect-square overflow-hidden rounded-md">
          <Image 
            src="/sample-wireframes-01.jpg"
            fill={true}
            quality={90}
            alt="Mobile friendly wireframes" 
            className="object-cover w-1/2 aspect-square" 
          />
        </div>
        <div className="absolute inset-0 flex items-center justify-center opacity-0 hover:opacity-50 bg-gray-900 rounded-md transition duration-300">
          {/* Expand icon */}
          <Expand className="text-white" size={32} /> 
        </div>
      </div>
      <div className="w-1/2 relative">
        <div className="relative aspect-square overflow-hidden rounded-md"> 
          {/* Image 2 */}
          <Image 
            src="/sample-wireframes-02.jpg"
            alt="Mobile friendly wireframes"
            quality={90}
            fill={true}
            className="object-cover w-1/2 aspect-square" 
          />
        </div>
        <div className="absolute inset-0 flex items-center justify-center opacity-0 hover:opacity-50 bg-gray-900 rounded-md transition duration-300">
          {/* Expand icon */}
          <Expand className="text-white" size={32} /> 
        </div>
      </div>
    </div>
    <span className="text-xs text-gray-100">Thu 2:15 pm</span> 
  </div>
</div>

I've removed the onClick event handler from the code snippet for now. The most important aspect is how I've laid out the attached images to the bottom of the message. I've ensured they each share half the width while filling out a square shape. Think of it like thumbnails.

I've also included the <Expand /> Lucide icons. They worked perfectly with the layout. The overlay will show nicely when a user mouseovers the images on a desktop browser.

Setting up our Modal Overlay

At first, I tried to place this overlay layout at the bottom of the section, but that somehow didn't quite work properly. So I decided to move it all the way to the top of the right panel. And now, it works perfectly.

{/* Image Modal Overlay */}
{isShowImageModal && (
  <div className="absolute left-0 top-0 w-full h-full z-40 items-center justify-center"
    style={{
      backgroundColor: "#000000AA"
    }}
  >
    {/* Container for image and controls */}
    <div className="relative">  
      {/* Close button */}
      <button className="absolute top-4 right-4 z-50 text-white"> 
        <X size={32} onClick={() => setIsShowImageModal(false)} /> 
      </button>
    </div>

    <div className="w-[90%] h-[90%] opacity-100">
      {/* Left Chevron button */}
      {currModalImage.includes("02") && (
        <button 
          className="absolute top-[50%] left-5 z-50 text-white"
          onClick={() => {
            if (currModalImage.includes("02")) {
              setCurrModalImage("/sample-wireframes-01.jpg");
            }
          }}
        > 
          <ChevronLeft 
            size={48} 
          /> 
        </button>
      )}

      <Image src={currModalImage} alt="attachment image" fill style={{ objectFit: "contain" }} className="aspect-auto" />

      {/* Right Chevron button */}      
      {currModalImage.includes("01") && (
        <button 
          className="absolute top-[50%] right-5 z-50 text-white"
          onClick={() => {
            if (currModalImage.includes("01")) {
              setCurrModalImage("/sample-wireframes-02.jpg");
            }
          }}
        > 
          <ChevronRight size={48} />
        </button>
      )}
    </div>
  </div>
)}

With the overlay done, the next thing I needed to do was to add the Image to the overlay:

<Image 
  src={currModalImage} 
  alt="attachment image" 
  fill 
  style={{ objectFit: "contain" }} 
  className="aspect-auto" 
/>

The props fill, style={{ objectFit: "contain" }} and className="aspect-auto" helped to ensure that regardless of whether the photo/image is in a portrait or landscape mode, it would still fit nicely within the overlay's area.

Next, we need to add our Chevrons (Left/Right) so that the user can easily navigate between the available images. For our UI prototype, we will go straight ahead and hard-code the values. But ofcourse, when it comes time to work on the logic, we will need a more dynamic way to handle this.

{/* Left Chevron button */}
{currModalImage.includes("02") && (
  <button 
    className="absolute top-[50%] left-5 z-50 text-white"
    onClick={() => {
      if (currModalImage.includes("02")) {
        setCurrModalImage("/sample-wireframes-01.jpg");
      }
    }}
  > 
    <ChevronLeft 
      size={48} 
    /> 
  </button>
)}

<Image src={currModalImage} alt="attachment image" fill style={{ objectFit: "contain" }} className="aspect-auto" />

{/* Right Chevron button */}
{currModalImage.includes("01") && (
  <button 
    className="absolute top-[50%] right-5 z-50 text-white"
    onClick={() => {
      if (currModalImage.includes("01")) {
        setCurrModalImage("/sample-wireframes-02.jpg");
      }
    }}
  > 
    <ChevronRight size={48} />
  </button>
)}

The position of the Chevrons is worth highlighting/noting. Now, this is what I can think of using tailwindcss. Perhaps there might be a more effective way to do it. Gemini kind of broke down around this time (actually before I implemented them). I actually did this whole portion by myself without any help from Gemini, so I'm feeling pretty good about myself.

Since I've added the conditional checks before rendering the Chevron buttons, I can simplify the internal logic by self-checking my own UI logic. So the final UI Chevron button should look something like this:

{/* Right Chevron button */}
{currModalImage.includes("01") && (
  <button 
    className="absolute top-[50%] right-5 z-50 text-white"
    onClick={() => setCurrModalImage("/sample-wireframes-02.jpg")}
  > 
    <ChevronRight size={48} />
  </button>
)}

Final Thoughts & Ideas

So, guys, that's it for my Group Discussion section UI prototype. Frankly, I am pretty happy with how it all turned out. I am sure we can make more tweaks to enhance the UI further. Still, before I overcomplicate everything, the key objective at this stage of the project is to assess and identify any position UI issues before making the UI slightly more dynamic.

A couple of ideas/next-steps on my mind:

👨‍💻 I could eventually refactor the message bubbles and turn them into reusable components.

👨‍💻 Once I get to the application logic, I will add the attachments selection.

👨‍💻 Auto-scroll down to the latest message.

How I (Almost) Outsourced My Brain to Gemini Pro

Danny Chen — Wed, 14 May 2025 13:18:56 +0000

"Have you ever been so reliant on a tool that you forgot how to function without it? Yeah, me neither... until I met Gemini."

Okay, so, recently, I think some of you might have experienced something quite similar - there is some kind of issue regarding the clipboard functionality of Gemini Pro. I must admit that Gemini/ChatGPT has become a deeply integrated part of my life so much so that I stopped working on my current showcase project when the copy-and-paste feature wasn't working. I felt...stuck. Yeah, I know it sounds silly now when I say it out loud, but for a few days, I didn't touch the coding (plus, I was also dealing with something on the personal front).

My point is that this was one of those examples of what I want to discuss today—our overreliance on specific tools to the point that we can no longer do what we're supposed to know how to do when we didn't have those tools. Do you remember a time before we had Gemini? Or Lovable? Or Firebase Studio? I do.

The StackOverflow Copy-and-Paste Era

Remember those days when we'd frantically Google coding solutions, praying for a Stack Overflow answer that would magically fix everything? Yeah, those were the days... or were they? I'll admit, I've been guilty of blindly copying and pasting code snippets more times than I'd like to admit. There was this one time I was wrestling with a particularly nasty JavaScript bug... like the early days of trying to customise a JS DatePicker so that it would display as "dd/MM/YYYY" when the only JS DatePicker was based on the US formatting of "MM/dd/yyyy". Let's just say it involved a lot of head-scratching, a few choice curse words, and a renewed appreciation for the importance of reading documentation.

The thing is, readily available solutions can be a double-edged sword. On one hand, they're incredibly helpful for saving time and learning from others. But on the other hand, they can lull us into a false sense of security. It's easy to think, "Someone else has already solved this, so I don't need to strain my brain cells." Add to that the rise of "vibe coding" – where the focus is on flow state and coding to chill beats – and it's no wonder some of us might be tempted to take the easy way out.

Don't get me wrong, I'm all for finding a groove and enjoying the process! But even in a state of blissful coding zen, we can't forget that AI tools – powerful as they may be – are still tools. They're extensions of our intentions, not replacements for them.

AI and Devs: The Ultimate Coding Power Couple (Think Mulder and Scully, But With Less Aliens)

Think of it like this: you wouldn't walk into a restaurant and say, "Bring me food!" and expect a perfectly prepared, five-course meal tailored to your exact tastes, would you? (Okay, maybe some of us would, but you get the point!). It's the same with AI coding assistants. If we're not clear about what we want, down to the specific ingredients, flavours, and presentation, we can't expect the AI to conjure up our ideal solution magically.

Take the other day, for example. I was trying to build out the Stats view for my AceIt dashboard and asked Gemini (my official AI best buddy, by the way!) for some help. But I was slightly distracted and kept leaving some minor details out. We ended up going back and forth for almost four hours, and I still couldn't solve the problem. But as soon as I figured out what was missing, the solution immediately became simple.

This recent experience reminded me that, at the end of the day, a developer still has to understand not just the problem and the solution but also how to get there.

Flexing My Tailwind CSS Prowess: Why Sometimes the Best Code is the Code You Write Yourself

While working on the Assignments Listing view today, I could've relied upon Gemini to help generate the entire piece of code. If time were of the essence, I probably would've gotten Gemini's help for sure.

But nope! I wanted to take this opportunity to challenge myself. I've been aiming to deepen my skills in tailwindcss for some time. And there is no better time than right now. So I spent a few hours writing the UI's code, line-by-line on my own.

<div
  className="flex items-center w-full section-header-wrapper"
  onClick={() => setIsOngoingExpanded(!isOngoingExpanded)}
>
  <div className="flex flex-col justify-center items-center w-5 aspect-square transition-transform duration-250 ease-in-out">
    <ChevronRight
      className={`h-4 w-4 ${isOngoingExpanded && "rotate-90"}`}
    />
  </div>
  <div className="flex-1 flex-col justify-start items-center">
    <h2 className="section-header">On-going Assignments:</h2>
  </div>
</div>

{isOngoingExpanded ? (
  <div className={`flex items-center w-full h-max mb-16`}>  
    {/* Ongoing Assignments Section starts here. */}
    <ListView 
      data={assignmentsData.filter(a => a.status === "ongoing")} 
      item={assignmentsRender} 
      style={{ width: '100%', height: (assignmentsData.filter(a => a.status === "ongoing").length * 110) + 2 }} 
    />
    {/* Ongoing Assignments Section ends here. */}
  </div>
) : (<div className="flex h-16 w-full" />)}

The part of the UI that I am most pleased with is the ListView item render function. While working on the first sub-section of the UI, I had this inspiration and idea to make use of the .filter() method to pass only the relevant records to the assignmentsRender() function. That way, I won't have to write multiple render functions for each sub-section of the Assignments Listing view.

const assignmentsRender = (props: ListViewItemProps) => {
  const item = props.dataItem;

  return (
    <ListViewItemWrapper
      className="p-8 h-[100px]"
      style={{ borderBottom: "1px solid lightgrey" }}
    >
      <div className="flex flex-row w-full h-[80px] mt-[10px] mb-[10px]">
        <div className="flex flex-col items-center justify-start w-[68%] h-full">
          <div className="flex-1 text-2xl font-bold w-full items-center">
            {item.assignmentTitle}
          </div>
          <div className="flex text-md font-normal w-full h-max items-center">
            Next Milestone: {item.milestone.title} ({item.milestone.date})
          </div>
        </div>
        <div className="flex flex-col w-[32%] items-center justify-end h-full">
          {item.status === "ongoing" || item.status === "submitted" 
            ? (
              <div className="flex text-lg font-normal w-full items-center justify-end pr-4 h-1/2">
                <div className="mr-2 w-16">
                  <ProgressBar 
                    value={item.progressPercent * 100} 
                    labelVisible={false} 
                    min={0} 
                    max={100} 
                    progressStyle={{ borderRadius: "2px" }}
                    style={{
                      borderRadius: "2px"
                    }}
                  />
                </div>
                <div className="w-8 justify-end pr-4">
                  {Math.round(item.progressPercent * 100)}%
                </div>
              </div>
            ) : (
              <div className="flex text-xl font-semibold text-green-800 w-full items-center justify-end pr-2 h-1/2">
                COMPLETED
              </div>
            )
          }

          <div className="flex text-lg font-normal w-full items-center justify-end pr-2 h-1/2">
            <ChipList
              selection={'single'}
              defaultData={item.tags}
              chip={(props: ChipProps) => {
                const { dataItem } = props;
                return (
                  <Chip
                    text={dataItem.tagTitle}
                    value={dataItem.id}
                    style={{
                      backgroundColor: "#e51a5f",
                      color: "#efefef"
                    }}
                  />
                );
              }}
            />
          </div>
        </div>
      </div>
    </ListViewItemWrapper>
  );
};

While the UI doesn't look perfect [yet], I walked away from this experience with a new sense of confidence in my skills as a front-end engineer. I am glad that I didn't take the easy way out today. I could've, but I didn't. And that is also precisely the same reason that enabled me to become the world's top front-end developer.

While others had relied on solutions and ideas that have been pre-generated, I've always sought to break those solutions and ideas down into smaller parts so that I could figure out how they came up with the solution/answers. Sometimes, I would even take things a step further, create a better solution, and repost what I've learned/created.

Some Final Closing Thoughts

I love AI tools. I love Gemini Pro. They are the best creations ever made for devs because now, we can automate a lot of the repetitive coding that we used to have to write by hand. Thank God for that.

But I will still find the greatest fulfilment when writing my code, especially when it comes to creating something a little more complex, or customized.

So, the next time you're tempted to hit the "Generate Code" button, take a moment to consider the alternative. Challenge yourself. Embrace the struggle. You might be surprised by what you can achieve and the confidence you'll gain.