Topics

The CEO's Slack comments led us to build an AI review web app—and that's when a different challenge emerged

  • column

~ A designer builds an authenticated web app on Cloudflare with AI ~

Hello. I'm Hasshi, a UI designer.

Recently, instead of the traditional flow of creating wireframes and getting client approval, I've been increasingly using AI to create mockups of landing pages and websites for client review.

Until recently, when getting design feedback, I'd receive Slack comments like:

"Please expand the whitespace here!" "Replace this image!" "Change the text here!"

That was the typical pattern.

On the surface, it seemed like a normal approach.

In fact, it worked fine that way until now.

But once I started rapidly creating prototypes with AI, a particular problem became much more apparent.

Comments flow continuously.

Slack is convenient.

It's convenient, but of course it's not a dedicated design review tool.

Regular work updates, casual chat, consultations about other projects—everything flows into the same place.

As a result,

  • revision comments get lost in other conversations
  • threads proliferate
  • you end up asking "where was that fix again?"
  • conversations shift to completely different topics before you realize it

—and all of this happens.

Slack screen

Slack also has a list feature.

Slack list feature screen

I've also written an article before about process improvement using Slack templates.

Getting Started with Slack Templates for Easy DX | Topics | Liberogic

However, thread notifications can be confusing, and when you integrate notifications, the message area gets cluttered...

In the end,

the chat area just keeps getting busier and busier.

The speed of creating LPs with AI increased many times over, but the review process remained the same as before.

Even if generation becomes faster, if we get stuck in the review stage afterward, it feels wasteful.

So I thought about it.

What if we could write comments directly in the HTML?

While working on a landing page, I had a thought.

What if you could write comments directly on HTML generated by AI prototypes? Better yet, what if you could bundle comments and attached images into a ZIP file and pass them directly to AI tools like Claude Code or Codex?

Adding red marks to screenshots is clear, but being able to review the HTML itself would be even better.

  • Clicked location
  • CSS selector of the target element
  • Nearby text
  • Page name
  • Attached reference image

and more can be saved together.

In other words,

Instead of "fix this," you can say "modify this HTML element this way."

This also seems to work well when asking AI for corrections.

"Isn't this incredibly useful?"

That's when we started building

Design Marker (LP Red-ink Checker)

.

Just gave it a shot

The initial version was a local application that ran on our own computer.

It's simple to use.

  1. Package your HTML files into a ZIP
  2. Drag and drop into Design Marker
  3. View the HTML from the ZIP in your browser
  4. Click on the area of interest
  5. Write a comment
  6. Export a review ZIP with comment information included
  7. Pass it to AI like Claude Code or Codex for corrections

You can comment directly on HTML just like drawing red lines on a screenshot.

If we had tried to build something like this years ago, it would have taken days.

As we were building it,

comment lists, assignee names, jump to comment location, image attachments, merging multiple reviews...

we kept thinking 'we want that too' and 'we want this too,' and the features grew little by little.

From around this point,

Wait, this is actually pretty handy as an internal tool, isn't it?

And that's when I started getting more confident about it.

The synergy with AI exceeded my expectations.

When I built Design Marker, what impressed me most was how well it integrated with AI.

When you ask for edits in a regular chat, instructions tend to be vague—

"Please make the image in the top left a bit larger."

That sort of thing.

Humans can figure it out by looking at the screen, but for AI, "top left" and "the image" become ambiguous—it's unclear which element is which.

With Design Marker, when you click on an HTML element, you can retrieve a CSS selector like this, for example:

article.strength-item:nth-of-type(1)
 > div.strength-visual-wrap
 > div.illustration-slot

Then you pass it to the AI—

Please enlarge the illustration in article.strength-item:nth-of-type(1) to approximately 115% of its current size.

You can give instructions in that format.

As long as the DOM structure hasn't changed significantly, you can pinpoint the correction target quite precisely.

You can even pass along the page name, nearby text, comments, and reference images all together.

Until now,

No, no, that's not the right spot!

corrections that used to require multiple back-and-forths with AI now land in the intended location on the first try.

"Reviewing with HTML" seems like it works really well with the AI era, doesn't it?

I felt real momentum at that point.

I thought, "This is useful!" and shared it with the team

Great.

This is convenient.

Let everyone use it too.

I eagerly shared it across the team.

Then...

It doesn't work? What is this, my settings?

Ah...

That's right.

It works on my computer.

But,

It won't run on most people's computers as-is.

A classic local app problem—we hit it head-on.

