DEV Community: ludy.dev

Building an AI Photo Enhancer Around a Verifiable Output

ludy.dev — Tue, 22 Sep 2026 08:38:21 +0000

I’m Ludy, and I built Uplenz, a web utility for enhancing photos with AI, comparing details, and downloading a PNG.

The product scope is intentionally small. The interesting engineering discussion isn’t "how many editing controls can fit on a page?" It’s "how do you help someone evaluate a generated result without hiding the constraints?"

Start with the processing contract

At the product level, the flow is an input image, an AI enhancement operation, a comparison step, and a PNG download.

That sounds simple, but each boundary deserves a clear contract. An accepted image isn’t the same as a completed edit. A completed edit isn’t the same as a successful download. And an unavailable processing slot shouldn’t look like a broken upload.

Those distinctions are the foundation I’d use to review any implementation of this workflow.

Stack choices versus observable behavior

The underlying framework, inference provider, hosting setup, and storage implementation aren’t detailed in this launch post. I don’t want to turn an architecture discussion into an invented stack diagram.

What is observable is the browser-based workflow and the AI enhancement step. For a technical review, I’d separate image input, processing orchestration, result presentation, and export into distinct responsibilities, regardless of the specific libraries involved.

That separation makes it easier to reason about failures without coupling every UI state to one long request.

No signup still needs resource boundaries

Uplenz requires no signup and offers up to three shared free AI edits daily, subject to capacity.

That makes capacity communication a core interface concern. "Free" doesn’t mean computation has no cost, and anonymous access doesn’t remove the need for resource controls.

A useful design review would ask when availability is checked, how a failed attempt is explained, and whether the interface makes it obvious when someone should retry. Those are architectural questions as much as copywriting questions.

The output needs inspection

AI enhancement can create convincing artifacts. A comparison experience should help users notice those changes rather than just celebrate a more dramatic image.

I’m especially interested in feedback on comparing fine textures, evaluating faces, and making the download step unambiguous.

Try Uplenz with an image you know well. What would you inspect first, and what information would you need before trusting the result?

I built a lightweight aspect ratio calculator with vanilla JavaScript

ludy.dev — Tue, 22 Sep 2026 07:23:17 +0000

I built AspectDock after repeatedly doing the same aspect-ratio calculations while working on images, video exports, and responsive layouts.

The underlying math is straightforward, but building a useful interface around it raised a few interesting implementation questions.

Two Calculation Modes

The first mode accepts a width and height, then calculates the ratio. To reduce the dimensions, the app finds the greatest common divisor of the two values and divides both by it. For example, 1920 × 1080 becomes 16:9 instead of a long decimal representation.

The second mode starts with a selected ratio and one known dimension. The missing dimension is calculated using the ratio components. A 16:9 ratio with a width of 1280 produces a height of 720.

Keeping these modes separate makes the input model easier to understand and avoids mixing incomplete values with stale results.

Handling Precision

Pixel dimensions are usually integers, but ratio calculations can produce fractional values. The UI keeps the ratio calculation precise while presenting dimension results in a practical format. This matters when working with responsive containers or print dimensions where rounding can affect the final output.

Validation also needs to cover empty fields, zero values, negative numbers, and incomplete input. A calculator should fail clearly rather than silently return misleading values.

Keeping the App Lightweight

The current implementation is intentionally small: semantic HTML for the structure, CSS for the layout and responsive behavior, and client-side JavaScript for all calculations. No server request is required for the core experience, so results appear immediately and the tool remains useful even when the calculation itself is the only thing someone needs.

Common ratios are treated as quick presets rather than hidden behind another menu. Copyable results are also important because the usual next step is pasting the value into a design brief, CSS file, or export dialog.

What I Learned

The hardest part was not the formula. It was deciding what information to show, when to show it, and how to make the interface feel predictable.

You can try the finished version at AspectDock. I would especially appreciate feedback on input validation, decimal handling, and whether the two-mode workflow feels natural.

Building ErasePeople: The Hard Part Is Defining Who Disappears

ludy.dev — Sun, 13 Sep 2026 15:44:09 +0000

This is an architectural model, not a disclosure of ErasePeople’s internal implementation.

At each boundary, there’s a different class of problem. Image orientation can affect coordinates. Selection can become ambiguous when people overlap. Reconstruction can introduce artifacts. Export can accidentally diverge from what the preview showed.

Keeping those concerns separate makes the system easier to reason about than treating the entire operation as one opaque "edit" button.

Stack transparency matters

The public product information describes an AI photo-removal website, not its framework, model provider, storage layer, or deployment platform. I’m keeping those implementation details out of this post rather than presenting an invented stack as a build log.

For anyone implementing a similar application, I’d evaluate the stack around image handling, asynchronous processing, error recovery, and clear data-retention behavior. Those requirements matter more than choosing a fashionable frontend.

Comparison is part of correctness

A technically successful response can still be a bad edit.

The comparison step gives users a way to inspect whether the intended person disappeared and whether important surroundings remained plausible. That makes it part of the product’s quality loop, not just a presentation feature.

