DEV Community: Vago Neue J

Why I Built a Printable Puzzle Generator and What It Taught Me About Web App Architecture

Vago Neue J — Fri, 10 Apr 2026 06:58:26 +0000

Last year I was stuck in one of those motivational dead zones that every developer hits eventually. My day job was fine but unstimulating. I wanted to build something — anything — just to remember what it felt like to ship a project from scratch without a product manager breathing down my neck about sprint velocity.

The idea came from an unlikely place: my daughter's homework.

She was in third grade and working on her multiplication tables. My wife asked me to print out a multiplication chart so she could hang it next to her desk. Simple enough, right? Except every site I found was either covered in ads, required some weird sign-up, or produced a blurry, ugly PDF that looked like it was designed in 1998.

I thought: I'm a web developer. I can build this in a weekend. And that thought spiraled into a three-month side project that taught me more about practical web architecture than I expected.

The Seed of the Idea

The multiplication chart thing was genuinely the starting point. I spent a Saturday afternoon building a clean, responsive web page that generates a Multiplication Chart Printable with customizable dimensions, clean typography, and a CSS print stylesheet that actually produces a good-looking result when you hit Ctrl+P.

That was about four hours of work, and honestly it was satisfying in a way that my day-to-day work rarely is. There's something deeply gratifying about building a tool that does one thing well. No login required. No feature creep. No "premium tier." Just a page that solves a specific problem cleanly.

But then I got curious. What other simple printable tools are people searching for? I started poking around Google Trends and keyword tools, and I discovered an entire ecosystem of people looking for printable resources online — graph paper, lined paper, dot grids, calendars, planners, sheet music, and (this one surprised me) Sudoku puzzles.

Turns out there's a huge demand for printable Sudoku. Like, way more than I expected. And most of the existing solutions were, again, either ad-heavy nightmares or limited in their puzzle generation capabilities.

So I built Sudoku Printable as my second project, and this is where things got technically interesting.

The Architecture Problem: Generating Puzzles on the Client

Here's the thing about Sudoku generation that I didn't fully appreciate before I started: creating a valid Sudoku puzzle is a constraint satisfaction problem, and generating puzzles with a unique solution at specific difficulty levels is genuinely non-trivial.

My first instinct was to do what a lot of developers do — throw the heavy lifting to the backend. Spin up a Node server, write a puzzle generator in JavaScript, cache generated puzzles in Redis, serve them via API. Classic architecture.

But I wanted this to be a zero-cost project. No server. No database. No monthly hosting bill. Just a static site.

That constraint forced me to think differently. Everything had to happen in the browser.

The puzzle generation algorithm works in two phases. First, you generate a complete, valid Sudoku grid using a backtracking algorithm. You start with an empty 9x9 grid, place numbers according to Sudoku constraints (no repeats in any row, column, or 3x3 box), and when you hit a dead end, you backtrack and try a different number. This is basically a depth-first search with constraint pruning.

The second phase is where difficulty comes in. You start with the completed grid and strategically remove numbers, checking after each removal that the puzzle still has exactly one solution. The number of cells you remove and the patterns of removal determine the difficulty. Easy puzzles might leave 35-40 given numbers. Hard puzzles might leave 25 or fewer.

That uniqueness check is the expensive part. For each removal, you need to verify that there's still only one way to solve the puzzle. I implemented a solving algorithm (also backtracking-based) that counts solutions and stops as soon as it finds a second one.

On modern hardware, this runs in the browser in under a second for most puzzles. But on older devices or when generating multiple puzzles at once (for a printable sheet of six puzzles), I hit performance issues.

The Web Worker Solution

My fix was to move puzzle generation into a Web Worker. This keeps the main thread free for UI updates and prevents the browser from becoming unresponsive during generation.

The architecture ended up looking something like this: the main thread sends a message to the worker requesting N puzzles at a given difficulty. The worker generates them in the background and posts them back when done. The main thread then renders them into the DOM and applies print-specific CSS for clean output.

This pattern — offloading CPU-intensive work to Web Workers — is something I'd read about plenty of times but never had a genuine reason to implement. Building this puzzle generator was the first time the pattern clicked for me in a practical sense.

One thing I learned: communicating complex data between the main thread and a worker via postMessage is straightforward, but you need to be careful about data serialization. I was initially passing puzzle objects with methods attached, which doesn't work because postMessage uses the structured clone algorithm, which strips functions. The fix was to pass plain data objects and reconstruct the puzzle instances on the receiving side.

Print Stylesheets Are an Underrated Skill

A surprising amount of my development time went into print CSS. And I think this is a genuinely underrated skill in the web development world.

