DJAI Academy
Back to blog
Guides13 min read

How I Built Open-Source Browser Tools with Codex and Claude Code

A practical guide to the AI coding workflow behind DJAI open-source browser tools: Claude Code for planning and review, Codex GPT-5.5 for implementation, and MIT licensing for community reuse.

Why this guide exists

This guide explains the real workflow behind the open-source DJAI browser tools repository: how planning, implementation, review, cost control, and product polishing were split between Claude Code and Codex.

The project is now prepared as an MIT-licensed open-source release under lovecatisgood-sudo on GitHub. It includes privacy-first browser tools for PDF work, image conversion and compression, OCR, DOCX conversion, AI token and RAG workflows, CSV and Excel utilities, and QR code generation.

DJAI Academy is proud to present this guide and this repository. Siamese Cat Dev is a senior community member of DJAI, and this open-source release is a generous contribution to people who want practical tools, reusable code, and a working reference for AI-assisted product development.

The short version of the workflow

The workflow was simple, but disciplined:

  • Use Claude Code for planning, architecture thinking, review, audit, and product feedback.
  • Hand most implementation work to Codex with GPT-5.5, especially medium reasoning, because it can execute long coding tasks reliably with a much higher practical rate limit.
  • Bring Claude back in between major milestones to inspect the direction, identify weak spots, and produce feedback.
  • Give that feedback to Codex, then let Codex fix, implement, test, and stabilize the product.
  • Repeat until the tools behave like a real product rather than a demo.

This is a strong AI coding pattern because it separates strategic thinking from production execution. Planning tends to spend more input tokens because the model has to read requirements, previous decisions, repo context, constraints, and product goals. Implementation often spends more output tokens because the model writes code, patches files, fixes errors, and repeats verification. Since premium planning models can be relatively expensive, especially on output tokens, using them mainly for high-leverage planning and audit can reduce total cost while still improving quality.

Why Claude Code was useful for planning

Claude Code was useful at the planning stage because planning is not just listing tasks. Good planning means deciding what should exist, what should not exist, what order to build in, how the pieces should connect, where the risk is, and how the final repo should make sense to other developers.

For this project, planning covered questions like:

  • Which tools should be grouped together?
  • Which tools should be separate apps?
  • How should English and Thai routes be structured?
  • What should stay browser-based for privacy?
  • Which features matter for SEO and GitHub discoverability?
  • What should the README say so people immediately understand the project?
  • How should attribution be requested without making the license restrictive?

That type of work benefits from deliberate review. Claude was used as a senior planning partner: good at weighing tradeoffs, noticing missing pieces, and giving structured feedback before the implementation sprint began.

Why Codex handled most of the execution

Codex with GPT-5.5 handled most of the build work because this project required a lot of direct repository work: reading files, editing code, wiring routes, adding documentation, testing builds, fixing errors, and repeating the loop.

For an application like this, execution volume matters. A model can be very smart, but if it has a restrictive practical rate limit or expensive output cost, it becomes harder to keep iterating. Codex GPT-5.5 medium was already able to implement almost everything needed for this product with strong reliability, so it became the main implementation worker.

That made the workflow cost-effective:

  • Use the more expensive planning model where judgment has the highest leverage.
  • Use the higher-limit implementation model where long coding sessions and repeated verification are needed.
  • Use review passes to keep quality high instead of assuming the first implementation is final.
  • Spend token budget on the stage where it has the best return.

This is not about one model replacing the other. It is about assigning the right job to the right tool.

The actual product that came out of the workflow

The open-source repository contains a large collection of practical browser tools. The public tools can be explored from the DJAI tools hub, and the source is prepared for GitHub under the MIT License.

The project includes:

  • QR code generation with PNG and SVG export.
  • Image conversion between JPG, PNG, WebP, HEIC, and HEIF.
  • Image compression to target sizes like 100 KB and 500 KB.
  • Image resizing by exact dimensions, percentage, and social-media presets.
  • Image metadata removal and batch download workflows.
  • PDF merge, split, compress, rotate, watermark, protect, organize, page numbering, metadata removal, images-to-PDF, and PDF-to-images tools.
  • DOCX to PDF, HTML, Markdown, and text conversion.
  • PDF to text and PDF to Word workflows.
  • Thai-English OCR for scanned documents and images.
  • AI token counting for text, code, PDFs, and DOCX files.
  • PDF to AI-ready Markdown.
  • AI context optimization for cleaning repeated headers, footers, page numbers, and broken lines.
  • RAG chunk calculation with chunk preview and JSONL export.
  • Prompt packaging for combining requirements, docs, code, and references.
  • CSV to JSON, JSON to CSV, CSV cleaning, CSV merging, CSV splitting, CSV to XLSX, and XLSX to CSV tools.
  • Thai and English interfaces with language-specific pages and metadata.