I’d like feedback from developers working on image interfaces: how would you express ambiguous "background people" intent without making the user complete a complicated selection workflow? You can try the current experience at ErasePeople.

How I built a lightning-fast, ad-free web novel reader using Next.js and Cloudflare

ludy.dev — Fri, 07 Aug 2026 18:38:02 +0000

Reading web novels online is a notoriously laggy experience. Most aggregator sites are packed with heavy tracking scripts, bloated ad networks, and redirects that make mobile reading painful. I wanted to see if I could build a platform that serves thousands of chapters with sub-second page loads.

That is why I created MuBooks.

To achieve maximum performance, I built the frontend using Next.js. The reading interface relies heavily on static generation where possible, combined with server-side rendering for newly updated chapters. I offloaded the heavy lifting to Cloudflare Workers to cache the parsed, sanitized chapter content at the edge. By removing the tracking scripts, ads, and heavy assets, the payload size for a standard chapter is under 50KB, resulting in instantaneous page transitions.

One of the biggest technical challenges was processing the raw chapter feeds. The source files often contain inconsistent HTML formatting, broken tags, and inline styles. I built a custom parser pipeline that strips out all non-essential HTML, sanitizes the text to prevent XSS, and normalizes the structure into clean, responsive Markdown-style components.

For the client side, I built a highly responsive reader component. Using lightweight Tailwind classes and local storage, users can toggle dark mode, adjust font scaling, and change line heights. The state is saved locally, meaning the user can resume reading exactly where they left off without needing an external database call.

By keeping the architecture lightweight and caching aggressively at the edge, the hosting costs remain minimal while providing a premium, native-app-like experience for readers.

Building a lightning-fast Roblox Wiki using Next.js and Markdown

ludy.dev — Wed, 08 Jul 2026 04:47:04 +0000

Most gaming wikis are built on legacy platforms like Fandom, which are notorious for layout shifts, aggressive ad networks, and terrible mobile performance. When I started playing Storage Hunters on Roblox, I realized the community desperately needed a fast, mobile-friendly database to check item values on the fly.

To solve this, I built Storage Hunters Wiki using Next.js, Tailwind CSS, and Markdown.

Using Static Site Generation (SSG), I pre-render all item database pages at build time. The search functionality is implemented client-side using a simple JSON index, which allows instant filtering of hundreds of in-game items without hitting a server. I also integrated an interactive map component using custom SVG coordinates to track Lost Items, which keeps the bundle size incredibly small compared to pulling in heavy map libraries.

The result is a lightweight resource that loads under 500ms on mobile devices, allowing players to pull up trade values instantly.

Building a Client-Side Grid Solver for Block Blast in React

ludy.dev — Tue, 07 Jul 2026 05:28:58 +0000

I recently built a tool to solve board layouts for the popular mobile puzzle game Block Blast. The app runs completely on the client side and helps players figure out the optimal placement for their blocks to maximize their score or clear lines.

The core engine relies on a backtracking search algorithm. In Block Blast, you get three pieces at a time and must place all three to receive the next batch. This means for any given turn, the solver needs to calculate the permutations of placing these three pieces onto an 8x8 grid.

To model this, the board is represented as a 2D array of boolean values. The pieces are defined by their relative coordinates. The algorithm checks every permutation of the three pieces ($3! = 6$ possible orders) and recursively attempts to place them in all valid coordinates on the grid.

Once a valid placement sequence is found, it calculates a heuristic score for the resulting board state. The heuristic evaluates:

Number of cleared lines (full rows or columns)
Number of empty cells remaining
Grid fragmentation (isolated empty spaces that are hard to fill)

To make the user experience seamless, I implemented an HTML5 Canvas interface that allows users to either manually tap the grid to match their game board or upload a screenshot.

You can check out the live tool at Block Blast Solver to see the solver in action. I would love to hear your thoughts on optimization strategies for the heuristic search function!

I built a collection of 160+ client-side utility calculators using Next.js and Tailwind CSS

ludy.dev — Thu, 25 Jun 2026 14:50:57 +0000

As web developers, we often build complex SaaS products, but sometimes the most satisfying projects are clean, fast utility tools. Recently, I set out to build MultiCalcTool, a collection of over 160 free calculators designed to replace the slow, ad-bloated legacy calculator sites that dominate search engines. Here is a breakdown of the tech stack and the architectural decisions I made to keep it fast.

The Architecture: Pure Client-Side Execution

One of my core requirements was speed and privacy. I decided that all calculations should run entirely client-side. There is no backend database processing user inputs. Whether someone is calculating their monthly mortgage payments, estimated income tax, or body mass index, the math happens instantly inside their browser.

To achieve this, I used Next.js to handle static site generation and page routing, combined with Tailwind CSS for a responsive, clean design system. Each calculator page is statically exported, meaning the HTML is pre-rendered at build time. When a user visits a calculator, they download a tiny, optimized JavaScript bundle that handles only the formula logic for that specific tool.

Managing 160+ Unique Calculation Formulas

Managing the math logic for over 160 distinct tools was a major organizational challenge. I structured the codebase by separating the UI components from the mathematical engine. Each category (finance, math, health, tax) has a dedicated directory of mathematical utility functions.