Most web developers never think about how their pages look when printed. And for most web apps, that's fine — nobody prints a dashboard. But for a printable resource generator, the print output is the entire product.

I learned a bunch of things I didn't know:

The @media print query lets you completely restyle the page for printing. I hide all navigation, buttons, and interactive elements, and expand the puzzle grid to fill the page.

The @page CSS rule lets you set page margins, orientation, and size. For puzzle sheets, I use @page { size: letter portrait; margin: 0.5in; } to get consistent output across different printers.

Page breaks are controlled with break-before, break-after, and break-inside properties. When printing a multi-page sheet of puzzles, you need to tell the browser where to break pages. Getting this right took more trial and error than I'd like to admit.

Color accuracy is another consideration. What looks great on screen might not print well, especially on lower-quality printers. I ended up using high-contrast black-and-white designs specifically because they print reliably on any hardware.

The Multiplication Chart: Simpler But Instructive

Going back to the multiplication chart project — this one was architecturally much simpler, but it taught me a lot about responsive layout and dynamic content generation.

The chart is essentially a large HTML table generated by JavaScript. You choose the range (say, 1 through 12, or 1 through 20), and the JavaScript generates the corresponding table with properly calculated products.

The interesting challenge was making this look good at any size. A 12x12 chart fits neatly on a letter-sized page. A 20x20 chart requires smaller font sizes and tighter cell spacing. A 25x25 chart starts pushing the limits of what's readable on a single printed page.

I ended up using CSS Grid for the layout (instead of an HTML table element) because it gave me more control over cell sizing and spacing. The grid dimensions are set dynamically via CSS custom properties that JavaScript updates when the user changes the chart range.

One thing I'm proud of: the print output of the multiplication chart is genuinely clean. No border artifacts, consistent cell sizes, centered text in every cell, and a clear header row and column that make the chart easy to read on paper. Getting there required a bunch of small CSS tweaks that don't show up in any tutorial but make a real difference in the final product.

What This Taught Me About "Small" Projects

There's a tendency in our industry to devalue small projects. If you're not building the next SaaS platform or open-source framework, it doesn't "count" as real engineering. I've heard this attitude from hiring managers, from colleagues, and honestly from my own internal monologue.

But building these printable tools taught me more about practical web development than a lot of the "serious" projects I've worked on.

I learned about constraint satisfaction algorithms by building the Sudoku generator. I learned about Web Workers by needing them for a real performance problem. I learned about print CSS by having to deliver a real print-quality product. I learned about responsive design by making charts look good at ten different sizes.

And critically, I learned about shipping. These projects have users. Real people visit these sites, generate puzzles and charts, and print them out for their kids, their classrooms, their brain-training routines. That feedback loop — build a thing, ship it, watch people use it — is the whole point of being a developer, and small projects give you that loop much faster than large ones.

The Technical Takeaways

If you're looking for a side project that teaches practical web skills, I'd genuinely recommend building a printable resource generator. Here's why:

Client-side rendering gives you practice with DOM manipulation, dynamic content generation, and performance optimization without the complexity of a backend.

Print CSS is a real skill that most developers lack. If you ever need to generate reports, invoices, or any printable output from a web app, you'll be glad you learned it.

Algorithmic thinking shows up in surprising places. Sudoku generation is a legitimate computer science problem. So is optimizing layout algorithms for different chart sizes.

Static site architecture forces you to think creatively about what's possible without servers. My hosting cost for these projects is literally zero because they're deployed as static sites on Netlify.

SEO and discoverability are real-world skills. Getting these sites in front of users required learning about metadata, page structure, content strategy, and search intent — all things that make you a more well-rounded developer.

Where I Am Now

Both projects get steady traffic. Nothing life-changing — a few thousand visitors per month each — but enough to validate that people find them useful. I don't monetize them, and I don't plan to. They exist because I needed a project, and they continue to exist because they solve real problems for real people.

The code is straightforward. The architecture is simple. The pages load fast and work offline (both are PWAs). And every time I hear my daughter using her multiplication chart, or see a comment from a teacher saying they use the Sudoku printable for their classroom, I'm reminded why I got into this field in the first place.

Not every project needs to be ambitious. Sometimes the best thing you can build is the simplest thing that actually helps someone.

If you're in a creative rut, try building something printable. The constraints are different from typical web development, the skills transfer directly to professional work, and the feeling of holding a physical artifact that your code produced is weirdly satisfying. Give it a shot.

Building a Freelance Side Hustle as a Developer: Tools That Actually Save You Time

Vago Neue J — Fri, 10 Apr 2026 06:53:12 +0000

