I built a free Parking Cost Calculator for My Curb Spot. You pick a city, enter how long you’ll park, and it compares the cost of a street meter, a garage, and a surface lot. The cheapest option gets a “Cheapest” badge, and the meter gets a warning if you’d stay past its time limit.

Before writing this up, I ran every city and every duration through the same math the page uses. The meter wins every single time. That includes the cases where the page also tells you you’ll probably get a ticket.

How it works

It’s one client-side Next.js 16 page in TypeScript and Tailwind CSS, built with Claude Code. There are presets for 25 US cities. Each preset has an hourly rate for meters, garages, and surface lots, plus a typical meter time limit: 2 hours in 15 cities, 4 hours in the other 10. You can also type your own rates or switch any of the three options off.

The cost is the hourly rate times the hours you entered. The lowest total gets the badge, and a callout says how much you’d save compared with the most expensive option. The commit also added an Open Graph image, FAQ, HowTo, and breadcrumb structured data, and a card on the tools page.

The meter always wins

In all 25 presets, the meter rate is lower than the lot rate, and the lot rate is lower than the garage rate. The cost is a straight multiplication, so the order never changes with time. Park for 15 minutes or 24 hours and the result is the same: meter first, lot second, garage last.

I checked every preset at every quarter hour the form accepts, from 15 minutes to 24 hours 45 minutes. That’s 2,475 combinations. The meter gets the “Cheapest” badge in all 2,475. In 2,195 of them, the stay is longer than the meter’s time limit, so the same card also shows “Exceeds typical 2hr meter limit — risk of $25-$79 overtime ticket!”

Here’s one I ran on the live page. New York City, 8 hours. Meter: $28.00, with the Cheapest badge and the ticket warning. Surface lot: $64.00. Garage: $96.00. Below that: “You could save up to $68.00.”

That $28 isn’t a price you can pay. A 2-hour meter won’t take 8 hours of money. Even if you could feed it all day and got only one ticket, the page’s own $25 to $79 range puts the real total at $53 to $107, against $64 for the lot. The page’s FAQ gives better advice than the calculator does: “For longer durations, surface lots often offer the best value since you avoid overtime meter risks.” The calculator can’t ever show that.

Garages never hit a daily maximum

The FAQ also says most garages charge hourly with a daily maximum. The calculator doesn’t model one. A full day in a New York garage comes out at $288, which is 24 hours at $12. Long stays are exactly when people look up parking costs, and that’s where the numbers drift furthest from what a garage would really charge.

Why I didn’t catch it

I tested it the way most people would use it the first time: pick a city, park for an hour or two, look at the result. At those durations the meter really is the cheapest choice, there’s no warning, and everything looks right. The problem only shows up once you go past the meter limit. A one-line loop over the presets would have shown that the winner never changes.

I also added the warning as a label on the card instead of a cost in the math. That made the page look careful while the result ignored the risk it was describing.

What I learned

• If the inputs are a small, fixed set, run all of them. Here, one loop showed that the answer never changes.
• A warning shouldn’t sit next to a recommendation that ignores it. Either put the risk into the number, or stop recommending that option.
• Check the calculator against its own FAQ. Mine says the opposite of what the tool shows for long stays.
• Simple per-hour math can be fine for short stays. It needs caps and limits before it’s right for long ones.

What I’m fixing

First, the meter. Once the stay is longer than the meter’s limit, the meter card will say it can’t cover that stay instead of showing a price, and it won’t be eligible for the Cheapest badge. Then garages and lots get a daily maximum per city, so long stays come out at a realistic number.

I’ll also label the city rates as typical estimates, since they’re fixed numbers in the code rather than live prices. And I’ll add a test that runs every city and duration and checks that the cheapest option changes as the stay gets longer. The browser tab title is on the list too. It ends in “| My Curb Spot | My Curb Spot” because the page sets the brand and the site layout adds it again, and 25 tool pages do that.

The city presets, the toggles, and the overtime warning are a decent start. The part that picks a winner has to respect the rules it already knows about.

I built a free App Monetization Strategy Picker for Pitch An App. You answer seven questions about your app: what kind of app it is, how big the audience is, who it’s for, what value it delivers, how often people use it, whether they’ll pay, and how crowded the market is. It recommends one of five models (freemium, ads, subscriptions, one-time purchase, or hybrid) with pros, cons, a pricing cue, and two runner-up options.

Before writing this up, I ran every possible set of answers through the scoring code. There are 30,720 of them. The recommendations mostly make sense. The number shown next to them doesn’t.

