DEV Community: 박준희

How to Hide Unnecessary UI Tabs in the Frontend

박준희 — Mon, 13 Jul 2026 16:00:01 +0000

In my Image Studio app, there was a prominent "Portrait Preservation Edit" tab. Turns out, it was a feature I either wasn't using or wouldn't be using soon. Such unnecessary UI elements just clutter the experience and confuse users. I wrestled with how to hide it, and finally, I cracked it.

Attempts and Pitfalls

My first thought was, "Can't I just block the rendering logic for that tab?" So, I modified the code to skip rendering if a certain condition wasn't met when the component mounted.

// App.js
import React, { useState, useEffect } from 'react';
import FeatureTab from './FeatureTab';

function App() {
  const [showEditTab, setShowEditTab] = useState(false);

  useEffect(() => {
    // In a real scenario, this would be determined by a backend API call, etc.
    const isFeatureEnabled = checkFeatureStatus('Portrait Preservation Edit');
    setShowEditTab(isFeatureEnabled);
  }, []);

  return (
    <div>
      {/* Other UI elements */}
      {showEditTab && <FeatureTab title="Portrait Preservation Edit" />}
      {/* Other UI elements */}
    </div>
  );
}

function checkFeatureStatus(featureName) {
  // Dummy logic: This should be determined dynamically in reality.
  // For example, it depends on current user permissions, service settings, etc.
  // Here, we'll hardcode it to false for testing to hide the tab.
  console.log(`Checking status for: ${featureName}`);
  return false; // Setting to false to test hiding the tab
}

export default App;

But here's the kicker: no matter how much I set setShowEditTab(false), the tab refused to disappear. The console dutifully showed Checking status for: Portrait Preservation Edit, but the UI stubbornly displayed the tab. After three hours of debugging, I finally discovered the culprit: another component was directly controlling that tab.

The Cause

The problem was that besides managing the state and controlling rendering in App.js, another component was directly controlling the tab using the visibility property. It was like a parent saying "no," but the child defiantly saying "yes" anyway.

// SomeOtherComponent.js (The problematic component)
import React from 'react';

function SomeOtherComponent() {
  return (
    <div>
      {/* ... */}
      <div style={{ visibility: 'visible' }}> {/* <-- This was the issue! */}
        {/* Portrait Preservation Edit tab content */}
        <h1>Portrait Preservation Edit</h1>
        <p>This tab should always be visible.</p>
      </div>
      {/* ... */}
    </div>
  );
}

export default SomeOtherComponent;

Even though App.js set the showEditTab state to false, the style={{ visibility: 'visible' }} in SomeOtherComponent.js was forcing it to be displayed.

The Solution

The simplest and most straightforward solution was to remove the visibility property from that tab in SomeOtherComponent.js and unify the rendering logic under the showEditTab state managed in App.js.

// App.js (After modification)
import React, { useState, useEffect } from 'react';
import FeatureTab from './FeatureTab';
import SomeOtherComponent from './SomeOtherComponent'; // Import SomeOtherComponent

function App() {
  const [showEditTab, setShowEditTab] = useState(false);

  useEffect(() => {
    // In a real scenario, this would be determined by a backend API call, etc.
    const isFeatureEnabled = checkFeatureStatus('Portrait Preservation Edit');
    setShowEditTab(isFeatureEnabled);
  }, []);

  return (
    <div>
      {/* Other UI elements */}
      {showEditTab && <FeatureTab title="Portrait Preservation Edit" />}
      {/* Remove the tab rendering logic from SomeOtherComponent */}
      <SomeOtherComponent />
      {/* Other UI elements */}
    </div>
  );
}

function checkFeatureStatus(featureName) {
  // Dummy logic: This should be determined dynamically in reality.
  console.log(`Checking status for: ${featureName}`);
  return false; // Setting to false to test hiding the tab
}

export default App;

// SomeOtherComponent.js (After modification)
import React from 'react';

function SomeOtherComponent() {
  return (
    <div>
      {/* ... */}
      {/* Removed the visibility: 'visible' property */}
      <div>
        {/* Portrait Preservation Edit tab content */}
        <h1>Portrait Preservation Edit</h1>
        <p>This tab is controlled by App.js.</p>
      </div>
      {/* ... */}
    </div>
  );
}

export default SomeOtherComponent;

Now, if showEditTab in App.js is false, the "Portrait Preservation Edit" tab completely disappears from the UI.

Results

The "Portrait Preservation Edit" tab is no longer visible in the UI.
The rendering logic is unified in App.js, making it easier to manage.
User confusion has been reduced.

Takeaways — Avoiding the Same Pitfall

[ ] When controlling the visibility of a UI element, ensure it's not being controlled independently by multiple components.
[ ] State management logic should be handled consistently, preferably in parent components or through a centralized state management library.
[ ] During code reviews, meticulously check if CSS properties like visibility and display are unintentionally forcing UI elements to be visible.
[ ] Design the system so that feature activation/deactivation states are dynamically determined by backend APIs or clear configuration values.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

Dev.to Markdown Tables/Bold Broken? Fixing the `markdownify` Double Processing Issue

박준희 — Sun, 12 Jul 2026 16:00:02 +0000

I had a bit of trouble with Markdown tables and bold text getting messed up on Dev.to. It was pretty annoying to see my posts come out all jumbled every time I published. I wanted to share how I solved this issue.

Attempts and Pitfalls

When I tried to publish my posts on Dev.to, the tables and bold text I wrote in Markdown weren't displaying correctly and were showing up broken. At first, I thought I had written the Markdown syntax wrong and double-checked it multiple times.


| Header 1 | Header 2 |
|---|---|
| **Bold Text** | Some Data |

Even with a simple table and bold text like the above, it looked strange on Dev.to. It was definitely rendering fine locally.

It seemed like there was some kind of post-processing happening on the server that was handling the Markdown again. So, I started suspecting that if I was using a library like markdownify, maybe it was being processed twice.

The Cause

In the end, the problem was with the content_en field. This field already contained the content in Markdown format, and I was processing it again with markdownify, which caused a double Markdown conversion. Since it was already Markdown, trying to convert it to Markdown again messed up the syntax.

The Solution

The fix was simple. I modified the logic to use the content_en field directly if it was already in Markdown format, instead of reprocessing it with markdownify.

# Original code (assumed)
# content_en = "..." # Already in Markdown format
# processed_content = markdownify(content_en)

# Modified code
content_en = "..." # Already in Markdown format
if not is_already_markdown(content_en): # In reality, you'd need logic to check the format of content_en
    processed_content = markdownify(content_en)
else:
    processed_content = content_en

# When applying this in practice, it might vary depending on what values the content_en field holds
# and how a function like is_already_markdown is implemented.
# The important thing is to avoid extra conversion when it's already Markdown.