I picked up my first freelance gig almost by accident. A friend of a friend needed a simple landing page, and I was bored on a Saturday. Fifty bucks and a six-pack later, I had a live site and what felt like a revelation: people will pay you real money to do things you already know how to do.

That was five years ago. Since then, freelancing has gone from a random weekend favor to a legitimate side income stream that brings in a few thousand dollars a month on top of my day job. And the single biggest lesson I've learned in that time has nothing to do with code — it's that the administrative overhead of freelancing is what kills most side hustles before they ever get traction.

Writing code is the fun part. Chasing down payments, generating invoices, keeping track of project hours, communicating with non-technical clients — that's where people burn out and quit.

So let's talk about the tools that have made the boring parts tolerable.

Invoicing: The Thing You Keep Putting Off

I'll admit it — for my first several freelance projects, I "invoiced" clients by sending them a Venmo request with a smiley face. Shockingly, this did not scale well.

The turning point was when I landed a small business client who needed actual invoices for their bookkeeping. You know, with line items, dates, a proper total, maybe a payment terms section. The kind of thing that looks like a real business sent it.

I tried a few different tools before landing on Online Invoice Generator. What I like about it is that it doesn't try to be a full accounting platform. I don't need QuickBooks. I don't need a subscription service that sends me fourteen emails about upgrading my plan. I just need to generate a clean, professional-looking invoice, download it as a PDF, and send it to my client.

You fill in your details, the client's details, add your line items with descriptions and amounts, and it spits out a proper invoice. The whole thing takes maybe three minutes. I keep a simple spreadsheet to track which invoices I've sent and which have been paid, and honestly that's been enough for my volume of clients.

One tip that took me way too long to learn: always include payment terms on your invoice. "Due within 14 days" or "Net 30" — whatever works for you. Having it written on the invoice gives you something concrete to point to when you follow up. Before I started doing this, I had clients sitting on payments for months because there was no explicit expectation.

The Graph Paper Situation (Yes, Really)

This one requires some context, because on the surface it sounds absurd.

I do a lot of my initial project planning on paper. Not because I'm some analog purist — I spend ten hours a day staring at screens and sometimes I just need to think with a pen. When I'm sketching out database schemas, wireframing UI layouts, or mapping out API endpoint structures, I reach for graph paper because the grid helps me keep things organized and roughly to scale.

The problem was that I kept running out of graph paper and never remembering to buy more. The office supply store near me closed, and ordering a pad of graph paper on Amazon felt ridiculous for a $4 item with $6 shipping.

Then I found Printable Graph Paper and my dumb little problem was solved forever. You pick your grid size, choose your page orientation, and print as many sheets as you want. I keep a small stack next to my desk now, and whenever I'm starting a new project or working through a tricky architecture decision, I grab a sheet and start drawing.

I know this sounds trivial, but the value of having a physical medium for brainstorming — especially when you're freelancing and need to translate a client's vague description into an actual technical plan — is genuinely underrated. I've caught more design problems on paper than in any review tool.

Getting Paid What You're Worth

The financial side of freelancing is where most developers leave money on the table, and it usually comes down to not doing the math before quoting a project.

Here's the scenario: a client asks "how much would it cost to build X?" You want to be competitive, so you throw out a number that feels reasonable. But you forgot to account for the three rounds of revisions, the scope creep that always happens, the time you'll spend on calls explaining things, and the fact that you're essentially giving yourself a pay cut because freelance income doesn't come with benefits, retirement contributions, or paid time off.

When I started treating freelancing like an actual business, I began running numbers more carefully. What's my effective hourly rate after accounting for non-billable time? How much has my rate actually increased year over year? If a client wants a 20% discount, what does that actually mean in terms of my total project compensation?

I use the Percentage Increase Calculator for these kinds of comparisons pretty regularly. It sounds simple, but when you're comparing quotes, tracking rate changes, or trying to figure out whether a "small" price adjustment is actually significant, having a tool that handles the math cleanly is surprisingly useful.

For example, I raised my rate from $85/hour to $110/hour last year. Feels like a solid bump, right? But what's the actual percentage increase? It's about 29.4%. Knowing that number precisely helped me communicate the rate change to existing clients more confidently — "I'm adjusting my rate by roughly 30% to align with market rates" sounds a lot more intentional than "I'm charging more now."

Managing Client Expectations

The hardest part of freelancing isn't the code. It's the communication.

Most of your clients are not technical. They don't know what a REST API is. They don't understand why "just move the button" might require refactoring a component hierarchy. And they absolutely do not want to hear about your build pipeline.

What they care about is: when will it be done, how much will it cost, and will it look good?