A key product decision is that supported file processing happens locally in the browser whenever possible. Users do not need an account, and the tools are designed around privacy, speed, and practical daily use.

The review loop that made the product stable

The biggest mistake in vibe coding is treating AI output as finished just because the first version runs. A stronger process is to make review part of the build loop.

The workflow used here looked like this:

  • Ask Claude Code to plan or review a slice of the product.
  • Give Codex a clear implementation target.
  • Let Codex inspect the repo and make scoped changes.
  • Run builds, audits, local checks, and route verification.
  • Feed problems or review comments back into Codex.
  • Repeat until the code and product surface are stable.

This matters because many issues only appear after integration. A tool can work alone but break routing. A page can look correct but miss SEO metadata. A README can be accurate but fail to communicate the feature value. A license can be legally permissive but still need a polite attribution request in the README.

Review turns AI coding from a quick prototype method into a more serious product development method.

How other developers can use this repo for vibe coding

This repository can be used as a working base for people who want to build with AI instead of starting from a blank folder.

Developers can fork it and use it as:

  • A browser tool starter kit.
  • A Next.js multi-tool reference project.
  • A bilingual Thai-English product example.
  • A privacy-first file-processing reference.
  • A prompt engineering and AI context utility bundle.
  • A foundation for internal business tools.
  • A public SEO tool site template.
  • A portfolio project showing practical AI-assisted engineering.

The best way to use it is to pick one business problem and adapt the tool pattern. For example, a school could turn the document tools into a student submission preparation portal. A law office could create private document cleanup utilities. A cafe or hotel could build menu QR tools, image preparation tools, and guest document workflows. A marketing agency could build campaign asset converters. A software team could extend the AI tools into a prompt library, RAG preparation system, or internal documentation packager.

Business ideas that can grow from this codebase

The repo is not limited to the exact tools already built. It is a foundation. Because the tools are browser-based and modular, the same approach can support many practical products:

  • A white-label PDF and image tool suite for small businesses.
  • A Thai-English document processing portal for schools, clinics, hotels, and agencies.
  • A private client-file preparation system for freelancers.
  • A QR campaign builder for restaurants, events, and tourism businesses.
  • A social-media image preparation dashboard.
  • A resume, application, and document upload helper.
  • A local-first AI prompt packaging tool for development teams.
  • A RAG dataset preparation tool for companies building knowledge bases.
  • A bilingual utility website that earns traffic through useful free tools.
  • An internal operations toolkit where staff can process files without sending them to third-party services.

This is where vibe coding becomes useful for business. The goal is not to generate random apps. The goal is to turn repetitive operational problems into simple tools that save time, reduce mistakes, and create public value.

Why the MIT License matters

The repository is released under the MIT License. In practical terms, that means developers and users can use, copy, modify, merge, publish, distribute, sublicense, and sell copies of the software, including in commercial products, as long as the copyright notice and license text are preserved.

This matters because it removes adoption friction. A permissive license makes it easier for students, freelancers, startups, educators, and businesses to try the code without worrying about complex restrictions.

The README also includes a polite attribution request. That request is not the same as a legal restriction. The MIT License keeps the code open and easy to use. The attribution request simply asks people, when reasonable, to credit DJAI Academy, Siamese Cat Dev, or Siamese Cat Cafe if the tools help their public project or commercial product.

This balance is important. It helps the community because the software remains free and permissive. It helps the creator because backlinks, stars, follows, and public credit improve reputation and discovery. It also helps people find the cafe and the community work connected with supporting cat adoption and independent development.

What builders should learn from this workflow

The main lesson is that AI coding works best when the human still owns the product judgment.

Claude Code helped shape the plan and critique the work. Codex did most of the repo execution and stabilization. The human directed the mission: open-source useful tools, make them practical, make them bilingual, make them searchable, and connect the work back to DJAI Academy, Siamese Cat Dev, and Siamese Cat Cafe.

That is the real pattern to copy:

  • Start with a clear user problem.
  • Use AI to plan the system and expose tradeoffs.
  • Use a coding agent to implement in small, verifiable steps.
  • Review with another model or another pass.
  • Fix what the review finds.
  • Write documentation that explains the value clearly.
  • Release under a license that encourages adoption.

Final thought

This project is a practical example of modern AI-assisted product building. It shows how a solo developer or small team can combine planning models, coding agents, review loops, and open-source discipline to build something useful without burning unnecessary budget.

DJAI Academy is proud to present the work of Siamese Cat Dev and to share this repository with the wider developer community. Fork it, study it, adapt it, build your own tools from it, and give credit when you can.