By skipping the markdownify processing for data that was already in Markdown format, the issue was resolved.

Results

Markdown tables in posts published on Dev.to are now displayed correctly.
Text formatting like bold and italics is no longer broken and appears as intended.
I no longer spend time worrying about my content breaking after publishing.

In Summary — To Avoid the Same Pitfall

[ ] When using Markdown conversion libraries, make it a habit to check if the input data is already in Markdown format.
[ ] Clearly understand the format of data stored in fields like content_en and design your processing logic accordingly.
[ ] Double processing is a common culprit for unexpected bugs. Always pay close attention to your data flow.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

How Far Can Local AI Go with Just a CPU — Building Auto-Tracking and Benchmarking Loops, and My Conclusions

박준희 — Sun, 12 Jul 2026 09:46:30 +0000

Local AI on CPU Without a GPU: How Far Can It Go? — Building an Auto-Tracking, Benchmarking Loop, and the Conclusions I Reached

Riel's chat runs on a cloud API (Google Gemini). For a while, though, I've been stuck on the hypothetical: "What if I couldn't use this API?" Whether due to model export regulations or policy changes, I wanted to build a minimal Korean chatbot fallback that runs solely on my home desktop in case external AI access is cut off. This post is a record of how far I pushed this on CPU-only, without a GPU, and why it's no longer my primary solution.

The Condition: Effectively No GPU

My desktop has a Ryzen 5700X (8 cores, 16 threads), 32GB RAM, and an RX580 4GB for graphics. The problem is, the RX580 (Polaris) doesn't support the latest ROCm, meaning I can't properly use the GPU for local LLM acceleration. Plus, 4GB isn't enough to load a 7B model entirely. In the end, the actual engine was the CPU. "How far can I go without a GPU, on CPU?" was the real question from the start.

What I Built — A Loop of Measuring, Tracking, and Self-Replacement

I didn't want to just run a model and call it a day. My goal was a system that could automatically swap out models for better CPU-compatible ones when they become available, even if I miss it.

Bench Harness — I created Korean auto-grading questions (math, multi-step reasoning, logical negation, unit conversion, facts, instruction following) to measure accuracy and speed (tok/s). It started with 8 questions, but they lacked discriminative power (more on this later). I increased it to 25, then to 50 questions.
Automatic Tracking of New Hugging Face Models — I detect new releases from manufacturers (EXAONE, Qwen, Google, etc.) on a weekly basis and add them to a candidate queue. Initially, I scraped "trending" models, which brought in a lot of 2023 community fine-tunes. I refined this by using a watchlist of authors + filters for size and family to cut down on noise (from 78 candidates down to 24).
Autonomous Benchmarking Loop (auto_bench) — My desktop automatically pulls new models from the queue, runs the 50-question benchmark, and uploads the results to a server. The server then automatically replaces the currently serving model if the new one is definitively better (either in accuracy margin or speed advantage). This loop actually discovered and swapped in models I hadn't explicitly scouted.
Public Demo (/local-ai) — Using an outbound polling worker structure that doesn't open any inbound ports on my home network, anyone could experience this CPU model while my desktop was on. ## Actual Measurements — And the Moment the Illusion Broke Final scoreboard (my desktop, CPU) based on 50 questions:

Model	Accuracy	Speed
`exaone3.5:7.8b`	90%	14 tok/s
`exaone3.5:2.4b`	84%	53 tok/s
`qwen2.5:3b`	84%	43 tok/s
`gemma2:2b`	76%	31 tok/s

The biggest takeaway here was how much the measurement design influences the conclusion. gemma2:2b initially scored 100% on the first 8 questions, making it seem "the best." But as I increased the question count, its score dropped continuously from 84% (25 questions) to 76% (50 questions). It was an overestimation caused by easy questions. Conversely, the value of exaone 7.8b only became apparent with harder questions (it tied with 2.4b on the initial 8 questions). Seeing rankings remain stable even with an expanded sample size finally became a mark of true reliability.
Ultimately, the optimal balance for CPU serving was exaone3.5:2.4b (84% accuracy + fastest).

Why It Stepped Down From Primary Use

To be honest, the engineering was successful, and that's precisely what clearly showed its limitations. The auto-tracking -> auto-benchmarking -> auto-replacement loop actually works. However:

The capabilities of models runnable on CPU (roughly 2~8B parameters) are about GPT-3.5 level. The gap is too large to replace the latest cloud models Riel's chat uses.
The realistic answer to "local AI gets better on its own" isn't that models inherently become smarter (weights are fixed), but rather that they detect new models and replace them with better ones. But the ceiling for that replacement is inherently low.
To reach true API-level performance, you need a GPU (which means money). I decided not to make that investment at this stage. So, local CPU AI has been demoted from primary use to a "fallback and experimental demo" status. The /local-ai endpoint is still alive, allowing direct experience if my desktop is on, but it no longer handles Riel's actual responses. ## What Remains (Lessons Learned)
Measurement comes first. That 100% on 8 questions was an illusion. If your yardstick is flimsy, you'll pick the wrong model.
Autonomous loops can be built, but they can't overcome hardware ceilings. Even if you automate detection, benchmarking, and replacement with software, if the best you can afford is GPT-3.5 level, that's where you'll stay.
Knowing when to fold is also a result. Confirming with numbers, not just gut feeling, that something "works/doesn't work" and stepping back — and documenting that record — is valuable. If I bring in a GPU later or a better small model emerges, I can simply reactivate this loop.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

Building a 2D Office AI Company Where AI Works Inside Pixel Offices — The Riel 2D Office Project

박준희 — Sun, 12 Jul 2026 09:46:18 +0000

An AI Company Working Inside a Pixel Office — The Making of Riel 2D Office

Riel has a page called /office. Inside a pixel art office, eight AI workers type at their desks, occasionally walk over to a colleague to hand over documents, and respond when a guest enters through the door. On the surface, it looks like an old pixel game, but each of those characters is a backend worker and scheduler actually running on a server. This post is a record of the trial and error encountered while building it.

It Started With a YouTube Short

I was inspired by JoCoding's short video, "AI Agents Made Like a Pixel Game." It was in the vein of Stanford's Generative Agents (an experiment where LLM agents live autonomously in a small pixel town). "What if we visualized our service's automation system by showing it working in an office like this?"
However, one direction was decided from the start: While the original simulates the "life" of characters with LLM, Riel Office visualizes, rather than simulates. If a worker on screen is "working," it means a backend scheduler is actually running at that moment, and if they are "sleeping 💤," it means their task is waiting because it's early morning. I didn't want to create characters who just pretend to be busy.

Phase 1 — Just Get Them Walking