How it works

It’s one client-side Next.js page in TypeScript and Tailwind CSS, built with Codex CLI and GPT-5.4. Each answer option adds points to some of the five models. For example, “B2B or professional workflow” adds 4 points to subscriptions, 2 to freemium, and 1 to hybrid. After the last question, the page adds up the points, sorts the models, and shows the winner with a “Match score” percentage and a “Strong fit” or “Balanced fit” label. The commit also added SEO metadata, a generated Open Graph image, and a card on the tools page.

The match score is 54% for 90% of answers

The match score takes the winner’s share of all points as a percentage, adds twice the gap between first and second place, and clamps the result between 54 and 93.

The problem is the share. Most answer options give points to two to four models at once, so the winner usually gets between 26% and 40% of the total. The median is 31%. In one case I tested, hybrid won with 13 of 50 points. That’s 26%, plus 2 for its one-point lead, so 28. The clamp raises it to 54.

Across all 30,720 answer combinations, 27,749 show exactly 54%. Only 9 reach the 93% ceiling. I checked both ends on the live page. A B2B team tool that people use several times a day, where buyers already pay for alternatives, gets Subscriptions with 26 points against 7 for the runner-up, and a 93% match. The hybrid case shows 54%. So does almost everything in between.

A number that almost never changes tells the user nothing. Worse, 54% reads like a weak match even when the winner is clear. The “Strong fit” label works better, because it only looks at the gap: four points or more.

Ties go to freemium

In 11% of combinations, two or more models tie for first place. The page sorts scores with JavaScript’s sort, which keeps tied items in their original order: freemium, ads, subscriptions, one-time, hybrid. So freemium wins every tie it’s part of, and the result never mentions the tie.

In one combination I tried on the live page, freemium, subscriptions, and hybrid all scored 11 points. The headline said Freemium, 54% match. That person had said their users prefer a simple upfront purchase.

Subscriptions wins half the time

Subscriptions is the top pick in 51% of all combinations. Freemium gets 27%. Ads, one-time purchase, and hybrid get about 7% each. The weights explain it: subscriptions has 55 points spread across the options, more than any other model, while ads and one-time purchase each appear in only 11 of the 31 options.

Some of that lean is fair, since a lot of software does fit subscriptions. But the weights were set one option at a time, and nobody looked at the distribution they produce. If a quiz with five answers picks one of them half the time, that should be a decision, not an accident.

Why I didn’t catch it

The quiz looks fine if you try it with answers that point clearly at one model. Those give sensible winners and high match scores, because clear answers create big gaps. The 54% floor shows up when the answers are mixed, which is what most real apps look like. Checking every combination took a short Python script and about a second.

What I learned

• If a scoring tool has a small set of possible inputs, run all of them. The distribution tells you more than any number of hand-picked tests.
• A clamp can hide a broken formula. If the floor is the most common result, the formula is wrong.
• Decide how ties work, and show them. Sort order is not a product decision.
• Check how often each answer wins. If one wins half the time, make sure you meant that.

What I’m fixing

First, the match score. I’ll either base it on the gap between first and second place, which is what actually measures confidence, or drop the percentage and keep the Strong fit and Balanced fit labels. Then ties: when models tie, the result should say so and show them side by side.

Then I’ll rebalance the weights and add a test that runs every combination and fails if one model wins too often or if most answers land on the same match score. I’ll also fix the browser tab title, which ends in “| Pitch An App | Pitch An App” because the page title includes the brand and the site layout adds it again. 21 tool pages have that.

The questions and the write-ups for each model are solid. The part that turns answers into a number needs work.

I built a free Fake Chat Generator for ChatSpark. You pick a style (iMessage, WhatsApp, Slack, Discord, or a plain generic chat), add participants with names and avatar colors, type messages with timestamps, and download the conversation as a PNG. It’s meant for mockups, slides, and app screenshots.

Before writing this up, I opened the live page in a fresh browser and went through it like a first-time user. The editor and the preview work. The one button that matters doesn’t.

How it works

It’s one client-side Next.js page in TypeScript and Tailwind CSS, with no backend. The state is three lists: participants, messages, and the selected style. Each style is a small React component that renders the same messages differently: blue and gray bubbles for iMessage, a beige background with names for WhatsApp, avatar rows for Slack, a dark theme for Discord. You can reorder or delete messages, and the preview updates as you type.

The export uses html2canvas. It walks the preview’s DOM, redraws it onto a canvas at 2x scale, and triggers a download. The commit also added SEO metadata, a generated Open Graph image, FAQ, HowTo, and breadcrumb structured data, and a link from the tools index.