I can use it. But most people can't.

Since I'm the one developing it, of course it works.

But for others to use it, they needed to install Node.js and set up dependencies.

For someone familiar with development, it's not that difficult.

But for designers and directors,

First install Node.js

—that's the kind of review app it was.

It was no longer a casual review app.

So,

"Why not make it launch with a single click!"

I thought, and created a launch file called start-mac.command.

When you double-click it,

it launches the terminal, performs the necessary setup, starts the app, and even opens the browser.

Perfect.

Or so I thought.

But when I think about it rationally,

"Please double-click this unknown .command file"

is a pretty intimidating instruction to give.

So I'm supposed to send it to the CEO and say "Just double-click this for now!"? That seems sketchy. I made it myself, and it still seems sketchy.

I did manage to build something that works, but it didn't become the go-to tool for sharing within the team.

When you're building an app alongside AI,

"it works on my machine, but other people can't use it"

—a wall that's apparently all too familiar in development—you hit it without fail.

A senior engineer's insight

Then a senior engineer offered some advice.

Why not just create a README and have people load the folder into Cloud Code, then follow the README for setup?

……

I'd been adding features to make it more convenient, but for people who can use AI, that approach was dramatically simpler.

Rather than trying to solve everything on the app side,

Think about the easiest way for users and AI together.

That was a learning experience for me too.

But the CEO won't write comments.

I made a README too.

I simplified the startup process.

This should work.

...or so I thought.

But then.

Radio silence.

The CEO is busy, so he doesn't pay attention to me...

That's when something even more important became clear to me.

Building a review app is one thing, but

getting people to actually use it

is orders of magnitude harder.

No matter how convenient the app is locally,

"launching the app"

becomes that crucial first step.

For busy people, even that first step can feel like a barrier.

So then...

why not make it web-based?

If we just need users to click a URL, wouldn't that be easy to use?

With that in mind, I decided to build a web version of Design Marker.

First, I'll build a pre-login page to boost my motivation.

There's a lot I'd like to build, but there are so many things to think about, so for now it's an AI-generated landing page.

I thought about how to handle the backend. That's when I chose Cloudflare.

But I'm a designer, after all.

Cloudflare Pages、Pages Functions、Cloudflare Access、D1、R2……。

Even though I'd heard the name, this was my first time actually thinking through the architecture myself and building it as a web application.

Now it's time for my AI teacher to shine.

I want to build an internal admin panel and a review screen to share with clients.

For the admin panel, there's an option to use Cloudflare Access.

What about comments and project information?

You can save it to D1

What about ZIP files?

There's a way to use R2

I see. I think I understand everything now!

...or so I think.

AI really is impressive.

If you ask it, it will explain quite specific architecture.

But what I felt strongly during this development was that,

AI teaching you how and building a secure system are two different things

That's what it was.

From "Tell me" to "Is this understanding correct?"

Especially for security-related parts, I'm hesitant to rely solely on AI responses.

That's why I decided to have senior engineers review the parts I didn't understand and the critical sections.

If it were the old me,

I want to do something like this with Cloudflare. How do I do it?

That's where I would start.

But then my senior would have to explain everything from scratch.

When they're already busy,

"Senior! Please teach me from the beginning!"

and just charge in.

This time, I worked through my thoughts by exchanging ideas with AI multiple times.

And then,

Restrict the admin panel to internal team members only via Cloudflare Access. The shared dashboard uses project-specific URLs with ID and password login. Store project information and comments in D1, and project assets (LP ZIP files) in R2. Is this understanding correct?

up to that point before consulting.

In other words,

"Please explain"

but rather,

"Is this understanding correct?"

shifted to.

This was a significant change for me.

Communication with senior colleagues became minimal, allowing them to focus their time on areas that truly needed review.

I stopped simply copying AI responses and moving on,

"Why do we do it this way?"

and began progressing through the work while gradually understanding the reasoning.

Moving to Web revealed another set of challenges

This is how the Web version gradually started working.

You can open it just by sending a URL.

It's far more user-friendly than a local app.

"Wouldn't this solve it?"

Or so I thought.

The moment we moved to Web, issues that we hadn't really noticed in the local version surfaced all at once.

For example,

  • Should client pre-launch LPs be stored in the cloud?
  • Who can view which projects?
  • How should passwords be protected?
  • How can unauthorized login attempts be prevented?
  • Can uploaded HTML be displayed safely?
  • When should project data be deleted after completion?

and so on.

Adding a single authentication screen does not mean security is fully addressed.