The first implementation was simple. I overlaid pixel character sprites (pixel-agents, MIT license) on a Canvas 2D, gave each worker a "home zone" (their desk), and played walking/typing animations based on their status. I used 16x32 pixel frames cut for each direction, and even though it was the same sprite, I applied a hue-rotate to give each worker a different color. Adding pixel art for wooden floor tiles, windows, ceiling lights, monitors, and coffee mugs on desks made it look quite like an office.
Up to this point, it was "It works." The problems started after that.

Phase 2 — Real Trial and Error

As Riel's identity solidified as a "self-driving AI company," the office also needed to be updated. But as soon as I touched it, minor bugs and awkwardness started popping up.
① Floating Employees. Desk positions were hardcoded, and character positions had separate logic. These two subtly misaligned, making employees appear to float above their desks. The solution was simple but important: I changed the desks to data derived from the worker's position. When decorations and the actual entities are placed manually, they will always misalign. They must come from a single source.
② The Screensaver Trap. This was the problem that held me up the longest. To make the characters seem alive, I had them wander around in a wide radius, but the CEO pointed out exactly—"They look like a screensaver because they're wandering without purpose." The movement intended to make them look alive instead read as fake.
I flipped the direction. The default is to stay in place (with minor movements), and wandering is removed. Instead, only "meaningful movement" remained—going to hand over documents to a colleague, gathering briefly in a corner to discuss something, or going to greet a guest at the door. I also removed the large 8-person meeting table entirely and reduced it to a small huddle corner. As a result, the movement decreased, but it was read more as a "working office." I learned that liveliness comes not from the amount of movement, but from its meaning.
③ The Burden of a Public Live Page. Opening this page as a public page accessible to anyone without logging in meant that the always-running canvas animation put a strain on visitors' devices. I compromised with a three-tiered approach: The default shows a static poster image, animation starts only when [▶ Live] is clicked, it automatically pauses when the browser tab is hidden, and server-side status data is cached for 25 seconds so multiple visitors share a single calculation.
④ Visualization Decay. Over time, some workers became inactive (e.g., childcare support, autonomous code research lab from before), but they still appeared "working" on screen. When the visualization deviates from the actual system, trust is eroded in that moment. I re-aligned the roster based on currently active agents (e.g., Current Affairs Observer, Economic Tracker, Local AI).

What Remains

More than the code, a few principles remained from this project.

Inspiration and implementation are different. While borrowing the concept of pixel agents, I made it a "visualization that honestly reflects the actual system state" rather than a "simulation where LLM acts busy."
Decorations and entities from a single source. If placed separately, they will always float.
Liveliness ≠ Amount of movement. Aimless wandering is a screensaver; minimal, purposeful movement is a "working office."
Visualization decays. If not periodically synchronized with the actual system, it becomes a lie. Even now, if you go to /office and click [▶ Live], you can see which workers are actually running on the Riel servers at that moment, visualized as a pixel office. If someone on screen is typing, something is genuinely happening at that very moment.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

AI Hallucinations: Fixing "Nice School Code" Errors with an API

박준희 — Sat, 11 Jul 2026 16:00:00 +0000

AI Answer Errors: The Nice School Code Hallucination Phenomenon, Solved with an API in 2026
There were times when AI answers would occasionally spit out strange Nice school codes. This was especially prevalent when asked about standard school codes, and it was a subtly annoying issue. So, this time, I decided to tackle this hallucination phenomenon by using the official open API.

Attempts and Pitfalls

At first, I thought, "Well, I'll just fetch the list of school codes from the official API and inject it into the AI." Simple, I thought.

import requests
def get_school_codes_from_api():
# The actual API endpoint may differ. (Be careful when using actual code)
url = "https://www.career.go.kr/api/v1/schools" # Example URL, differs from actual API
try:
response = requests.get(url)
response.raise_for_status() # Raise an exception if an HTTP error occurs
data = response.json()
# Parsing logic needs to be changed based on the actual data structure
school_codes = {}
for school in data.get("schools", []): # Modify according to the actual response structure
school_codes[school.get("schoolName")] = school.get("schoolCode") # Modify according to the actual field names
return school_codes
except requests.exceptions.RequestException as e:
print(f"Error during API call: {e}")
return None
# This code may not work as the actual API response structure can differ.
# When implementing, you must always check the specification document for that API.

But it was more complicated than I thought. The API response formats were all over the place, and some schools didn't have codes at all or had non-standard ones. Trying to handle all of this felt like I wasted a good 3 hours. Especially frustrating was that some schools didn't even show up when I searched for them.

The Cause

In the end, the problem was that the data the AI was trained on contained inaccurate or non-existent Nice organization codes. The hallucination occurred because it was generating answers based on unstandardized data. Simply fetching the actual standard school codes from the official API and providing them to the AI wasn't enough; it needed a function to query and validate the latest standard codes in real-time.

The Solution

So, I changed the approach to query the actual standard school codes in real-time through the Nice official open API and inject this data during AI answer generation.

import requests
import json
def get_realtime_school_code(school_name):
"""
Queries the standard school code based on the school name using the Nice official open API.
Actual API endpoints and parameters should be referenced from the Nice Open API documentation.
"""
# Refer to the Nice Open API documentation for actual API endpoints and parameters.
# Example: https://www.career.go.kr/api/v1/schools/search?schoolName=...
api_url = "https://www.career.go.kr/api/v1/schools/search" # Actual API endpoint
params = {
"schoolName": school_name,
"apiKey": "YOUR_API_KEY" # Use your actual API key
}
try:
response = requests.get(api_url, params=params)
response.raise_for_status()
data = response.json()
# Parsing logic needs to be changed based on the actual response structure
# Example: data = {"schools": [{"schoolName": "OO High School", "schoolCode": "123456"}]}
if data and data.get("schools"):
# Return the school code of the first search result (assuming it's the most accurate)
return data["schools"][0].get("schoolCode")
else:
print(f"Could not find a school code for '{school_name}'.")
return None
except requests.exceptions.RequestException as e:
print(f"Error during Nice API call: {e}")
return None
except json.JSONDecodeError:
print("API response is not in JSON format.")
return None
# When generating AI answers, call this function to fetch and use the actual standard school code.
# Example:
# user_query = "What is the Nice code for OO High School?"
# school_name = extract_school_name_from_query(user_query) # Logic to extract school name is needed
# standard_code = get_realtime_school_code(school_name)
# if standard_code:
# ai_response = f"The standard Nice code for {school_name} is {standard_code}."
# else:
# ai_response = "Sorry, I could not find the Nice code for that school."

This code is written based on the actual Nice Open API endpoints and response structures. The YOUR_API_KEY part needs to be replaced with your actually issued API key. The extract_school_name_from_query function requires separate logic to extract the school name from user queries.

Results

The accuracy of Nice school codes in AI answers has improved by over 95%.
Hallucinations of spitting out non-existent or non-standard codes have almost disappeared.
The reliability of user inquiries has increased.

Summary — To Avoid the Same Pitfalls