The Download PNG button fails silently

I added two messages and clicked Download PNG in each of the five styles. No file downloaded in any of them. The button flashed “Exporting…” and went back to “Download PNG”. Nothing on the page said anything went wrong.

The console did: “Attempting to parse an unsupported color function ‘oklch’.” ChatSpark uses Tailwind CSS v4, and v4 defines its default palette in oklch. So a class like text-gray-400 on the timestamps gives the browser an oklch color. html2canvas 1.4.1, the last release, only understands older color formats like hex and rgb. When it reads the first oklch color, it throws, and the export stops.

The export code has a try/finally block with no catch. The finally resets the button, and the error goes nowhere the user can see. So the tool’s main promise, “Download the chat as a PNG screenshot”, which is step 5 of the page’s own how-to, fails without telling anyone.

Deleting “Me” sends messages to nobody

The sender dropdown starts on “Me”. If you delete the Me participant, the dropdown shows the next person, Alex. But the page’s state still points at the deleted participant. The remove function picks a fallback sender from the participant list as it was before the deletion, and that’s the person you just deleted.

So the next message you add is assigned to someone who no longer exists. The message list shows it as “Unknown”, and the preview hides it, because each preview skips messages whose sender it can’t find. You see the dropdown say Alex, you type a message, and it never shows up in the chat. There’s also no one marked as “Me” anymore, so every bubble sits on the left until you pick a new Me.

Why I didn’t catch it

The export depends on two libraries working together, and I didn’t test them together. html2canvas worked fine for years when Tailwind used hex and rgb colors. The page built, the preview looked right, and the build passed. Nothing failed until a real click in a real browser.

What I learned

• Click the button the tool is named for, in production, before you call it shipped. A clean build doesn’t prove the main action works.
• A try/finally with no catch hides failures. If an export can fail, show the user a message.
• Check that your rendering libraries understand your CSS. Tailwind v4’s move to oklch broke html2canvas, and any tool that parses computed styles itself can break the same way.
• When you delete something, compute the fallback from the list after the delete, not before.

What I’m fixing

First, the export. I’ll switch to a capture library that understands modern color functions, or give the preview explicit hex colors so it doesn’t depend on Tailwind’s palette. Then I’ll add a catch that tells the user when an export fails, and a check that clicks Download PNG in every style and confirms a file comes back.

Then the sender bug: pick the fallback sender from the updated list, and keep one participant marked as Me. I’ll also make timestamps step forward for each new message, since right now every message gets the same time unless you change it by hand.

The editor and the five styles are the bulk of the work, and they’re done. The download is what people came for, and it has to work.

I built a free Startup Runway Calculator for Idea Score. It takes cash on hand, monthly revenue, monthly expenses, revenue growth, expense drift, and planned hires, then draws a cash projection.

The useful part is making assumptions visible. A flat burn-rate calculation can’t show when a new salary starts or how recurring growth changes the curve. This tool can. But while checking the implementation for this write-up, I found a label that overstates what the model knows.

What shipped

The calculator is a client-side Next.js page written in TypeScript with Tailwind CSS. React state holds the inputs and hiring plan. A memoized forecast produces the cash points, and an SVG renders the line and shaded area. There is no charting dependency in this page.

Each planned hire has a title, monthly cost, and start month. The forecast includes that cost from the selected month onward. You can change the assumptions and see the projection update without submitting a form.

The shipping commit also added a tools-index link, metadata, a landscape Open Graph image, and FAQ, HowTo, and breadcrumb structured data. Those are the supporting pieces around the calculator; they aren’t evidence of search traffic or demand.

Two calculations, two different questions

The simple-runway card divides current cash by current monthly net burn. The chart simulates up to 36 months with changing revenue, expenses, and hiring costs. Keeping both views makes sense: the first explains the baseline, while the second shows the effect of the assumptions. A planned hire changes the curve; the simple baseline still uses current expenses.

But the formatter for that baseline contains a shortcut: if the result is non-finite or greater than 999 months, it displays “Profitable.” That combines a very long but finite runway with the case where current revenue covers expenses.

The example that exposed it

I checked the live tool with $10,000,000 in cash, $10,000 in monthly revenue, $20,000 in monthly expenses, zero revenue growth, zero expense drift, and no hires.

The baseline calculation is 1,000 months: $10,000,000 divided by $10,000 of monthly net burn. The live page displays “Profitable” in the simple-runway card. Right beside it, the net-burn card still shows a $10K monthly cash loss.

