DEV Community: Sonny kk

how to repeat texts up to 10,000 times quickly

Sonny kk — Wed, 08 Jul 2026 05:54:48 +0000

I Found a Product Idea Hiding Inside a Google Autocomplete Suggestion. Here's the Full Case Study.

Most indie hacker case studies start with "I had a problem, so I built a solution." Mine didn't start that way. Mine started with a autocomplete dropdown that made zero sense to me at first glance — and turned into one of the more satisfying small builds I've shipped.

I'm sharing the full process here: the research, the validation, the build, and what happened after launch. No inflated numbers, no "I made $10k in a weekend" nonsense. Just an honest walkthrough for other devs who like turning small, weird ideas into working products.

Step 1: Noticing the Signal

I was doing routine keyword research for a text utility site when I typed "sorry" into a search tool out of curiosity. The autocomplete and related-searches data showed something odd: write sorry 100 times as a real, recurring, high-frequency query. Not a fluke — consistent month over month.
Before you go further here is output example of tool -
I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺

That's usually the point where most people scroll past and move on. I didn't, because a repeating pattern like that is a signal, not noise. Real people were typing that exact phrase into Google with real intent behind it.

Step 2: Figuring Out the Actual Intent

Search volume alone doesn't tell you what to build. I had to figure out what someone typing "sorry 100 times" actually wanted as an end result. A few possibilities:

They wanted to read about the phrase (informational intent)
They wanted a pre-written block of "sorry" repeated, ready to copy (transactional intent)
They wanted a meme or joke image

I checked what was already ranking. Almost everything was either a bare-bones repeater tool with poor UX, or low-effort content pages with no actual usable output. That told me the intent was clearly transactional — people wanted the text itself, generated instantly, not an article about apologies. And nobody had built a genuinely good tool for it.

That's validation. Not survey data, not a landing page test — just a clear, unmet, repeating demand with weak existing competition.

Step 3: Scoping the MVP Ruthlessly

It would've been easy to over-scope this. Add accounts, add a "save your history" feature, add social sharing, add a dozen preset categories. I didn't. The entire point of someone searching "sorry 1000 times" is urgency — they want output fast, not a feature tour.

So the MVP became intentionally minimal:

A text input, plus a few ready-made presets for common cases
A count selector — 100, 1,000, 10,000
A generate button
Copy button
Download as .txt button

That's it. No sign-up wall, no unnecessary steps between the search query and the result.

Step 4: Building and Shipping Fast

Because the scope was so tight, the build itself only took a few focused sessions. Plain HTML, CSS, and JavaScript — no framework overhead needed for something this contained. I kept performance in mind from the start, since generating up to 10,000 repetitions needed to feel instant, not sluggish, or the entire value proposition falls apart.

I didn't wait for a "perfect" version. I shipped the minimal version, watched how real users interacted with it, and iterated afterward based on actual usage rather than my own assumptions.

Step 5: What I Learned Post-Launch

A few things surprised me once real traffic started coming in:

People use presets more than I expected. I assumed most users would type their own text, but a large chunk of users click straight into a preset and generate immediately. Reducing typing effort mattered more than I predicted.

The download button gets used more on mobile. Copy-paste on mobile keyboards is clunky when the block of text is huge, so a lot of mobile users prefer downloading the .txt file over trying to copy 10,000 lines by hand.

"Sorry 100 times copy and paste" style intent dominates. Almost everyone wants the output ready to paste somewhere immediately — a group chat, a text message, a caption — not a file to keep. Copy usage outpaces downloads by a wide margin.

The Bigger Lesson for Other Indie Dev's

You don't need a groundbreaking idea to build something worth shipping. You need a real, repeating signal of demand, a clear-eyed read on what people actually want when they search that phrase, and the discipline to build only what solves that specific need — nothing more.

This entire project started because I refused to scroll past a weird, oddly specific search query. If you're doing keyword or market research for your own side project, don't dismiss the strange, hyper-specific queries. Sometimes those are exactly the ones nobody has bothered to build a good solution for yet.

If you want to see the finished result of this whole process, it's a live tool now — simple enough that you can generate something like sorry 10,000 times output in under ten seconds without writing a single line of code yourself.

Sorry 100 times generator

Sonny kk — Wed, 08 Jul 2026 05:48:03 +0000

How I Built a Text Repeater That Doesn't Freeze the Browser at 10,000 Repetitions