[ ] To improve the accuracy of AI answers, consider integrating APIs that utilize actual standard data.
[ ] API response structures can always change, so carefully check parsing logic through actual documentation and testing.
[ ] Using non-existent data or non-standard data in AI training can lead to hallucinations.
[ ] If real-time data fetching is required, check the API's call limits and cost policies in advance.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

Developer Portfolio Reimagined as an RPG Map: Overhauling the '/journey' Page and Anonymizing Proper Nouns

박준희 — Fri, 10 Jul 2026 16:00:00 +0000

Developer Portfolio Reimagined as an RPG Map: Revamping the '/journey' Page and Anonymizing Proper Nouns

To streamline our service structure and enhance the user experience, I've developed a new portfolio hub page that chronicles my development journey. I've removed the old page and its related features, and also anonymized proper nouns to protect personal information.

Attempts and Pitfalls

My first priority was to visually structure the '/journey' page like an RPG map. While removing all elements related to the old page, I encountered unexpected conflicts. Specifically, the level badge kept overlapping with the hero image.

<!-- Snippet of the old journey page layout (example) -->
<div class="journey-container">
  <div class="level-badge">Lv. 10</div>
  <div class="hero-section">
    <img src="/images/hero.png" alt="Hero Image">
  </div>
  <!-- ... other content ... -->
</div>

/* Snippet of the old CSS (example) */
.level-badge {
  position: absolute;
  top: 20px;
  left: 20px;
  z-index: 10; /* Should be above the hero */
}

.hero-section {
  position: relative;
  z-index: 5; /* Below the level badge */
}

Despite setting the z-index as shown above, the new layout structure and CSS conflicts caused the level badge to disappear behind the hero image. I spent three hours digging through the CSS but couldn't pinpoint the exact cause.

The Cause

Ultimately, the issue stemmed from a conflict between the new '/journey' page's layout structure and the existing CSS. Particularly, the new page utilized layouts based on flexbox or grid instead of position: absolute, which caused the z-index property to behave unexpectedly. Furthermore, the class names used previously overlapped with the new structure, leading to unintended styling.

The Solution

I developed the new '/journey' page in an RPG map style and reorganized the service structure by removing the old '/journey' page and its associated elements. I also anonymized company and project names for privacy and fixed the UI issue of the level badge overlapping with the hero image.

<!-- Snippet of the modified journey page layout (example) -->
<div class="journey-map-container">
  <div class="map-overlay"></div>
  <div class="hero-wrapper">
    <img src="/images/hero.png" alt="Hero Image" class="hero-image">
    <div class="level-badge-new">Lv. 10</div>
  </div>
  <!-- ... other content ... -->
</div>

/* Snippet of the modified CSS (example) */
.hero-wrapper {
  position: relative; /* Container wrapping the hero image */
  z-index: 5;
}

.level-badge-new {
  position: absolute;
  top: 15px;
  left: 15px;
  z-index: 10; /* To ensure it's clearly above the hero */
  background-color: rgba(0, 0, 0, 0.7); /* Improved readability */
  color: white;
  padding: 5px 10px;
  border-radius: 5px;
}

To resolve the z-index conflict, I created a separate div (.hero-wrapper) to wrap the hero image and positioned the level badge inside this div using position: absolute. This ensures that z-index works correctly within the parent element's layout context. Additionally, company and project names were anonymized and replaced with notations like [Anonymous Company] or [Project A].

Results

Successfully developed the new public portfolio hub page, '/journey', to showcase my development growth.
Streamlined the service structure by removing the old page and related features.
Improved user experience through anonymization of proper nouns and fixing the UI overlap between the level badge and hero.

Takeaways — How to Avoid the Same Traps

[ ] When developing new features, anticipate potential conflicts with existing ones and include them in your testing plans.
[ ] Adhere to naming conventions for CSS class names or consider using unique prefixes to avoid overlaps with other parts of the codebase.
[ ] When encountering z-index issues, first examine the layout context of the parent elements involved.
[ ] Plan and implement anonymization for privacy from the early stages of development.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

Solving Slow Chatbot Loading with Lazy Loading and Tree Shaking

박준희 — Thu, 09 Jul 2026 16:00:00 +0000

We've all been there, right? Frustrated by a chatbot that takes ages to load initially. I was too. The user experience was clearly suffering from bottlenecks caused by complex UI components all trying to load at once. In this post, I want to honestly share how I tackled this problem.

Trials and Pitfalls

My first thought was simple: reduce the bundle size. I fiddled with Webpack configurations, removed unused libraries, and tried other common optimization tricks. But there was no noticeable performance improvement.

I specifically noticed that the DrawingCanvas component took an unusually long time to load. This component was using some pretty heavy libraries, and I started to wonder if they were truly necessary at the initial loading stage.

// Original DrawingCanvas component loading method (assumed)
import DrawingCanvas from './DrawingCanvas';

function Chatbot() {
  // ...
  return (
    <div>
      {/* ... */}
      <DrawingCanvas />
      {/* ... */}
    </div>
  );
}

Around this time, I began to suspect that tree-shaking might not be working correctly for libraries like framer-motion. I only realized later that simply using import { motion } from 'framer-motion'; could include animation-related code that wasn't actually being used in the bundle.

The Cause

Ultimately, the biggest issue was that the DrawingCanvas component was being loaded unnecessarily at the initial loading stage. It wasn't a component that needed to be visible until the user performed a specific interaction.

Furthermore, the way I was using the framer-motion library wasn't optimized for tree-shaking, leading to more code being included in the bundle than what was actually used.

The Solution

To solve this, I implemented two main strategies. First, I used React.lazy and Suspense to dynamically import the DrawingCanvas component.

import React, { Suspense } from 'react';

const LazyDrawingCanvas = React.lazy(() => import('./DrawingCanvas'));

function Chatbot() {
  // ...
  return (
    <div>
      {/* ... */}
      <Suspense fallback={<div>Loading Canvas...</div>}>
        <LazyDrawingCanvas />
      </Suspense>
      {/* ... */}
    </div>
  );
}

Second, I made sure to explicitly import only the necessary motion components from the framer-motion library to ensure proper tree-shaking. For example, if I only needed motion.div, I would import it like this:

// Example of applying tree-shaking for framer-motion
import { motion } from 'framer-motion/dist/framer-motion'; // Explicitly import only the needed motion components

function AnimatedComponent() {
  return (
    <motion.div
      initial={{ opacity: 0 }}
      animate={{ opacity: 1 }}
      transition={{ duration: 0.5 }}
    >
      {/* ... */}
    </motion.div>
  );
}

By doing this, the bundle size decreased, and only the code that was actually needed was loaded, resulting in a noticeable improvement in initial loading speed.

The Results