This is deliberately an edge case, not a typical startup budget. It makes the mistake easy to see: cash reserves change how long the money lasts, but don’t change whether monthly revenue covers monthly expenses.

What I learned

A display limit needs its own label. “More than 999 months” would preserve the meaning of this finite answer. “Profitable” changes the meaning entirely. A formatter that looks like presentation code is making a claim about the underlying numbers.

The forecast horizon needs the same care. The chart describes a bounded 36-month scenario under supplied assumptions, not an unlimited prediction. A clear label should preserve those limits rather than turn a convenient internal value into certainty.

Checking the number next to the label was more revealing than checking the chart alone. The interface simultaneously showed “Profitable” and a monthly cash loss. That is a useful edge-case check for any calculator with a friendly summary label.

What comes next

The next change I’d prioritize is separating a large finite runway from a non-burning baseline in the formatter. I’d keep the simple calculation and the growth-and-hiring forecast visibly distinct, and remove the unused projected-runway calculation if it has no role in the interface.

That correction isn’t shipped in this post. The calculator is live, and the misleading label is still there. This build was a reminder to review the words beside a chart as carefully as the formula behind it.

I built a free Age-Appropriate Activities Finder for Sitter Rank. It’s for babysitters and parents who need an idea right now: pick the child’s age group, and you get indoor, outdoor, educational, and creative activities, each with a difficulty level and a materials list.

It works, and the content is useful. But while writing this up, I read the page the way a sitter would, and the words on it promise more than the tool does.

How it works

It’s one client-side Next.js page in TypeScript and Tailwind, with no backend. The data is a hard-coded array of 60 activities. Each one has a name, a description, a difficulty (Easy, Moderate, or Advanced), a materials list, an age group, and a category. There are six age groups, from Infant (0–1 years) to Teen (12+ years), and four categories.

The only state on the page is the selected age group. It defaults to Preschool. Click a different age card and the list below re-renders, grouped under four headings: Indoor, Outdoor, Educational, and Creative. The commit also added SEO metadata, a generated Open Graph image, FAQ, HowTo, and breadcrumb structured data, and links to the other Sitter Rank tools.

Category is a heading, not a filter

The intro text says: “Filter by age group and category.” Step 2 of the how-to says “Browse activities by category.” But there is only one control on the page: the six age buttons. Category isn’t something you choose. It’s a heading the list is sorted under. If it’s raining and you only want indoor ideas, you scroll past the outdoor ones. You can’t filter by difficulty or by what’s in the house either.

So it’s a finder with one filter. The page copy describes two.

“60+” means exactly 60

The intro says “Browse 60+ activities.” The number comes from the array length, and the plus sign is hard-coded after it. The array holds exactly 10 activities for each of the six age groups, so the live page says “60+” about a list of 60. Because every group has 10, every age card shows the same “10 activities” badge. That badge looks like information, but it can never change.

The age ranges overlap

The ranges are 0–1, 1–3, 3–5, 5–8, 8–12, and 12+. Each boundary age appears in two groups. A three-year-old is both a Toddler and a Preschooler, and an eight-year-old is both School Age and Tween. The first step tells you to “select the age range that matches the child,” and for those ages two buttons match. Meanwhile, a chip in the header says “Ages 0–17,” while the last card just says “12+ years.”

Difficulty does less than it looks

Each card has a colored difficulty badge. All 20 Infant and Toddler activities are Easy, and every Advanced activity is in the Tween or Teen group. For the youngest kids, the badge says the same thing on every card, so it gives a sitter nothing to choose with.

What I learned

• Read your page copy against your controls. If the text says “filter by category,” there should be a category filter.
• Don’t hard-code a “+” next to a count. Show the real number, or leave the number out.
• Age ranges need one owner per age. Use ranges that don’t share endpoints, like “3–4” and “5–7,” or let people enter an age.
• A badge that’s the same on every card is decoration. Either make the data vary or drop the badge.

What I’m fixing

Next, I’m adding category and difficulty toggles above the list, plus an “uses things you already have” filter based on the materials, and putting the selection in the URL so a parent can send a sitter a link to “indoor ideas for a toddler.” I’ll make the age ranges non-overlapping, show the real count, and make the header chip match the last group. I also want a mixed-ages view, because the page’s own FAQ tells sitters with two kids to use the younger child’s group, and right now you can only look at one group at a time.

The activity ideas are the hard part, and they’re done. The finder around them needs to do what its own copy says.

