DEV Community: ludy.dev

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!

Building a 100% Client-Side PDF Merger: How I Bypassed Server-Side Processing for Ultimate Privacy

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

We have all been there. You need to combine three PDFs for a tax filing or a job application, so you search for a quick tool online. You end up uploading sensitive documents containing your SSN, address, or financial history to a mysterious, ad-ridden server.

As a developer, this always rubbed me the wrong way. Why do we need to send megabytes of personal data over the wire just to append a few byte streams together? The answer is: we don't.

I set out to build a completely free, zero-registration PDF merger that does 100% of the heavy lifting right inside the user's browser. No backend APIs, no remote servers, and absolutely zero data leaks. Here is how I did it.

The Tech Stack: Running it All in the Browser

To achieve zero-server processing, I needed a library that could parse, modify, and serialize PDF documents completely on the client side. I chose pdf-lib due to its robust API and active ecosystem.

Unlike traditional server-side rendering tools (like PDFKit or standard CLI tools), pdf-lib allows us to load PDFs as binary ArrayBuffer data arrays directly in the browser's memory space.

Here is the high-level architecture of the merge process:

The user drags and drops their files.
The browser reads the files as ArrayBuffer using the HTML5 FileReader API.
We instantiate a new PDFDocument in memory.
We loop through each uploaded file, load it via pdf-lib, copy the pages, and add them to the main document.
The combined PDF is serialized back into a Uint8Array and instantly triggered as a local browser download.

Overcoming Browser Constraints

While client-side processing is incredible for privacy, it comes with a major bottleneck: browser memory limits.

If a user tries to merge five 50MB PDFs on a low-end mobile device, the browser tab will easily crash due to out-of-memory (OOM) errors.

To solve this, I implemented several optimizations:

Garbage Collection Optimization: Explicitly dereferencing massive arrays and forcing garbage collection paths.
Asynchronous Chunking: Processing page copying in sequential chunks rather than all at once, preventing the UI thread from freezing.
On-the-Fly Compression: Strip out unnecessary metadata and duplicate font definitions that often bloat merged files.

The Result

The result of this weekend project is pdfmergeapp.com. It is incredibly fast because there is zero network latency for uploads or downloads. Best of all, if you inspect the network tab while using it, you will see exactly zero outbound requests containing your document data.

I’d love to hear your thoughts on optimization tricks for handling even larger files (100MB+) purely in the browser. Have you experimented with WebAssembly or Web Workers for client-side file manipulation? Let’s chat in the comments!

Programmatic SEO without the bloat: Building a 500+ page static resource hub with Astro

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

At build time, Astro parses the JSON array, generates static HTML files for all 500+ routes, and writes them straight to the disk.

Overcoming the Build-Time Bottleneck

When you generate hundreds of pages programmatically, asset optimization can slow down your builds significantly. Initially, my build times on Cloudflare Pages were dragging towards the 3-minute mark because of dynamic image optimization and massive CSS parsing per page.

I solved this by:

Standardizing layout components to prevent style duplication.
Relying on Tailwind's JIT compiler to keep the global CSS payload under 15kb.
Pre-indexing the templates into a lightweight local JSON search index so users can query jobs instantaneously without a heavy search engine backend.

The result? The entire project builds in under 22 seconds, scores a perfect 100/100 on Lighthouse desktop performance, and serves instantly to users who just want to grab a template and apply for their next gig.

Check out the live site at mycoverletter.org and let me know what you think of the speed! I'd love to hear your feedback on the UI or how I can optimize the static build pipeline even further.

Building a 100% Client-Side JPG to PDF Converter (And Why I Skipped the Backend)

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

This reduced the final PDF file size by up to 75% without noticeable loss in document readability.

Auto-Fitting to Standard Page Sizes

Calculating the correct scaling factors for arbitrary image ratios to fit beautifully onto A4 pages was a fun math challenge. The tool detects whether the image is landscape or portrait, sets the PDF page orientation dynamically, and computes the margins so that the image is perfectly centered without clipping.

Hosting & Zero Overhead

The site is hosted on Cloudflare Pages because the entire app is just static JS, HTML, and Tailwind CSS. The running cost is practically $0/month, and it can scale to millions of users without any server overhead.

If you want to convert some images securely, give it a spin at jpgtopdfweb.com. I'd love to get your feedback on the client-side performance!

Building a static repository for print-perfect PDFs

ludy.dev — Wed, 17 Jun 2026 07:20:28 +0000

Most print-ready websites are slow, bloated, and covered in ads. I wanted to build a clean directory for paper templates that loads instantly and prints perfectly.

I built PrintableCove to solve this.

The tech stack is lightweight: Astro for generating static pages and Tailwind CSS for styling. The major technical challenge was ensuring that the PDF files and print stylesheets rendered exactly to scale. When dealing with graph paper or lined paper, a millimeter deviation on screen can ruin the physical print grid.