A few months back I shipped a small utility that does one thing: repeat a block of text however many times you want. Sounds trivial, right? String repetition is a one-liner in most languages. But the moment I put a "10,000" option in the UI, I ran into a handful of problems that taught me more about browser performance than I expected from something this small.

This is a build log, not a highlight reel. I want to walk through the actual technical decisions, including the ones that didn't work the first time.
Before going further see some example output of the tool-
I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺 I am really sorry 🥺

The Trigger: A Weird Keyword

Before any code, there was a keyword. I was doing search research for a side project and noticed a strange pattern: thousands of people searching sorry 1000 times every month. Not a typo, not a one-off — a consistent, recurring search. People wanted a fast way to generate a huge block of repeated text, usually the word "sorry," and copy or download it immediately.

That's a product decision hiding inside a search query. So I decided to build it properly, as a developer, not just slap together a script.

Problem 1: Naive String Repetition Doesn't Scale the Way You Think

My first pass looked roughly like this:

function repeatText(text, count) { let result = ""; for (let i = 0; i < count; i++) { result += text + "\n"; } return result; }
At 100 repetitions, fine. At 1,000, still fine. At 10,000, this starts to hurt — repeated string concatenation in a loop creates a lot of intermediate string allocations, and depending on the engine, that can get expensive fast. The fix was obvious once I looked at it properly: build an array and join it once.

function repeatText(text, count) { return Array(count).fill(text).join("\n"); }

Massive improvement. Lesson: don't concatenate strings in a hot loop, ever, even for something as "simple" as a repeater tool.

Problem 2: Rendering 10,000 Lines to the DOM Is the Real Bottleneck

Generating the string was fast. Displaying it wasn't. Dumping 10,000 lines into a <textarea> or a rendered

caused visible jank on lower-end devices, especially mobile. The DOM doesn't care how efficient your string logic is if you're forcing a massive reflow.

The fix here was to keep the raw text in a <textarea>, which browsers handle far better than rendering thousands of individual DOM nodes (which is what would happen if I'd foolishly rendered each repetition as its own element, something I actually tried first and immediately regretted). A <textarea> treats it as plain text content, not a DOM tree, so it stays lightweight even at 10,000 lines.

Problem 3: Copy and Download Needed to Feel Instant

Since the whole point of this tool is speed — someone searching "sorry 100 times" wants their text now, not after five seconds of spinner — I had to be careful with the copy and download flows too.

For copying, I used the Clipboard API directly instead of the older document.execCommand("copy") fallback, since it's cleaner and doesn't require selecting text manually:
async function copyToClipboard(text) { try { await navigator.clipboard.writeText(text); } catch (err) { console.error("Copy failed", err); } }

For downloading, I generate a Blob client-side and trigger a download without ever touching a server:

function downloadAsTxt(text, filename = "repeated-text.txt") { const blob = new Blob([text], { type: "text/plain" }); const url = URL.createObjectURL(blob); const a = document.createElement("a"); a.href = url; a.download = filename; a.click(); URL.revokeObjectURL(url); }
No backend call, no waiting, no server round-trip. Everything happens in-browser, which matters a lot when your entire value proposition is speed.

Problem 4: Debouncing the Generate Action

Early testers (mostly friends I roped into clicking buttons for me) kept mashing the generate button impatiently, especially at the 10,000 setting, thinking it hadn't registered. I added a short debounce and a lightweight "generating..." state so the UI gives immediate feedback even though the actual generation takes milliseconds. Perceived performance matters as much as real performance.

What I'd Tell Another Developer Building Something Similar

If you're building anything that takes a "how many times" input from a user, don't assume they'll stick to reasonable numbers. Someone will always test the upper limit immediately — in my case, that's literally the point, since people specifically search for the highest counts like "sorry 1000 times" or more. Build for the ceiling, not the average case.

Also, resist the urge to over-engineer a tool this small. I didn't need a framework, a state management library, or a backend. Vanilla JS, a textarea, the Clipboard API, and the Blob API covered everything. Sometimes the right architecture is just... less architecture.

If you want to see how the copy and download flow feels in practice, the tool supports presets too, so you can test type sorry 100 times copy and paste style output in a couple of clicks without typing anything yourself. I'd genuinely appreciate feedback from other devs on what would break this at scale — I'm always looking for the next edge case I haven't hit yet.