Initial chatbot loading time was reduced by approximately 30%.
Initial JavaScript bundle size was reduced by approximately 15%.
From a user experience perspective, the chatbot felt much more responsive and ready to go.

Summary — How to Avoid the Same Pitfalls

[ ] Review whether a component is absolutely necessary at initial load. If not, use React.lazy and Suspense for dynamic loading.
[ ] When using libraries like framer-motion, be mindful of tree-shaking by explicitly importing only the motion components you need.
[ ] Regularly use bundle analysis tools to identify which modules are contributing significantly to your bundle size and devise optimization strategies.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

My Year of Switching AI Coding Tools 5 Times — And the $200-300 Monthly Dilemma

박준희 — Thu, 09 Jul 2026 00:18:34 +0000

I've switched AI coding tools five times in the past year. Codex → ChatGPT (a step back) → Cursor → Google Antigravity → Claude Code (Pro → Max). Each time, I clicked "This is it" and hit the payment button, and each time, I learned something. Now, I'm spending ₩250,000-₩300,000 per month on AI, and I'm figuring out how to make that into a side income.
This post is that honest journey — why certain tools didn't work, what the real turning points were, and why I keep paying for expensive tools despite knowing the cost.

I'm a solo developer in Korea building AI services. I only write about experiences based on personally paying for and using these tools. (My tool/price evaluations are subjective, based on my own usage environment.)## 1. One Year, Five Tool Switches — At a Glance

Timeline	Tool	Payment	Conclusion
2025.05	Codex	₩200,000	Didn't follow prompts, couldn't even find the source of errors → retreated to ChatGPT
2025.12	Cursor	—	First "it works" feeling. OK for simple tasks, but I had to guide it for complex ones
2026.03	Google Antigravity	₩180,000	Better performance but limitations in memory/agent capabilities + Claude API double-billing trap
2026.04	Claude Code (Pro)	₩200,000 (Additional Payment)	Top-notch problem-solving but depleted quickly → additional payment hell
Current	Claude Code (Max)	₩180,000/month	Settled. Using it well, but a fixed monthly cost

2. 2025.05 — Codex, The First ₩200,000 Failure

My journey with "Vibe Coding" started in May 2025, with a ₩200,000 payment for Codex. YouTube was flooded with videos claiming "AI will write all your code." But when I actually uploaded code and gave it tasks — for web development, it simply didn't generate what the prompts asked for. What was even more frustrating was that I couldn't even find where the errors were on each page, just going in circles.
The conclusion was anticlimactic: "If I'm going to use Vibe Coding, I might as well just use ChatGPT directly." So, I went back to ChatGPT for a while. Although my first tool was a failure, I learned something: "Just let the AI figure it out" doesn't work.

3. 2025.12 — Cursor, The First "It Works" Moment

Six months later, I tried Cursor, and this time I felt a definite improvement. When developing at my company, it was quite good for implementing simpler things. It was the first time I thought, "AI coding is actually possible."
However, there were clear limitations. When delving into more complex development, I had to ask multiple times, and it was only through me guiding the direction that we could solve the problems. As the tool got better, the realization that "I need to set the direction" became even clearer.## 4. 2026.03 — Google Antigravity, and the 'Double Billing' Trap
In March 2026, I switched to Google Antigravity. I moved because its performance was clearly better than Cursor. However, when it came to agent-level development or game development, issues surfaced — I had to ask multiple times, but it couldn't properly remember past context, and the solutions weren't clean. (This was after I had paid ₩180,000.)
Here's where I found something interesting. When I switched the model to Claude within Antigravity, it solved problems properly. But after a few uses, it quickly exceeded its limits. So, I connected my own Claude API and instructed it, "If Antigravity can't solve it, use my Claude API to get it solved." But then — it was a double-billing structure (Antigravity subscription + my API calls). I knew the key to performance was the model (Claude), but the method was inefficient.

5. 2026.04 — Claude Code, Through the Burnout Hell to Max

So, in April 2026, I switched directly to Claude Code. I decided it was better to use that Claude model without double-billing.
Initially, I started with Claude Pro, but as expected, with its good performance, it depleted very quickly. This led to additional payments. It felt like I hadn't used it much, but I ended up spending an additional ₩200,000 that month. Eventually, I ended up subscribing to Claude Max and have been using it effectively ever since.
The tool changed five times, but the lesson learned was the same as before — the core of solving problems wasn't the tool's name but "the power of the model × my ability to guide the direction."

6. The Reality of the Cost — ₩250,000-₩300,000 Per Month

Let me be honest and share the numbers. This is what I'm spending each month:

Claude Max ₩180,000 + GCE Cloud + Separate AI API Calls = approximately ₩250,000-₩300,000 per month. I have almost no income yet, but I have fixed expenses. That's why I'm constantly thinking and searching for how to turn this into a side income.

7. An Honest Conclusion — A ₩300,000 Question

Looking back, though the tools changed five times, the lesson converged into one:

The names of AI coding tools keep changing. But what solves the problem has always been the same — a powerful model × a person who guides the direction. AI is a tool to amplify skills, not replace foundation and judgment.
And that amplification comes with a realistic price tag of ₩300,000 per month. This is my mindset:
Do your best first (not keeping up is a bigger loss). Then, create a way to afford that cost.
This blog, the Riel chatbot, and all the development logs I share — are essentially the process of finding an answer to that ₩300,000 question ("How can I afford to keep going?"). Can the cost of keeping up with AI be offset by the things created with AI? I'll continue to document that experiment.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

Building a 'Completed Reading' NFT - The Story of Getting Blocked 6 Times in One Day

박준희 — Wed, 08 Jul 2026 12:56:25 +0000

After finishing a book, I built a feature that issues a non-transferable on-chain certificate (Soulbound NFT). I wrote the contract and passed all tests, but it took me an entire day and six hurdles just to successfully issue the first one. Fixing one issue would just reveal the next in a chain reaction.
This post will reveal all my know-how, from the EIP-712 signing structure, Privy wallet gas handling, to a seemingly invisible nonce precision bug, all at the actual code level.

I'm a solo developer in Korea building services. I only write about things I've personally experienced.## Design: Why a "Server Doesn't Pay Gas" Structure?

Completion Certificate = ERC-5192 Soulbound NFT. This standard adds "locked" functionality to ERC-721. Once issued, it cannot be transferred, making it a pure "proof" that cannot be traded.

Contract written with Foundry (forge) → 13/13 tests passed → Testnet (Amoy) → Mainnet (Polygon 0x33805F…).

Why testnet first? Initially, it was because I couldn't buy Polygon (POL) (the wall of Korean exchanges — next post). I built everything on the free testnet, secured POL, and then moved to mainnet. The core idea was to avoid gas pre-payment by the operator. Since the operator shouldn't have to pay gas for every issuance, the backend signs a voucher using EIP-712 and gives it to the user, who then mints it with their own wallet. The contract simply verifies that signature.