To solve this, I designed the PDF templates directly using vector exports to guarantee clean scaling at 300 DPI on standard Letter and A4 sizes. I also implemented CSS @media print rules on the web previews to hide layout grids and menus, allowing users to print directly from the browser window if they choose not to download the PDF.

Hosting static assets on a global CDN means the site loads in under 200ms anywhere in the world. No databases, no dynamic server lag, just clean vector resources ready for the physical world.

I built a fast, static template library for small businesses using Astro and Tailwind

ludy.dev — Sat, 13 Jun 2026 14:37:04 +0000

I recently needed a clean, standard profit and loss template for a side project. After clicking through dozens of template sites that forced me to register or sign up for a trial, I got annoyed enough to build my own open directory of document templates.

I wanted the site to be incredibly fast, simple, and require zero database overhead.

The Tech Stack

I chose Astro for this project because it is perfect for content-focused websites. Since the templates themselves (Excel, Word, and Google Sheets files) are static assets, there was no need for a dynamic backend.

Framework: Astro (SSG mode)
Styling: Tailwind CSS
Deployment: Cloudflare Pages for global low-latency delivery

Using Astro allowed me to keep the JavaScript footprint at absolute zero on the client side. The templates are organized using Astro's content collections, which makes managing metadata for each template type (like category, file formats, and download links) highly structured and type-safe.

Handling File Downloads Efficiently

Instead of hosting download files on a heavy cloud storage bucket, I opted to bundle them directly into the static build assets directory. This keeps the download speed high and costs at zero.

For Google Sheets templates, instead of direct file downloads, the site provides a pre-formatted template copy link (/copy endpoint pattern) which prompts the user to make a clean copy directly in their own Google Drive workspace, avoiding any permission sharing issues.

If you want to check out the design or grab some clean files for your own business operations, you can visit BizKitly. I would love to hear your feedback on the layout and site performance.

How I Compiled 30-Year-Old Console Emulators to WebAssembly to Play 3,000+ Retro Games in the Browser

ludy.dev — Sat, 13 Jun 2026 04:51:20 +0000

I’ve always had a massive soft spot for retro games. There’s something magical about the 8-bit and 16-bit eras of FC (NES), SFC (SNES), GBA, and classic arcade games. But modern emulation is surprisingly fragmented. You have to download native apps, hunt down sketchily hosted ROMs, configure controller mappings, and hope you don't download a Trojan in the process.

I wanted to change that. I thought: modern browsers are basically lightweight operating systems. Why not bring the entire console library to the web?

So, I built laowanke.com—a zero-download, instant-play nostalgic gaming platform running over 3,000+ retro games directly in the browser. Here is how I pulled off the engineering under the hood.

The Tech Stack: Porting C/C++ Cores to WebAssembly

The absolute backbone of this project is WebAssembly (Wasm). Instead of writing emulation engines from scratch in JavaScript (which would be painfully slow and inaccurate), I leveraged legendary open-source C/C++ emulation cores (like retroarch/libretro projects) and compiled them using Emscripten.

By compiling these mature codebases to Wasm, I achieved near-native execution speed. The browser runs the game loops, processes CPU/GPU instructions of these vintage consoles, and pipes the video/audio output directly to a <canvas> element and the Web Audio API.

Solving the Real-time Save State Challenge

One of the biggest hurdles was managing save states. Classic game cartridges used battery-backed RAM (SRAM) to save progress, while modern emulators use state snapshots (save states).

To make this feel like a modern cloud gaming experience, I had to map the Wasm virtual file system to the browser's persistent storage. I implemented a hybrid storage system:

IndexedDB handles local persistence for auto-saves and manual save slots. It operates asynchronously, so I had to write a JS wrapper that hooks into the emulator's save state cycle without blocking the main rendering thread.
If a player logs in, these IndexedDB blobs are synced to a lightweight backend database, letting them resume their Pokémon GBA run on their phone right where they left off on their desktop.

Taming Audio Latency and Input Lag

In retro action games, a 50ms delay in button inputs or audio sync makes the game completely unplayable.

To solve input lag, I bypassed the standard browser keyboard events wherever possible and used the Gamepad API with a high-frequency polling loop mapped directly to the Wasm input registers. For audio, standard HTML5 Audio wasn't fast enough, so I implemented a dynamic audio buffer using the Web Audio API AudioWorklet. The Worklet pulls raw PCM audio data directly from the Wasm memory space in real-time, completely eliminating crackling and latency.

What's Next?

Right now, the platform supports keyboard controls, gamepads, save/load states, and a smooth catalog search UI. Next, I'm working on stabilizing WebRTC-based netplay so two players can play cooperative arcade games across different networks.

I’d love to get your thoughts on the performance and latency. Give it a spin at laowanke.com and let me know how it handles on your machines!