For instance, the financial formulas use standard amortization algorithms, while the construction calculators rely on precise geometry functions. I implemented TypeScript across the entire project to ensure that input variables were strictly typed. This prevented runtime rounding bugs, which are common when dealing with JavaScript's floating-point precision.

Optimizing for Page Speed

Since utility websites rely heavily on organic search traffic, performance metrics were critical. By keeping the pages static and leveraging local client-side execution, the site achieved near-perfect core web vitals. There are no external tracking scripts or advertising SDKs blocking the main thread, resulting in instantaneous page loads even on slower mobile connections.

The project is now live, and I would love to hear feedback from other developers on how to improve the overall responsive layout.

Building a Zero-Database, No-Signup Quiz Engine for Instant Psychometric Scoring

ludy.dev — Tue, 23 Jun 2026 05:18:08 +0000

The scoring engine is a lightweight, pure JavaScript function. As the user selects answers, the engine mutates an in-memory vector representing the scoring dimensions.

For the MBTI test, it calculates the raw coordinate offsets across the four dichotomies (E/I, S/N, T/F, J/P). For the IQ test, it matches the cumulative correct answers against a statically loaded age-based standard deviation matrix to output a normalized percentile score instantly.

The Challenge of Shareable Results Without a Database

If there is no database storing the results, how can a user share their unique score page with a friend?

I solved this by using high-entropy URL state encoding. When a user completes a test, the scoring engine compiles their performance vector, compresses it using a lightweight LZW compression algorithm, and serializes it into a Base64-like URL token:

https://quizvex.com/results/mbti?data=e30xNDIsLTEyLDM0fQ==

When the /results route loads, the client-side router decompresses the token, hydrates the state vector, and renders the custom SVG charts on the fly. No read queries, no database latency, and absolute privacy for the user.

Keeping CLS at Absolute Zero

Because quizzes involve constant DOM updates as users transition from question to question, Cumulative Layout Shift (CLS) was a major concern. To prevent layout jumps, the question container uses a fixed-aspect-ratio CSS Grid container with hardware-accelerated CSS transitions for slide-in animations. This guarantees a smooth 60fps experience even on low-end mobile devices.

I’d love to hear your thoughts on this stateless approach. How do you handle complex scoring algorithms without bloating your backend? Let's discuss in the comments!

Bayesian math is hard, so I built a zero-database A/B test & conversion calculator

ludy.dev — Tue, 23 Jun 2026 05:17:52 +0000

Keeping the UI Fast

For the frontend, I went with React and Tailwind CSS. Instead of pulling in heavy charting libraries that bloat the bundle size, I wrote custom lightweight SVG generators for the funnel visualizations. This kept the entire site's initial load size under 45kb gzipped, making it load almost instantly.

If you are tired of heavy analytics dashboards and just want a fast, clean way to calculate your conversion rates, model your funnels, and test significance, try it out at simplifyconversion.com. I would love to hear your feedback on the math implementation or the UI!

Building a 10-in-1 Daily Puzzle Hub That Works Offline and Weighs Under 1MB

ludy.dev — Tue, 23 Jun 2026 05:17:23 +0000

By seeding this pseudo-random number generator with the current date, we get consistent daily boards globally without a single API request.

True Offline Support with Workbox

To make the app work offline, I configured Vite's PWA plugin with a custom Workbox Service Worker strategy.

We aggressive-cache all essential game assets (HTML, CSS, JS, and local dictionary modules). Since the daily game configurations are generated programmatically via the local date seed, users can play the current day's puzzles in the middle of a flight or deep inside a subway tunnel without losing their progress. Game states and daily streaks are automatically serialized and synced to localStorage.

Check out the live build at https://puzzleboxs.com, try turning off your network connection, and let me know what you think of the performance and offline synchronization!

Building a distraction-free poetry database that scores 100 on PageSpeed (No bloat, just beautiful layouts)

ludy.dev — Tue, 23 Jun 2026 05:17:08 +0000

By parsing this with a customized unified/remark pipeline, I preserved standard line-breaks using CSS white-space: pre-wrap on the container elements. This ensures that the delicate, visual spacing of poets like Walt Whitman or William Carlos Williams renders exactly as intended on both desktop and mobile screens.

Achieving 100/100 PageSpeed

To give students and writers a fast, distraction-free environment:

Static Generation: Every page is pre-rendered at build time. No database queries on runtime.
Tailwind CSS: Using utility-first CSS keeps the global stylesheet footprint under 6KB.
Zero Bloat: Swapped heavy tracker scripts for privacy-first, lightweight analytics.

I'd love to hear your thoughts on how you handle preserving formatting for sensitive text structures. Check out the live build at poemexamples.com and let me know what you think of the performance!

I built a 3D printing parameter optimizer using Next.js and WebAssembly

ludy.dev — Tue, 23 Jun 2026 05:16:30 +0000

This keeps the main bundle small while enabling powerful computational modeling on the client.

I'd love to hear your feedback on the architecture, especially if you've done client-side ML in Next.js before!