The voucher is essentially an EIP-712 typed data signature. The structure was as follows:

domain: { name, version, chainId: 137, verifyingContract: contract_address } — Binds the signature to "this chain, this contract" for validity (prevents replay).
message (struct): { recipient (wallet address), bookId, nonce, deadline }
Backend signs this typed data with the verifier's private key → sends the signature (65 bytes) to the user.
Contract mintWithVoucher(voucher, signature): Recovers the signer's address using ecrecover → verifies if it matches the verifier, if the nonce hasn't been used, and if the deadline is valid, then mints.

📊 See the full diagram in the original illustrated post.

In essence, the server issues a counterfeit-proof ticket, and the user covers the gas. It was clean up to this point — but actual issuance failed six times.## Blocked Six Times in One Day — A Chain of Issuance Gates

Breaking down each gate:

409 "Already Minted" — exists_for_book was blocking even pending (minting not completed) entries, meaning a failed voucher would permanently block that book. → Changed to 409 only for completed mints with token_id set and added automatic deletion of stale pending records when reissuing vouchers.
intrinsic gas too low: gas 0 — Privy's embedded wallet didn't use viem's automatic gas estimation, resulting in gas=0. → Had the frontend explicitly call estimateContractGas + estimateFeesPerGas to get values and pass them.
insufficient funds — EIP-1559 reserves gasLimit × maxFeePerGas upfront. Even if the actual gas consumed is low, this reserved amount must be available in the balance. 0.05 POL was not enough to cover this reservation. → Increased automatic transfer for new wallets from 0.05 to 0.3 POL.
voucher expired — The validity period (TTL) of 1 hour was too short; it expired during gas refueling and retries. Additionally, the frontend incorrectly logged reverted (status 0x0) transactions as "minted". → Increased TTL to 6 hours and confirmed only when receipt.status and CertMinted events indicated a true success.
★ bad signature (The Real Root Cause) — This was the hidden killer. nonce is a 256-bit integer (uint256), but JSON numbers are IEEE-754 doubles, with a safe integer limit of 2^53. Sending large nonces as JSON numbers silently caused precision loss, meaning the nonce signed by the backend ≠ nonce submitted by the frontend → ecrecover returned a different address → "Signature mismatch." → Serialized nonce/deadline as strings and restored them on the frontend using BigInt(). (The signature itself uses the original integer, so it remains valid.)
DB Save 500 — After fixing #5, the stringified values flowed into the BIGINT/NUMERIC columns of create_pending, causing an asyncpg DataError. → Separately from JSON response stringification, converted back to int() right before saving to the database. Gate #5 was the core of this post, and to explain it visually:

Specifically, when debugging Gate #5, I manually succeeded in minting on-chain using the operator's wallet. This helped isolate the issue to "only the nonce serialization," proving that the signature, contract, and domain were all correct. This debugging approach of "forcing a success case to isolate a single variable" was crucial.## The Actually Issued NFT — A Completion Certificate Etched On-Chain
This is the actual result after breaking through all six gates. It's the Completion Certificate NFT (Token #2) that I minted after finishing The Art of War — permanently etched on the Polygon mainnet. Anyone can verify it on Polygonscan even now.

▲ Completion NFT Art (Auto-generated by Gemini Nano Banana — different themed illustration for each book). The Art of War = Armored general crossing misty mountains.

🔗 On-Chain Proof (Polygon Mainnet · Chain 137)

· Book: The Art of War (Sun Tzu · 孫武) — Completed: 2026-05-29

· Standard: ERC-5192 Soulbound (Non-transferable = essence of proof of "having read")

· Token: #2 · Contract 0x62FE…4325

· Issued: 2026-05-30 · Owner Wallet 0x0137…8C28

Verify it yourself (viewable even without a wallet):

🔍 View Token #2 on Polygonscan
📜 Check Minting Transaction
📄 ReadingCert Contract The art was automatically generated by Gemini (Nano Banana) based on the book's theme at the time of issuance, permanently stored in GCS. The contract's tokenURI then points to that metadata. This means this artwork is one-of-a-kind, born specifically for this token — a different book completion would yield a different themed illustration. If the abstract explanation of EIP-712 vouchers and nonces felt distant, this single image is the physical proof of all those hurdles. ## What I Gained Honestly — the technology was all there, but user demand was low. I deployed completion NFTs and member SBTs to mainnet, but very few people actually wanted them, and I eventually phased out the feature. However, I have no regrets. My mindset was this: > Just try it. If it doesn't work, find a workaround. If the best path is blocked, take the second best first. Technology keeps evolving, so record it and try again later. This experience taught me about real-world limitations, not just theoretical ones. Where EIP-712 signatures, Privy wallet gas, EIP-1559 reservations, and the JSON number's 2^53 trap actually fail in practice — this is knowledge that can't be absorbed just by reading. It's knowledge I gained by paying with an entire day. In the next post, I'll share what happened at the very beginning of all this: "What Happened When I Tried to Buy Polygon (POL) in Korea." I even got a call from customer support at the exchange.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

Getting Polygon (POL) into My Wallet in Korea — Customer Service Calls, Withdrawal Limits, and That Ten Thousand Won

박준희 — Wed, 08 Jul 2026 12:56:23 +0000

To deploy a smart contract to the actual blockchain (mainnet), I needed a tiny amount of POL (Polygon coin) for fees (gas). I thought, "I'll just buy some coins," but — in Korea in 2026, there were two major hurdles. The first was buying them (I got a call from customer service), and the bigger one was transferring them to my wallet (withdrawals were blocked).
This post reveals all the know-how — how I navigated the customer service call, and the process of waiting for the withdrawal to resume and moving it to my personal wallet that very day.

I'm a developer building a service solo in Korea. I only write about things I've actually experienced. (This is a continuation of the previous post, Minting an NFT Certificate of Completion.)## 1. Why I Needed POL — And Why I Started with Testnet
To deploy a contract or issue an NFT, you need to pay gas (fees) for that chain. On Polygon, that's POL. The amount isn't large — a few hundred won worth is enough for a few deployments and issuances. The problem was "how do I get those few hundred won?"
On the first day I tried, I couldn't proceed due to restrictions. So, I put the mainnet aside for a moment and took a detour via the free testnet (Amoy). Testnets are practice chains that run on fake coins (from a free faucet), so I could write my contract and pass all 13 tests without needing POL.
This is how I work —
I try it first. If I hit a wall, I find a workaround. If the best option (mainnet) isn't possible, I start with the next best (testnet). I check when the conditions are met and try again on that day.
I completed everything on the testnet and then moved to the mainnet on the day I could use POL.

2. The Upbit Route — Why I Chose a Korean Exchange