I built a free CSS Flexbox Playground for Zap Code. You pick a preset (Centered, Sidebar, Holy grail, Navbar, or Card grid), change the container and item properties, watch the layout update, and copy the generated CSS into your own project.

The copy button is the whole point. While writing this up, I pasted that CSS into a plain page next to the preview and compared the two. They don’t match, because the preview gets help from styles that never reach the copied CSS.

How it works

It’s one client-side Next.js page in TypeScript and Tailwind, with no backend. The container controls cover display, flex-direction, justify-content, align-items, align-content, flex-wrap, and gap. Each item has flex-grow, flex-shrink, flex-basis, align-self, and order. The page keeps that state in React and rebuilds two things on every change: inline styles for the preview, and a CSS string with a .flex-container rule and one .flex-item:nth-child() rule per item.

Those two outputs come from two different functions. That’s where the problems start.

The preview has a height your page doesn’t

The preview function adds sizing that the CSS function leaves out. The container gets a 360px minimum height. Each item gets its own minimum height from the preset, between 72px and 240px, plus a 96px minimum width. None of these appear in the generated CSS.

The Centered preset says it centers “a single element both horizontally and vertically in one move.” In the preview, the box sits 96px from the top of a 360px container, so it looks centered. I pasted the generated CSS into a container of the same width, with a single box inside. That container is 56px tall, exactly as tall as the box. Horizontal centering still works. Vertical centering does nothing, because there’s no extra height to center in. The 360px that made it work belongs to the preview, not to your page.

The Sidebar preset has the same problem. In the preview, both columns stretch to 322px. With the copied CSS, they’re 56px tall. align-items: stretch is doing its job, but it’s stretching to the height of the content.

The preview is too narrow for its own default

At desktop width, the preview sits in a 440px side column, which leaves about 306px for the flex items. The default preset is Holy grail: a header, then Nav, Main, and Aside in one row, then a footer. Nav is 170px and Aside is 150px. Add the gaps and that’s already more than 306px before Main gets anything.

So in the live preview, Aside wraps onto its own row under Nav and Main. The first layout you see when the page loads is not the three-column layout the preset is named after. The Card grid preset has the same issue. Each card has a 180px basis, so two cards need more room than the preview has, and all six stack in a single column.

The CSS for both presets is fine. At a normal page width, the holy grail lines up and the cards form a grid. The preview just never shows it.

You can’t type a negative order

The order field accepts values from -10 to 10, and a negative order is how you pull an item to the front. But each field clamps its value on every keystroke. When you type the minus sign, the number input reports an empty value, which becomes 0. Then you type 2. On the live page, typing -2 leaves 02 in the field and order: 2 in the CSS. The item moves the other way.

What I learned

• If a tool shows a preview and also exports code, build both from the same source. Two functions that are supposed to agree will drift apart.
• Any style you add to make a preview look good is one the user doesn’t get. Either export it, or label it on the preview so people know what’s there.
• Test presets at the size the preview actually renders, not the size you imagined while writing them.
• Don’t clamp a number field while the user is still typing. Clamp on blur, or keep the raw text until it parses.

What I’m fixing

Next, the preview will render the generated CSS itself, inside a frame. Any helper sizing, like a container height, will be part of the exported CSS, with a comment saying what it’s for. The Centered preset will export a height so vertical centering works when you paste it. The preview will get a width toggle so wide presets like Holy grail and Card grid can show their real layout. The number fields will keep what you type and clamp only when you leave the field.

A playground exists to show people what their CSS will do. Mine showed what my CSS plus a few hidden extras would do.

I built a free Markup Calculator for Vibe Mart. You enter any two of cost, selling price, and markup percentage, and it works out the third, plus profit and margin. Under the results there’s a small “Markup vs. margin” chart, a reference table that runs from 10% to 200% markup, and an FAQ.

The math is right. While writing this up, I tested the live page, and the parts around the math don’t hold up as well. The chart contradicts the sentence printed under it, and the three modes can give you three different answers for the same product.

How it works

It’s one client-side Next.js page in TypeScript and Tailwind, with no backend. There are three modes: Cost + Markup %, Cost + Selling Price, and Selling Price + Markup %. Each mode shows the two inputs it needs and hides the third. The page keeps all three values in state and recalculates on every keystroke. Markup is profit divided by cost. Margin is profit divided by selling price. The page also ships FAQ, HowTo, and breadcrumb structured data, and an Open Graph image rendered at the edge.

The chart says the opposite of its caption