I've found that the invoicing process is actually a powerful communication tool. When your invoice has clear line items — "Homepage redesign: 8 hours at $110/hr" versus just "Website work: $880" — the client can see exactly what they're paying for. It reduces disputes, sets expectations for future work, and frankly makes you look more professional.

This is another reason I like tools that let me customize invoice details rather than locking me into a template. Every client relationship is a little different, and your invoicing should reflect that.

The Unsexy Math of Going Independent

A lot of developers I talk to dream about going fully freelance. And I get it — the freedom is appealing, the money can be better, and you don't have to sit through another all-hands meeting where someone shares a slide deck about "synergy."

But the math has to work, and most people don't run the numbers before making the leap.

Here's what I mean: if your full-time salary is $120,000, your freelance rate needs to cover not just that base number, but also health insurance (easily $500-800/month for a decent plan), self-employment tax (roughly 15.3% on top of your income tax), retirement contributions you're now making on your own, equipment, software licenses, and the fact that you'll have some months with fewer billable hours than others.

When you add all that up, your effective freelance rate probably needs to be 40-60% higher than your salaried hourly equivalent just to break even. That's not a guess — it's math you should actually run before making any big decisions.

The planning tools I mentioned earlier help here too. Running calculations on income changes as percentages, modeling out what different rate structures look like over a year, and keeping clean invoicing records so you know exactly what you've earned — all of this is the infrastructure of a sustainable freelance practice.

My Current Freelance Stack

For anyone curious, here's what I actually use day to day:

For communication, I use Slack or email depending on the client's preference. I don't fight people on their communication channel — meeting them where they are reduces friction.

For project tracking, I keep it simple: Notion for larger projects, a text file for smaller ones. I've tried Jira, Trello, Asana, and everything in between. For solo freelance work, they're all overkill.

For invoicing, I generate PDFs through an online invoice tool and send them via email with a polite note about payment terms. For financial tracking and rate comparisons, I use a combination of a spreadsheet and a percentage calculator for quick sanity checks.

For planning and sketching, pen and graph paper for the initial brain dump, then Figma if the project needs proper mockups.

The total cost of this stack? Basically zero for the freelance-specific stuff. Notion is free for personal use, the invoice and calculator tools are free, and graph paper costs me about three cents per sheet in printer ink.

Final Thoughts

If you're thinking about freelancing on the side, my advice is simple: don't let the administrative overhead scare you off, but don't ignore it either. Set up your invoicing workflow before you need it. Understand your numbers before you quote a project. And treat the non-coding parts of the work as seriously as the coding parts.

The developers who succeed at freelancing aren't necessarily the best coders — they're the ones who run their side hustle like a business from day one. That means tracking your income, communicating professionally, and knowing your worth in concrete numerical terms, not vague feelings.

Start small. Take one project. Invoice it properly. Track what you earned. Then decide if you want to do it again.

The tools are there. The work is there. The only question is whether you'll treat it seriously enough to make it work.

How Developers Can Take Control of Their Personal Finances with the Right Online Tools

Vago Neue J — Fri, 10 Apr 2026 06:48:14 +0000

Let me be honest with you — I spent way too long pretending that "I'll figure out the money stuff later" was a valid life strategy.

I was in my late twenties, three years into my first real developer job, making a decent salary, and still somehow living paycheck to paycheck. Not because I was broke, but because I had no idea where my money was actually going or what I should be doing with it. My employer had a 401k. I was contributing the minimum. I vaguely knew there was something called a Roth IRA but had never bothered to understand it. And every time I thought about buying a car, I just looked at the monthly payment number and thought "yeah that seems fine."

Spoiler: it was not fine.

The Developer Tax on Financial Literacy

Here's the thing nobody tells you when you land your first dev job: high income does not equal financial intelligence. If anything, there's a weird trap that a lot of us fall into — we're good at solving complex problems at work, so we assume we can "figure out" personal finance whenever we decide to care about it. It's always on the backlog. Always labeled "someday."

Meanwhile, compound interest doesn't wait for your sprint planning.

I'm not writing this to lecture anyone. I genuinely just wish someone had sat me down earlier and said: "Hey, there are tools that make this less painful. Use them." So that's what I'm doing here.

Stop Guessing at Car Payments

This one bit me hard. I was shopping for a used car and doing the classic mistake of anchoring entirely to the monthly payment number. "Can I afford $400/month?" Cool question, but that's not how car buying actually works. The monthly payment is a function of the loan amount, the interest rate, and the loan term — and dealers know exactly how to make those three variables dance in ways that cost you thousands more than you expected.