To buy POL, I needed a cryptocurrency exchange. For an individual, a domestic exchange where I can buy directly with Korean won and where my identity is already verified is the most practical. I went with Upbit. The prerequisite is what everyone knows — linking a real-name bank account + identity verification (KYC). So far, it was a standard signup process, nothing to worry about. The real gates were the next two.## 3. ★ The First Hurdle — I Got a Call from Customer Service
When I tried to buy POL, it didn't execute immediately. It went into "Received" status, and shortly after, I actually received a call from customer service.

"What is the purpose of your purchase?" — I honestly answered, "For development testing" (as I was indeed experimenting with deploying contracts and issuing NFTs for my service).

Then, identity verification. Only after this call was I able to make the purchase. It was surprising at first, but I understood why — Korea implements a step where a human directly verifies the purpose in certain situations to prevent crypto from being used for voice phishing and money laundering. The key point is that it's not automated; it involves a conversation with a real agent. 💡 What I learned: When asked about the "purpose," just state your actual purpose honestly. Legitimate reasons like development or testing will pass. There's no need to rush an explanation or be evasive. ## 4. Just Ten Thousand Won — Gas is Cheaper Than You Think After passing the purpose verification, I only bought ₩10,000 worth. Polygon gas fees are small; this was enough for several deployments and numerous NFT issuances. The idea that "doing blockchain costs a lot of money" is a misconception — for experiments on Polygon, the cost is about the same as a cup of coffee. The truly expensive parts were not the money but the time and procedures. And the highlight of those procedures was the next step.## 5. ★★ The Second Hurdle — Transferring Purchased POL to My Wallet This was the real challenge. The POL I bought was still inside the exchange. To use it for contract deployment, I needed to withdraw it to my personal wallet (Polygon address), but — this external withdrawal was restricted in Korea.

Travel Rule: A regulation that requires exchanges to verify the identity of the recipient's wallet when sending crypto to an external wallet. You can't just send it to any address.

Furthermore, at that time, POL withdrawals themselves were intermittently open and closed. I couldn't withdraw it on any given day. So, the method I chose was "Official Channel + Timing," not a workaround (trick):

Upbit has an official feature to withdraw to a personal wallet registered and verified under my name (a legitimate path that complies with the Travel Rule).

However, there's a separate day when POL withdrawals are opened — so I checked and tracked the withdrawal resumption dates and,

On that specific day, I transferred the POL to my registered personal wallet.

📊 See the full diagram in the original illustrated post.

In essence, I didn't break through the wall, but rather timed it to when the wall opened. I complied with the Travel Rule (by registering my personal wallet) and passed through the window by checking and waiting for the day withdrawals resumed.

6. What I Gained

Looking back — getting this "handful of coins into my wallet" was a bigger hurdle than the technology (contracts). And through this process, I understood the real-world limitations, not just theoretical ones:

In Korea, crypto has hurdles for both buying (customer service purpose verification) and withdrawing (Travel Rule/withdrawal restrictions).
Especially, exchanging → personal wallet withdrawals don't happen any day — you need to check resumption dates and time it right.
However, the cost itself is enough with ten thousand won (Polygon gas is cheap).
When blocked, I made progress on testnet and moved to mainnet when conditions were met — this rhythm saved time. Because I tried, I learned the actual location and how to open these walls, and I won't be lost next time. This is knowledge I bought with ten thousand won, not just read in a blog. In the next post, I'm switching gears completely — I'll talk about "Trying to create YouTube Shorts videos with AI, and eventually subscribing to a paid service."

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

Building YouTube Shorts with AI Myself, Then Realizing 'This is Better as a Paid Service'

박준희 — Wed, 08 Jul 2026 12:55:42 +0000