It goes without saying, but only after building it myself did I truly understand how heavy the responsibility is.

We currently implement basic mechanisms including Cloudflare Access, project-specific login, and storage in D1 and R2.

On the other hand,

We've enhanced password protection, implemented login attempt limits, separated HTML previews, and established data storage and deletion rules—but there are still improvements we'd like to make before full public launch.

Design Marker also includes a mode where ZIP files aren't stored in the cloud—only reviewed within your browser.

Project information and ZIP files are stored in the cloud only when necessary for sharing projects.

Design Marker is not yet an official service.

We're currently in the validation phase, focusing on internal use.

In other words, what we've built is

"a completely secure service that's finished!"

—that's not what this is.

Rather,

an application in development, where we're learning what needs to be protected and implementing necessary safeguards one by one

.

Going digital isn't just about convenience.

With it comes the responsibility of safeguarding user data.

This project taught me a great deal.

The completed design tool's admin dashboard.

From the dashboard, employees can review all feedback and revision requests.

Opening the detail page shows a structure proposal with quick links—allowing direct LP review and commenting.

You can also view LP-related comments in this view. Since previous comments are accessible too, design revisions became much smoother.

Even with AI, learning was essential.

Throughout this development, I felt one thing very strongly.

Thanks to AI, designers now find it much easier to tackle development than ever before.

I myself,

"I want to build this"

to something that actually works has clearly expanded.

But that didn't mean

"you don't have to study anymore"

.

It was quite the opposite.

This configuration is recommended

Got it!

alone is risky.

What we really need is

"Why?" "Is that good enough this time too?" "Are we missing something?" "Shouldn't we have an expert review this part?"

is what we found.

The knowledge to judge whether AI's proposal meets the requirements and identify what's missing is essential.

AI is truly a reliable partner.

But ultimately, humans make the final decision and take responsibility.

This web implementation of Design Marker has been an opportunity to reconsider how we work alongside AI.

What changes most in the AI era might be the review process

AI can create a landing page in just minutes.

What used to take hours to rough out now arrives remarkably quickly.

But then afterward,

"Make this adjustment here" "Expand this whitespace a bit" "Change just this image"

—these kinds of exchanges haven't really changed much over time.

Only the production speed increased,

humans verify the work, communicate the requested changes, and have it remade.

This part is still quite human-driven.

That's why lately,

it's not just AI itself,

how AI and humans interact with each other

that I believe will become increasingly important.

Design Marker is one of our experiments to address this.

Now I

We're exploring HTML comments, image attachments, integrated multi-user reviews, and version control per project.

There's still plenty more we want to build.

Direct markup on screenshots themselves.

Requesting AI-powered corrections from comments.

Improved version comparison.

Enhanced usability for multi-user reviews.

And of course, improved security for authentication, HTML preview, and data management.

Our plan is to start using it internally and improve it step by step.

Initially,

"Slack comments move so fast, we need to do something about it"

That's how a small tool was born.

Before we knew it,

we built a desktop app,

the CEO didn't use it,

we moved it to the web,

we studied Cloudflare,

we wrestled with security,

we consulted with senior engineers,

and ended up thinking about how to work with AI.

I just wanted to build a simple review app, but there turned out to be a lot more to think about.

But I find it interesting that I can now take small inconveniences from my own work and shape them into something real with AI.

Once I've developed it to a point where it's safe to release publicly, I'd like to formally introduce Design Marker.

But first.

I need to get the CEO to actually write proper comments first (laughs). But for now, it looks like I'll be able to enjoy some good drinks today.

About the author of this article

UI design is constantly evolving! I'm working through how to integrate accessibility into LP design. I've been stepping away from markup lately and wondering if I should level up my JavaScript skills too. I'm a fan of Takumi Kitamura!

Hashy

Web Designer / Joined 2018 / Still a beginner at heart

Read this staff member's article

Reliable team structure and responsive project management are our strengths

At Liberogic, our experienced staff actively drive projects forward, earning high praise from clients.
We carefully assign project managers and directors to ensure smooth project execution across all phases. We prevent unnecessary cost increases from over-commitment by deploying resources strategically, and we're known for speed in project understanding, estimation, and delivery.

* Please note that we do not actively pursue on-site SES-style staffing arrangements.

You can use virtually all major project management and chat tools, including Slack, Teams, Redmine, Backlog, Asana, Jira, Notion, Google Workspace, Zoom, Webex, and more.

Tell us about your web concerns.

Case Studies