Skip to content

Independent software product / Case 06

Public product · built by ConduitCode Labs

ConduitTools: building a growing collection of practical browser utilities

An independent ConduitCode Labs product turns recurring file, text, calculation, and developer tasks into focused browser tools. A shared Next.js foundation keeps the catalog consistent while each utility handles its own processing, feedback, and output.

Next.jsReactTypeScriptBrowser processingProduct engineeringPlaywright

What this solved for the business or user

ConduitTools is a product built and maintained by ConduitCode Labs. Visitors can open a utility, complete a task, and download or copy the result without creating an account. It covers PDFs, images, text, developer data, calculations, time, and other everyday work.

Open ConduitTools

What was happening

Small tasks repeatedly interrupt larger projects: converting an image, preparing a PDF, cleaning up JSON, generating a QR code, or comparing time zones. Each task is simple to describe, but a useful tool still needs clear inputs, understandable options, accurate output, and a layout that works on a phone as well as a desktop.

Why the obvious solution was not enough

A growing catalog can become difficult to navigate and expensive to maintain if every tool invents its own interface. File tools also need to explain format limits, processing states, and output tradeoffs. Browser processing reduces the need for server uploads, but it still has device limits and some features need additional libraries or model downloads.

How the solution works

  1. Use Next.js, React, and TypeScript for a shared application foundation, with individual routes for focused utilities.
  2. Maintain a central catalog with tool descriptions, categories, search keywords, routes, and availability so visitors can distinguish working tools from planned additions.
  3. Reuse navigation and interface patterns where they serve the same purpose, while keeping each tool's controls specific to its job.
  4. Process files and tool inputs in the browser for the browser-based utilities. Explain resource downloads where required, and distinguish tool processing from site analytics and deliberately submitted contact messages.
  5. Give users feedback they can act on: image previews and before-and-after sizes, selectable PDF modes, visible validation errors, and clear copy or download actions.
  6. Use task-appropriate libraries for file formats and structured data rather than recreating every parser or encoder.
  7. Check representative workflows with Playwright, including mobile layouts, file outputs, and tools with date, time, or data-format edge cases.

What should be verified before shipping

  • Confirm available catalog entries open working tool routes and planned tools are clearly marked.
  • Test representative file and text workflows with valid, empty, unsupported, and malformed inputs.
  • Inspect output files and copied data, including dimensions, file type, filenames, and content where relevant.
  • Check narrow-screen controls, keyboard access, loading states, and long filenames or validation messages.
  • Compare PDF compression modes and ensure a smaller download is offered only when the output is actually smaller.
  • Verify browser-processing claims against the implementation and keep model downloads, contact submissions, and analytics described separately.

What changed

The live catalog currently has 72 available tools and 1 planned addition. A shared product foundation supports expansion across file utilities, developer tasks, calculators, and everyday tools while keeping each workflow focused. The result is a public product people can use directly, alongside the client work documented in this portfolio.

Reusable lesson

A collection stays useful when each tool has a clear job and the shared foundation removes repeated work. Consistency helps people move between tools; careful input and output handling makes each one worth returning to.