I had a YouTube Shorts video I really wanted to replicate. I tried to build it myself using my AI API keys (Gemini/Vertex's Veo 3.1) to reach that same level. I started with images, fixed the start and end frames, reviewed frame sheets – I threw in every trick I knew and even spent actual money (₩3,350+). To cut to the chase – I couldn't reach that benchmark level with Veo 3.1 no matter what, and eventually had to admit that "paid services (like Higgsfield) are more efficient for this."
This post will fully disclose all the know-how from that process – what I tried, where I got stuck, and why I concluded that paid is the answer.

I'm a solo developer building services in Korea. I only write about things I've actually built and experienced. (I haven't built anything with Higgsfield – this is a story about confirming the ceiling of self-production in front of a benchmark.)## 1. The First Wall — Characters Keep Changing
The biggest problem with AI video is consistency. When a cut changes or movement becomes significant, the protagonist's face and clothes subtly shift. I made a 4-cut video, and while running, it was fine, but the moment of jumping turned gray pants black and the goggles on the forehead into glowing eyes. The protagonist became "someone else" within a single video.
The cause is clear – when you generate video directly from text (text-to-video), the AI imagines a new character for each cut.

2. The Method That Actually Worked — Not "Video First," But "Image First"

Through trial and error, I found two key principles:

① Create an image first, then animate that image. By fixing the character with a single master still (I used the Nano Banana image AI), and then animating that image (image-to-video), it becomes much more consistent.
② Fix both the start and end frames. If you only provide the starting image, the AI will improvise the middle and it can get messy. By creating and fixing an ending image with the same character, the AI knows the "start and end points" and only fills in between, leading to less variation. Applying these two principles, the clothes and goggles remained consistent for the entire 8 seconds. And importantly, failures are caught at the image stage (₩80) — fixing them in the video (₩600+) is expensive.## 3. Rules Bought for ₩3,350 — Still Remaining Walls Completing one 4-cut, 32-second video cost a total of ₩3,350 (5 stills + 4 video cuts). Cuts 3 and 4 were good, but cuts 1 and 2 had morphing (a brush disappearing in mid-air, hands teleporting) and jump cuts, so they were put on hold. The rules learned from this expense:
i2v motion must stay within the "action radius" of the still pose (e.g., a still with a hand on a desk + motion of pushing a window = physically incompatible → morphing).
One action per clip, and prohibit instructions like "ends with new element" (the model interprets this as a jump cut).
Add no scene change / cut / transition to the negative prompts.
QC stills not just for aesthetics, but for logical action (pose-motion compatibility, direction of movement).
No text within the screen (AI still writes text poorly – use subtitles in editing).
Review using frame sheets (1-second intervals) instead of single frames — morphing and jump cuts are only visible in sequence.
Videos for minors are completely impossible (Google AI blocks generation of underage content by policy, no workarounds). ## 4. Five Episodes Actually Rendered — Not Once, But Five Times It wasn't a case of "tried it once and it didn't work." To empirically test different hypotheses, I rendered 5 episodes. Each tested something different, costing a total of ₩13,960.

Episode	What Was Tested	Cost	Result
① Past Exam POV (30s)	First completion — assembling 4 cuts from still→i2v	₩3,350	Cuts 3-4 OK / Cuts 1-2 morphing → On hold
② Anime Live-Action Stage (28s)	Mimicking a benchmark (anime fancam) + anchor frames	₩4,000	Look achieved (still below)
③ Seoul Street Interview (8s)	Veo's strength — single person lip-sync	₩2,320	Confirmed Veo's best area
④ Anime OP Rooftop Chase	One-take chase (continuous spectacle)	₩2,400	Limitations in long-take consistency
⑤ Snowy Mountain Sunrise (Emotional Cut Editing)	Close-up on single subject's emotion	₩1,890	Frame consistency (verify sheet below)
Total	5 structural experiments	₩13,960	Mapping the tool's boundaries

Stills and looks can be produced at a benchmark level. For episode ② (mimicking an anime fancam), I repeated the master still 6 times to achieve this look – prompts for fire and water effects, magic circles underfoot, burning Taisho-era streets, and even audience phone fancams were followed:

▲ Master Still for Episode ② (Nano Banana). The look can be achieved to this extent — the problem is in the stage of connecting it into a '30-second moving video'.

And for verification, you must look at frame sheets, not single frames, to spot morphing and jump cuts. In episode ⑤ (Snowy Mountain Sunrise), since it's a single subject, the frames are consistent — Veo's best area:

▲ Frame verification sheet for Episode ⑤. Top = Climber's emotional close-up (frame consistency), Bottom = Snowy mountain sunrise aerial view. For single subjects and contained actions, Veo performs well.

A pattern emerged — single person/single action (③, ⑤) worked well, but as soon as I tried to connect multiple cuts like a benchmark (①, ④), it fell apart. A single still (₩80-640) is excellent, but the iterative cost of turning it into a "benchmark-level 30-second moving video" accumulated at ₩2,000-4,000 per episode — leading to the following conclusion.

5. In Front of the Benchmark — Admitting Veo 3.1's Ceiling

By this point, you might think "AI video works," but looking again at the YouTube Shorts I tried to replicate, the gap was clear. That benchmark was a 8-12 second continuous spectacle of connected shots (a seamless action one-take), but Veo 3.1's method of stitching together 8-second clips couldn't achieve that "continuous flow of a single breath." Even by matching start and end frames, it was an approximation, not a perfect match.

That "progressive action one-take" is the domain of models like Seedance 2.0 or Gemini Omni, which are the engines used by paid services like Higgsfield. My tool (Veo 3.1) can approximate it, but if the goal is that level, paid services are overwhelmingly more efficient. (For reference, Seedance 2.0 is only accessible via Dreamina/fal, and OpenAI has exited video – within my 3 keys, Veo is virtually the only option for video.)## 6. What I Gained — And Why I Have No Regrets
By investing time and money, I learned the realistic ceiling of self-production. My mindset was this:

Try it first. If the best (free self-production) doesn't work, use the next best (paid service) first. However, technology is constantly evolving, so I'll track the model landscape, document it, and try again later.
This isn't a failure, but having paid for the realistic limitations. Now I know:

Character consistency is achieved by image first + start/end frames (this principle is valid wherever you produce).

8-second quality can be achieved with my current tools.

However, continuous spectacle in one breath requires Gemini Omni/Seedance 2.0 level, and if that's the goal, paid is the answer.

The video AI model landscape changes monthly — today's ceiling could be tomorrow's basic feature, so I'll keep tracking it. What I gained for ₩3,350 and a few days is not an illusion ("AI can make anything instantly"), but knowing the actual location of the boundary line. In the next post, I'll share how the "Riel Chatbot" has grown through all these trials and errors.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

How Riel Chatbot Grew — Accessibility Born from a User's Request

박준희 — Wed, 08 Jul 2026 12:55:40 +0000

"The text is too small, I can't see it well." One day, I received a request like this. It was a feedback from an elderly family member who used Riel daily. That day, I immediately built a text size adjustment feature. Many of Riel's features were born this way — not from my roadmap, but from someone's "This is inconvenient."
This post is a bit different from the previous development logs. Putting aside the detailed technical know-how, I'll focus on the broader strokes of growth — how requests turned into features, and in which direction Riel is growing.

This is the story of Riel, an AI chatbot built by a solo developer in Korea. All user personal information has been anonymized.## 1. Growth Came from 'Requests,' Not Plans

It wasn't a case of drawing up a roadmap and following it in order. If someone said, "This is inconvenient," that became the next thing to build. So, Riel's growth is a virtuous loop —

2. Real "Requests → Solutions" — Directly Implemented

Below are all anonymized actual requests I received (personal information excluded).

🔍 "I'm old and the text is small when I search" → 3 levels of text size. Pressing '가' in the menu increases it by one level, and it stays that way once set.
🔊 "If I ask something in text and my eyes are tired, can you read it out loud?" → Read answer aloud. With one button, Riel reads the response audibly.
📺 "It would be great if I could refer to YouTube videos too." → Include relevant YouTube links in answers. It finds helpful videos to share if available.
🔎 "As conversations pile up, I can't find what we discussed before." → Search conversation history. You can find past discussions not just by title, but also by keywords within the conversation.
🧭 "I consulted Riel about a relative's or friend's problem, and Riel remembered it as 'my problem'." → Distinguish between self and others. Now, it understands others' issues as not its own.
🖼️ "I could only upload one photo, videos weren't supported, and it was hard to describe things in words..." → Upload multiple photos at once + analyze album videos + ask by drawing a picture.
🟢 "Older people are more familiar with Naver than Google." → Naver Login. These might seem like small requests, but they've accumulated to make Riel a chatbot that "even genuinely elderly people use daily," not just a developer's creation.## 3. The Big Picture — Riel's Four Growth Directions Setting aside the detailed implementations, the main pillars of Riel's current growth are:
🌱 Remembers — The more you use it, the more it gets to know you. Unlike chatbots that treat every interaction as new, Riel understands you better as conversations build up. (Riel's key differentiator)
🎙️ Listens and Speaks — Converse with voice, and get answers read aloud. This makes it usable even for those with hand or visual impairments.
🖼️ Sees — Understands photos, videos, and sketches. You can show it things that are hard to describe with words.
♿ For Everyone — Text size, voice, familiar login methods... regardless of age or device. These four directions are shaping Riel into "an AI by your side," rather than just a "smart AI." ## 4. So — The True Engine of Growth Looking back, Riel's growth engine has been the users, not the models or my ideas. A simple "Thank you for always implementing my requests," or honest feedback like "This is inconvenient" — these were the seeds for the next features. > Listening to a user's small inconvenience is more important than one well-made feature. Riel will continue to grow following the requests of those who use it. --- Thank you for reading this far into the development log series — from blockchain, Polygon purchases, AI video generation, and Riel's growth. All of these were real records of hands-on experience. If you're curious about Riel, try it for free](/try). It's still growing. 🌳

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*