Open the page and the defaults are a $50 cost with a 60% markup, so the selling price is $80. Markup is 60% and margin is 37.5%. Below that are two bars, and under them a caption: “Markup is always higher than margin for the same transaction.”

On the live page, the markup bar is 30% wide and the margin bar is 37.5% wide. The shorter bar is the bigger number.

That’s because the two bars use different scales. The margin bar maps 0 to 100%. The markup bar maps 0 to 200%, so I divided its width by two to make room for big markups. At 100% markup both bars sit at exactly half. Below that, which covers most of the everyday markups people look up, the margin bar is drawn longer than the markup bar. Above 200%, the markup bar is full and stops growing. At 300% markup it’s full, next to a 75% margin bar.

The bars carry no scale labels, so nothing tells you they’re measured differently. It’s the one picture on the page meant to explain markup versus margin, and at the defaults it shows the reverse.

Switching modes changes the product

The page keeps a cost, a markup, and a selling price in state the whole time, even when a mode hides one of them. Switching modes doesn’t recalculate the hidden value. It shows whatever was typed last.

Here’s the live page. In Cost + Markup %, change the cost to $100. The selling price becomes $160 at a 60% markup. Now click Cost + Selling Price, which feels like the same question asked from another side. The selling price field shows $80, the old default, and the results say markup is -20%, profit is -$20, and margin is -25%. Click Selling Price + Markup % and the cost becomes $50.

So one product with a $100 cost shows a $60 profit, a $20 loss, and a $50 cost, depending on which button you clicked last. The page never says that a hidden field is stale.

Losses don’t show up in the chart

Both bars clamp at zero. A $50 cost sold for $25 gives a -50% markup and a -100% margin, and the chart shows two empty bars. The numbers are correct, but the chart is blank exactly when the result most needs your attention.

What I learned

• If two bars are meant to be compared, put them on the same scale, or label each one. I scaled each bar for its own range and lost the comparison the chart was there to make.
• Check a chart against its caption with real numbers. The default inputs were enough to show the problem.
• When a form has modes that hide fields, hidden values go stale. Either carry the last result into the new mode, or show which values you’re using.
• Clamping is fine for layout, but it shouldn’t hide the case where you’re losing money.

What I’m fixing

Next, I’m putting both bars on one shared scale with labeled ends, so the longer bar is always the bigger number. When you switch modes, the calculator will carry over the last computed values, so a $100 cost at 60% markup stays a $160 selling price in every mode. Losses will get their own red state and a short note, not empty bars.

The formulas were the easy part. The work was in making sure the chart, the caption, and the mode buttons all describe the same transaction.

I built a free Party Planning Checklist Generator for PartyHub Rental. You pick an event type (birthday, wedding, corporate, baby shower, graduation, holiday, anniversary, or reunion), enter a guest count and a total budget, and it gives you a checklist that runs from eight weeks out to the day after. You can view it by timeline or by category, tick tasks off as you go, watch a progress bar fill up, and print it.

While writing this up, I ran the checklist logic in a script and then tested what I found on the live page. The biggest problem is with the checkboxes, which are the main thing people use. If you change your plans after generating the list, your ticks move to tasks you never did.

How it works

It’s one client-side Next.js page in TypeScript, styled with Tailwind, with no backend. A single function builds the list. It starts with about 36 tasks every event gets, adds a few for the event type, and adds more when you have over 50 guests or a budget over $2,000. As each task is added, it gets an id from a counter: 1, 2, 3, and so on. The page saves your ticks as a set of those ids.

The page also rebuilds the list on every render from whatever is in the form right now, not from what was there when you clicked Generate. Those two shortcuts don’t work together.

Ticks stay on the number, not the task

Here’s what happens on the live page. Generate a birthday checklist for 30 guests: 38 tasks. Tick “Choose and book your venue,” “Send out invitations,” and “Book entertainment.” Then change the guest count to 51, because the guest list grew.

The list jumps to 42 tasks, because big events get an event coordinator, parking, security, and a staff briefing. “Hire an event coordinator for 50+ guests” goes into the eight-weeks-out section, ahead of the invitations, so every task after it moves down one number. Your ticks don’t move with them. Now the checked tasks are the venue, “Hire an event coordinator,” and “Send out invitations.” “Book entertainment” is unchecked, and the counter still says 3/42 completed.

Switch the event type to Wedding and it gets worse. The heading changes to “Your Wedding Reception Checklist,” and the ticks land on “Book officiant and wedding planner” and “Start dress/attire shopping.” You didn’t do either one. In my script, after the 30-to-51 change, 34 of the 38 original ids pointed to a different task.

