none of them honestly. i'd rather keep shipping for five clients than bet a year on one idea i didn't pick myself.

set a rate limit of 100 requests a minute per IP. felt reasonable 9:02 the next morning, one customer's entire office was locked out 300 people, one office, one public IP. their NAT made them look like a single very busy user the limiter did exactly what I told it to do moved the main limit to the API key, kept a much looser per IP ceiling behind it, and their morning went back to normal an IP address is a building, not a person

pushed a tiny caching tweak at 4pm to make the dashboard feel faster at 4:07 a user emailed asking why the page said "welcome back, Priya" his name is Tom the API response went out with Cache-Control: public, max-age=600. the CDN read public and kept one copy of that page for everybody so for 10 minutes, whoever loaded first was the account everyone else saw switched it to private, purged the cache, then wrote a lot of apology emails if a response knows who you are, it should say private

my import script kept failing with "missing column: email" the CSV very clearly had a column called email. first one, top left spent 40 minutes on it before I printed the header's length 6 email has 5 letters Excel had saved the file as UTF-8 with a BOM, an invisible character glued to the front of the first header. so the column was really " email" stripped it on read and the import finished in 4 seconds the bug you can't see is usually sitting in byte one

went from 1 server to 3 the night before a launch next morning 1,200 users got the daily digest email three times support inbox: "why are you spamming me" the cron lived inside the app process. one box meant one 7am run. three boxes meant three 7am runs, all at the same second fixed it in two places. the schedule moved to one worker, and the job now grabs a lock row in the database first, so a second copy just exits scaling out copies everything, including the jobs you thought ran once

sent the ops team a CSV of 3,000 orders to tidy up they opened it in Excel, fixed a few rows, saved, sent it back the import failed on about 2,700 of them our order IDs are 16 digits. Excel keeps 15 significant digits, so the last one quietly came back as a 0 the phone numbers had lost their leading zero too nothing looked broken unless you held it next to the original now every ID goes out with letters in front, like ORD-4417. Excel leaves text alone if a number is really an ID, don't let it look like a number

exported all our orders to CSV last night, 500 rows a page with OFFSET the file had 12,037 rows. the table had 12,037 rows. done, I thought then finance found the same order on two lines 37 duplicates. and the 37 orders placed during the export weren't in the file at all the query sorted newest first. each new order pushed everything down one row, so the next page started on a row I'd already written switched to WHERE id < last_seen_id. no more drift matching row counts don't mean matching rows

a user in Sydney wrote in saying we billed them a day early they signed up at 9am on November 1st. their receipt said October 31st both were right 9am in Sydney that day was 10pm on the 31st in UTC, and the server stored and printed everything in UTC the charge went out on time. the date on the receipt was just 11 hours behind their life fixed it in 2 lines. keep the instant in UTC, show it in the user's timezone a date without a timezone is a guess with nice formatting

split a $100 plan into 3 monthly payments 33.33, 33.33, 33.33 looked fine on every invoice. the accountant found it 4 months later each customer paid 99.99. one cent short, every time. across 1,800 customers that's $18 we never billed no single invoice looked wrong, which is why it lasted 4 months the fix was tiny. round the first two payments, then make the last one whatever is left. 33.33, 33.33, 33.34 splitting money is easy. splitting it so it adds back up is the actual work

a user said the signup form rejected their email on the second try first click: valid. second click: invalid. third click: valid again same email, same code, alternating answers the validator was one shared regex with the g flag on it with g set, test() remembers where the last match ended in lastIndex and starts the next search from there. so the second call began past the end of the string and found nothing took the g off and it worked on all 3 clicks a regex that keeps state between calls is a bug waiting for the second click

a migration script printed "done" 0.3 seconds after I ran it it was supposed to update 4,000 user rows the loop was users.forEach(async (u) => await save(u)) forEach ignores whatever your callback returns, promises included. it fired off 4,000 saves, moved straight to the next line and closed the database connection a few seconds later the first "connection closed" error took the whole process down. a handful of rows made it, the rest never got touched a plain for...of loop fixed it forEach is fine right up until the word async shows up inside it

