Frontend Is Easy… Until You Actually Build Something
It Was Just a Checkbox. Until It Wasn't.

Search for a command to run...
It Was Just a Checkbox. Until It Wasn't.

No comments yet. Be the first to comment.
Disclosure: This case study is anonymized. Product branding, source code, production screenshots, employee and candidate information, internal architecture, commercial details, and performance metrics

Maybe your friend isn't the only one who overthinks.

Every frontend developer has heard some variation of these.
"It's just a screen."
"Backend does the real work."
"AI can generate that."
"Just use ShadCN."
"Just copy the component."
"It's just a checkbox."
And every frontend developer silently smiles because they know where this story is headed. Because somewhere, deep inside Jira, a "simple checkbox" is preparing to ruin someone's week.
People outside frontend often imagine our job like digital LEGO.
| Problem | Solution |
|---|---|
| Need a modal? | Copy one. |
| Need a button? | ShadCN has it. |
| Need a table? | AI can generate it. |
| Need a form? | There are 37 libraries for that. |
Everything looks simple. Until somebody says:
"Can we add a checkbox?"
And suddenly four days disappear from your life.
Ask me how I know.
At my previous company, we were building a project management platform for a large auditing firm.
One day our PM asked for a checkbox on a senior consultant's dashboard. PM said:
It's just a checkbox. You can probably do it in two hours. In fact, I'm giving you the whole day so you can test it too.
According to her, she was being generous.
Honestly, I thought the same.
How hard could a checkbox be?
My assumptions needed debugging.
Turns out the checkbox wasn't for every senior consultant.
It should only appear if:
The project is from a certain type of client, OR
The project is from the clients having ARR above the given limit.
The project is active.
The project belongs to a specific category.
The consultant is actually responsible for that project.
And few other client and project related checks.
Okay.
Not terrible.
Just some filtering and conditions.
Still sounds like a checkbox.
Right?
Wrong.
Checking the box wasn't the real feature.
The checkbox created a request that needed approval from the consultant's senior manager.
Now we're talking about:
New API endpoints.
New request states.
Approval workflows.
Error handling.
Loading states.
Notifications.
Funny enough, the checkbox itself became the least interesting part.
Then another requirement appeared.
Senior managers didn't want requests piling up when they weren't around.
So the checkbox should only be visible when the corresponding manager was currently using the application.
Wait… what?
Not online recently.
Not active today.
Actively connected.
At that moment.
Because if the manager wasn't available, consultants shouldn't create requests that would just sit there.
Which meant we needed real-time presence.
Not for chat.
Not for notifications.
For a checkbox.
Computers are fascinating and mildly offensive.
By this point, we had:
Modified database models.
Added new API contracts.
Introduced new frontend states.
Defined new data flows.
Added presence tracking.
Maintained socket connections.
Managed synchronization between users.
Tested edge cases.
Handled loading, errors, and race conditions.
And somewhere in the middle of all that…
There was a checkbox.
Thirty hours later, the feature was done.
Not because drawing a checkbox takes thirty hours.
Because business rules do.
Frontend isn't difficult because buttons are hard. The complexity comes from translating human requirements into behavior.
Every "simple" feature eventually turns into:
"What if this happens?"
"What if they're offline?"
"What if two people click simultaneously?"
"What if permissions change?"
"What if the API is slow?"
"What if the socket disconnects?"
"What if this user shouldn't even see the button?"
The UI is where all these questions become visible.
Backend systems have complexity.
No doubt.
But frontend has to absorb complexity coming from users, business rules, permissions, accessibility, responsiveness, loading states, and the beautiful chaos known as changing requirements.
And unlike backend, everyone sees frontend. Which means everyone has opinions about it.
Including people who think AI can replace it because it generated a pretty card component once.
I love ShadCN. And use AI daily.
Component libraries are amazing. They remove boring work.
But they don't solve business problems.
ShadCN gives you a checkbox.
It doesn't tell you:
Who should see it.
When it should disappear.
Which projects qualify.
How approvals flow.
How real-time presence works.
What happens when connections fail.
How state should synchronize.
The hard part was never drawing the box. It was understanding what the box actually meant.
AI is fantastic at producing buttons, forms, and layouts.
But business logic lives inside conversations, assumptions and requirements nobody mentioned until Wednesday afternoon.
And every frontend developer knows this magical sentence:
"Oh, one more thing…"
Those four words have probably consumed more engineering hours than TypeScript errors.
Honestly?
Yes.
Right up until you actually build something. Then you realize frontend isn't about pixels. It's about translating human chaos into something people can click. And somehow making it feel simple.
Maybe that's why the best frontend work looks easy.
Not because it is.
But because somebody spent four days making a checkbox feel like a checkbox.
And honestly, that's the fun part.