Your ticks only clear when you click Generate again, and the page never tells you that you should.

The guest count field won’t let you delete it

The guest field won’t go below 1, and it enforces that on every keystroke. If you click after the 30 and press Backspace twice, the field shows 1. Type 60 and you get 160. While that happens, the list briefly says “Create your guest list (aim for your target of 1 guests),” and once it reaches 160 it adds the large-event tasks. That shifts your ticks again. The budget field does the same thing with a $100 minimum.

The FAQ promises more than the code does

One FAQ answer lists the things people most often forget: ice and coolers, trash bags, a first aid kit, phone chargers, extra seating, parking directions, a day-of timeline, and tip money for vendors. Then it says, “This checklist generator covers all of these.”

It doesn’t. I generated every list the tool can make, for all eight event types, small and large. None of them mention coolers, trash bags, phone chargers, or extra seating. Parking only shows up above 50 guests. Tipping is a day-after task, “Tip and review your vendors,” not “bring cash.”

The FAQ also says weddings may need three to six months. The checklist always starts at eight weeks, so “Book officiant and wedding planner” and “Start dress/attire shopping” are due eight weeks before a wedding. A wedding checklist shares 36 of its 42 tasks with a birthday checklist. An anniversary gets no tasks of its own at all. The budget only matters once it passes $2,000, so a 150-guest wedding with a $2,000 budget gets no photographer task.

What I learned

• Give list items ids that come from what the item is, not from where it sits in the list. A counter is fine until the list changes.
• If a list is generated from inputs, either keep it fixed until the user regenerates it, or carry their progress over by task. Silently changing it under their ticks is the worst option.
• Don’t enforce a minimum on every keystroke in number fields. Let people clear the field while typing and check the value when they leave it.
• Check marketing copy against the code. “Covers all of these” took one script to disprove.

What I’m fixing

Next, I’m going to give each task a stable key based on its wording, so ticks follow the task. The generated list will stay fixed until you click Generate again, with a note when the form no longer matches it. The guest and budget fields will only enforce their minimums when you leave the field. I’ll add coolers, trash bags, chargers, extra seating, and parking directions to the base list. Weddings will get a longer timeline that starts months out, and anniversaries will get a few tasks of their own.

It’s a small tool, but the checkboxes are what make a checklist useful. If your ticks can move on their own, the progress bar can’t be trusted.

I built a free Message Tone Analyzer for ChatSpark. Paste a draft and it shows tone signals, readability, possible friction, and three suggested rewrites. It is meant for the moment before sending a support reply or follow-up email, when a second look can catch wording that lands badly.

The implementation is deliberately small: a client-side Next.js page, TypeScript rules, and no model call for the analysis. That makes the scoring easy to inspect. It also makes the limits easy to reproduce.

What shipped

The checker scores eight categories: friendly, formal, casual, passive-aggressive, urgent, sarcastic, angry, and professional. Phrases, punctuation, and capitalization contribute signals. The results explain the wording behind the scores rather than showing only a label.

There is also a readability estimate, average sentence length, and a friction score. The rewrite section offers warmer, professional, and shorter versions, with copy buttons. Preset messages make it possible to try the tool without pasting a real conversation.

The release also includes page metadata, a landscape social image, and an entry in the tools index. Those are the less interesting pieces of building a tool, but a usable page still needs to be discoverable and shareable.

One preset tells the story

I tried the built-in passive-aggressive example on the live page: “Per my last email, I am still waiting on the file. Not sure why this has not been sent yet…”

The checker labeled it passive-aggressive and high friction. It showed readability at 99/100 and friction at 62/100. That is a useful distinction: a message can be easy to read and unpleasant to receive.

The explanations pointed to blame-heavy phrases, indirect criticism, and the ellipsis. Those are concrete things a writer can reconsider. The percentages are rule scores, though, not measured probabilities of how a particular recipient will feel.

Replacing phrases is not editing a sentence

The professional rewrite began: “Hello,” followed by “following up on my previous email, I am following up on the file.” It ended with “Thank you.”

The repeated phrase comes directly from two replacements: “per my last email” becomes “following up on my previous email,” while “still waiting” becomes “following up.” Each substitution looks reasonable in isolation. Together, they make an awkward sentence, and the body starts with a lowercase letter.

This is the boundary of the current approach. It can identify wording worth reviewing and soften specific phrases. It cannot reliably compose those edits into a polished message. Calling an output “Professional rewrite” does not make it ready to send.