Before I went to a single dealership for my current car, I spent about twenty minutes with the Car Payment Calculator to actually understand what I was looking at. You plug in the car price, your down payment, interest rate, and loan term, and it tells you exactly what your monthly payment will be — and critically, what you'll pay in total interest over the life of the loan.

That total interest number is the one dealers don't want you thinking about. On a five-year loan for a $28,000 car at 7% interest, you're paying something like $5,200 in interest alone. When I ran those numbers before my test drives, I went in with completely different negotiation energy. I knew what a good deal looked like in terms I could actually defend.

If you're even thinking about buying a car, do yourself a favor and model out a few different scenarios before you step foot in a showroom.

Understanding Percentage Changes (Actually Useful, I Promise)

This one sounds boring but I use it constantly in ways I didn't expect.

Percentage increases and decreases show up everywhere once you start paying attention to money: your salary negotiation ("this offer is 12% above my current comp"), your investment returns ("my portfolio is up 23% since last year"), inflation adjustments, subscription price hikes. And most people, including me for a long time, have a surprisingly shaky intuitive grasp of what these numbers actually mean in practice.

For example: if something costs $80 and goes up to $95, what's the percentage increase? Feels like it should be easy, but a lot of people get it wrong because they anchor to the wrong number in the calculation. The Percentage Increase Calculator handles all the directions — increase, decrease, percentage difference — and shows the formula so you actually understand what happened, not just what the number is.

I started using this when I was tracking my freelance rates year over year and when comparing job offers. It sounds like overkill until you're sitting in a negotiation and need to quickly sanity-check whether the number being quoted to you is actually a meaningful improvement or just sounds like one.

The Roth IRA Thing — Please Read This Section

Okay. If you take nothing else from this post, take this.

If you're a developer in your 20s or early 30s, and you don't have a Roth IRA, you are leaving a genuinely significant amount of money on the table. The tax treatment of a Roth IRA — contributions made post-tax, but all growth and qualified withdrawals are tax-free — is one of the most powerful wealth-building tools available to people in the US, and it's particularly valuable early in your career when you're in a lower tax bracket than you likely will be in the future.

I didn't open mine until I was 29, and I still regret not doing it at 22. Time in the market is the whole game with Roth accounts.

What helped me actually understand the numbers was the Roth IRA Calculator. You put in your current age, how much you plan to contribute each year, expected return rate, and it shows you what your account could look like at retirement. The difference between starting at 25 versus starting at 35 is often hundreds of thousands of dollars, not just "a bit less." Seeing those projections spelled out made it real for me in a way that abstract advice never did.

A few practical notes:

The annual contribution limit for 2024 is $7,000 (or $8,000 if you're 50+)
There are income limits — check current IRS guidelines if your income is on the higher end
You can open one through Fidelity, Vanguard, Schwab, or a number of other brokerages with no fees

The earlier you start, the less you actually have to contribute overall because the compounding does more of the heavy lifting. That's the whole point.

Building Better Financial Habits as a Developer

I think the underlying issue for a lot of developers is that we're used to thinking about problems with high precision — bugs have root causes, systems have measurable behavior, code has deterministic outputs. Personal finance feels messier and more subjective, so we avoid it.

But the tools have gotten genuinely good. You don't need to be an accountant or have an MBA. You need to do a few hours of deliberate reading and use some honest calculators, and you'll have a better handle on your financial picture than the vast majority of people around you.

My actual workflow now:

Quarterly check-ins on my investment accounts (I use a simple spreadsheet to track net worth over time)
Before any significant purchase, I model it out — car payments, loan scenarios, the whole thing
I maxed out my Roth IRA contribution for this year back in February
I track my salary progression as a percentage increase from year to year, which keeps negotiations grounded in real numbers

None of this took a finance degree. It took about a weekend of deliberate effort and the right bookmarks.

The Real Cost of Waiting

Here's a thought experiment: if you're 25 and you invest $500/month in a Roth IRA earning an average of 7% annually, by the time you're 65 you'd have roughly $1.2 million — and because it's a Roth, you'd owe zero federal income tax on any of that when you withdraw it.

Wait ten years to start and contribute the same amount? You'd end up with about $567,000. Same monthly investment, same return, just starting ten years later. That's more than $600,000 in difference.

I'm not trying to make anyone feel bad. I'm just saying: the math is the math, and it doesn't care about your intentions.

The tools exist, they're free, and they're not complicated. Take an afternoon, model out your actual situation, and make one concrete decision. That's all it takes to start.

If you've been putting off any of this, I hope this gives you a nudge. And if you've already got your financial house in order, feel free to share what actually moved the needle for you — I'm always looking for better approaches.