Tutorial

Introducing Omnilude-tools

AAnonymous
5 min read
#Next.js
#Omnilude Tools
#Vibe Coding
#Product Development

If this blog is a product for recording my work, there is an older sibling project that I tested in the field before it. That project is omnilude-tools.

This project is essentially a page that gathers a few web utilities, and I used this repository to see how quickly vibe coding could become something that is actually deployable.

In the repository, the first feat: init 프로젝트 commit was made on the morning of January 26, 2026. On the afternoon of January 27, commits related to release: v1.0.0 and deployment followed. In other words, this was an early experiment that went from implementation to deployment in roughly two days.

What kind of project is Omnilude-tools?

The current omnilude-tools is a multi-tool web app served at tools.omnilude.com. It bundles developer tools, text tools, everyday utilities, time tools, and calculator tools into one product, and it is designed to let people handle as much work as possible directly in the browser.

At a high level, the areas look like this.

  • Developer tools: UUID Generator, Timestamp Converter, Regex Tester, JSON/YAML/XML converters, JWT Debugger
  • Text tools: JSON Editor, Diff Checker, Markdown Preview, Emoji Picker, Text Counter
  • Everyday tools: QR Generator, Barcode Generator, Random Picker, Color Extractor, Subtitle Converter
  • Time and calculation tools: Global Time, Timer, D-Day Calculator, Unit Converter, GPS Coordinates Converter, Resistor Calculator

What is interesting is that this project did not stop at being a site with a lot of tools. The public toolset grew to 45 tools, and the product supports a seven-locale structure with Korean as the default, plus English, Japanese, Chinese, Spanish, French, and Hindi. Product standards like free access, fast usability, browser-centered processing, and multilingual SEO were built in from the beginning.

Technology

The stack is built on Next.js 16, React 19, next-intl, pnpm workspace, and turbo. On top of that, it uses a shared UI package called @omnilude/ui, and each tool is organized with a page.tsx, _components, _store, and _lib pattern. That means new tools can be added on top of a repeatable structure instead of inventing the structure from scratch each time.

There were three things I especially liked in this project.

  • src/lib/constants/tools.ts manages groups, tool metadata, the sidebar structure, and home card links in one place.
  • src/lib/utils/seo.ts and the JSON-LD components generate canonical tags, hreflang, Open Graph data, and structured data across tools and groups.
  • scripts/deploy-prd.sh and the kubernetes/prd manifests keep real deployment inside the repository.

The deployment structure is also fairly practical. Ingress includes the tools.omnilude.com, www.omnilude.com, and omnilude.com hosts together, and Deployment separates startup, liveness, and readiness probes. Later, the repository also received the commit for improving zero-downtime deployment based on SSR warm-up. So this was not a product that ended at being built. It kept getting work from the operational side after deployment.

The first goal was achieved

What I confirmed through this project is that the core of vibe coding is not blindly shipping things fast. It is almost the opposite. If you want to push a lot of implementation through in a short time, you have to establish repeatable standards even faster.

I think that is also why omnilude-tools could reach deployment within two days.

  • The product scope was clear. The problem definition of a browser-based collection of utilities was explicit.
  • There were repeated patterns. Shared UI, shared state handling, and shared SEO utilities were already there.
  • There were many areas where AI is good. Form composition, conversion logic, boilerplate UI, and repeated implementation all moved faster.
  • The points that still needed human judgment were clear. I kept deciding which tools should be public, which ones should stay hidden, how they should be grouped and named, and what counted as a deployable result.

That point matters. More than simply confirming that AI is useful for making prototypes quickly, I more strongly confirmed that a real service can also be pushed up surprisingly fast if a human sets the right criteria.

Still, I think I need more time to judge whether this tool provides meaningful value. Once enough data accumulates, I plan to share it.

Closing

omnilude-tools is a simple collection of web tools, but for me it was the first product I launched by using AI aggressively.

That experience is also inside the way I build and operate this blog now. In later posts, I want to unpack individual features inside omnilude-tools, its multilingual structure, the SEO decisions behind it, and the work units that made fast deployment possible.

If you are curious, it is worth taking a look at tools.omnilude.com directly. You will probably get a faster sense of what kind of product this is than from this post alone.