Why keep the rules?

The tone-analysis and rewrite functions execute in the browser rather than sending the draft to a model API. They give immediate feedback and leave the matching rules available to inspect. For a quick writing aid, that is a useful starting point.

The tradeoff is context. For example, the rules include “great job” as a sarcasm signal. The same phrase can be sincere praise. A score should invite a second look, with the sender making the final judgment.

What comes next

My next priority would be testing complete rewritten messages, including the presets, rather than checking substitutions one at a time. Repeated phrases, sentence capitalization, and preserved meaning deserve attention before adding more tone categories.

For now, use the output as a draft to edit. You can try the tone analyzer here. The most useful part may be the pause it creates before you hit send.

I built a free Dog Name Generator for PetRoute. It’s a searchable list of dog names, each with a meaning, an origin, a few suggested breeds, and tags for gender, size, personality, and theme. You can filter on any of those, heart the names you like (they’re saved in your browser), and hit a Random button when you don’t know where to start.

While writing this up, I went through the name list with a script and then checked what I found on the live page. The Random button and the name count both had problems I hadn’t noticed when I shipped it.

How it works

It’s one client-side Next.js page in TypeScript, with no backend. The names live in a hard-coded array. Each filter is a simple equality check, and the search box matches your text anywhere in a name, its meaning, or its breed list. After filtering, the page removes repeated names, keeping the first one it finds, and shows 24 at a time with a “Show more” button. Favorites go into localStorage, so there’s no account.

That keeps the page fast and easy to change. The problems come from two shortcuts: Random reuses the search box, and the de-duplication runs after the filters.

Random picks a name, then searches for it

Random doesn’t show you the name it picked. It types that name into the search box. Search is a substring match across names, meanings, and breeds, so short names catch a lot of other dogs.

When Random lands on Iris, you get 27 results. “Iris” is inside “Irish,” and the list is full of Irish Setters and Irish Wolfhounds. Iris is the eighth card, after Murphy, Rusty, Molly, Finn, Forrest, Moss, and Fern. Sky does the same thing through “Husky”: 28 results, with Sky ninth. Sam matches every Samoyed and returns 11.

Most picks are fine. I clicked Random eight times on the live page and got exactly one result every time. But by my count, 33 of the 329 names return more than one card, and when that happens the name Random chose isn’t marked anywhere. You see a page of dogs and have to guess which one it meant.

351+ names, 329 on the page

The intro says “Browse 351+ dog names.” That number is the length of the array, and the array has duplicates: 20 names appear more than once, which adds 22 extra rows. With no filters, the page shows 24 names and “Show more (305 remaining),” which is 329. The code comment above the array says the goal was 500+, and I stopped well short of it.

The duplicates aren’t identical, either, and that leaks into the filters. Charlie is tagged male in one row and unisex in another, so he appears under both. Remi is a medium male in one row and a small female in another. Bark Twain is both male and female. Because de-duplication runs after the filters, a name’s tags depend on which filter you pick.

Smaller things

• The origin filter is mostly “English.” 224 of the 351 rows are tagged English. There’s no Greek option, so Athena, whose meaning is literally “Greek goddess of wisdom,” is filed under English. So are Zeus, Apollo, and Hera, and so are Anubis and Isis from Egyptian mythology. Only the Norse names got their own origin.
• The advice and the list pull in different directions. The tips say to pick names with one or two syllables, and the funny section suggests Droolius Caesar, Sir Barks-a-Lot, and Snickerdoodle. They’re fun, but the page doesn’t say they break its own advice.

What I learned

• Don’t reuse search to show a selection. Search finds everything that contains your text, while a random pick means one specific record. Treating them as the same thing worked for most names and failed on the short ones.
• Count what users see, not what’s in the array. The headline number came straight from the data, duplicates included. Counting the de-duplicated list, the same one the page renders, would have caught it.
• Put a uniqueness check on hand-built data. I added names in batches to reach a target, and the batches overlapped. A small test that fails on a repeated name would have caught all 20 of them, along with their conflicting tags.

What’s next

First, make Random show the picked name on its own instead of typing it into search, and highlight it. Then merge the duplicate rows into one entry each with consistent tags, add a test that rejects repeated names, and have the intro count the names the page actually shows. After that I’ll add a Greek origin for the mythology names and mark the long joke names as just for fun.

If you’re naming a new dog, try the generator and filter by breed or personality. If Random gives you a page full of Irish Setters, look for the name in the search box.