added a meeting to Monday and it showed up on all 7 days of the week the grid was built with Array(7).fill([]) looked fine. 7 empty arrays, one per day except fill doesn't make 7 arrays. it makes one array and puts the same reference in all 7 slots, so pushing to Monday pushed to Sunday too took 40 minutes to find because my tests only ever added one meeting and checked one day Array.from({ length: 7 }, () => []) fixed it fill is great for zeros and terrible for anything you plan to change later

a user wrote in 4 times saying they couldn't remove their phone number clear the box, hit save, green "saved" toast. reload. the number was back the form set phone to undefined when the field was empty. JSON.stringify quietly drops any key whose value is undefined, so the PATCH body never mentioned phone at all the server saw nothing to change and kept the old one swapped undefined for null and it worked first try null means "make this empty". undefined means "I didn't say anything". JSON only has a word for one of them

a user couldn't save their display name. "too long", the form said the limit was 20 characters. they had typed 12 9 letters and 3 flag emojis in JavaScript a flag is two regional indicator symbols, and each one takes 2 UTF-16 units. so a single flag has a length of 4 9 + 12 = 21 the fix was counting with Intl.Segmenter, which counts what a person actually sees on the screen "how long is this string" has at least three right answers, and the default one is the wrong one for humans

my sync script said a Notion database had exactly 100 rows it had 1,342 no error, no warning. status 200 and a tidy list of 100 pages, so I believed it for 3 weeks then someone asked why most of their entries never showed up anywhere the API returns 100 at a time with a has_more flag and a next_cursor for the page after. I never checked has_more the fix was a 6 line while loop now any count that lands on exactly 100 makes me nervous before it makes me happy

a customer couldn't pay for a $19.99 order. the $9.99 and $29.99 ones went through fine Stripe kept rejecting it with "invalid integer" I was sending the amount as price * 100 19.99 * 100 in JavaScript is 1998.9999999999998 floats can't store most decimals exactly, so a few prices land a hair under the cent. 9.99 and 29.99 happen to round clean, which made it look random Math.round fixed it in one line storing money as integer cents from day one would have meant nothing to fix

set a Christmas sale to start with new Date(2026, 12, 25) tested it by faking the clock to December 25th. no banner faked it to January 25th. banner JavaScript months start at 0. January is 0, December is 11. so 12 isn't an error, it just rolls over into the next year no warning, no exception. a perfectly valid date, one month late the fix was typing 11 and feeling a bit stupid the calendar has 12 months. JavaScript has 0 through 11 and a lot of confidence

a user wrote in asking why they had two accounts with the same email they didn't, technically. one was all lowercase. the other started with a capital P because their phone capitalised it at signup my unique constraint on email did its job. Postgres compares text exactly, so P and p are two different people 38 users had done the same thing over 2 years the fix was a unique index on lower(email) and a very boring merge script the database was right all along. humans just never type the same thing twice

my signups chart showed a spike at 1am this morning. about double a normal hour no launch, no tweet, nothing. I went looking for a bot it was the clocks. the UK went back an hour at 2am, so 1:00 to 2:00 happened twice the chart grouped by local hour, so two hours of signups landed in one bar the fix was boring. bucket everything in UTC and convert only the labels nothing was wrong with the data. the day just had 25 hours in it

wrote a retry wrapper for a flaky API. 3 attempts, exponential backoff, the works it never retried once the API returned 503s for most of an afternoon and my logs said success fetch only rejects when the network itself fails. a 500 or a 503 is a perfectly good response as far as fetch is concerned my try/catch was waiting for an error that was never coming one line fixed it: if (!res.ok) throw new Error(res.status) the retry logic was fine. nobody ever told it something went wrong

a leaderboard I wrote put someone with 9 points in first place, ahead of someone with 100 the code was one line. scores.sort().reverse() JavaScript's default sort compares everything as strings so [9, 10, 100] sorts to [10, 100, 9]. "9" lands after "1" the same way "z" lands after "a" every test passed because every test score had two digits the fix was scores.sort((a, b) => b - a) it took 4 minutes to fix and 3 weeks for anyone to notice