The night before release, past 11 PM, I was staring intently at the terminal output. When I saw a single line of text remaining at the end of the flowing logs, I almost let out a sound. exit 124——a timeout force-termination code. The script that automatically posted to SNS every morning had been silently dying from time to time. I told myself it was "not fatal." It only happened about once in four times, and when it worked, it worked properly. But it was definitely "broken." Knowing that, the next morning I pressed the release button. This essay is an honest record of that decision and what happened afterward.
That day, I was doing final testing on an automation tool that had finally come together. It was a script that managed scheduled SNS posts to a brand account I personally operated, something I'd been gradually shaping over two weeks.
While looking over the test execution logs, an unfamiliar number caught my eye. exit 124. When this exit code appears on Linux, it means a timeout——the process didn't finish within the allotted time and was forcibly terminated by the OS. When I checked, the timeout setting for the posting process was far too tight relative to the actual processing time.
What the Numbers Revealed
I would later learn through proper measurement, but at that point the night before, I only had a rough sense of things. The average processing time was about 150 seconds, and the timeout setting was 180 seconds. There was only 30 seconds of margin, and it would fail immediately if the API response was even slightly delayed.
Before: Success rate approximately 75% (7-8 out of 10 runs completed)
After (operating for one week without fixing): Success rate approximately 40% (timing worsened due to environmental changes)
However, I only understood these numbers after the release. The night before, I was only estimating "about once in four times" by feel, without proper measurement. This would later become a source of regret.
For 30 minutes after confirming the bug, I kept thinking about it right there.
If I fixed it, simply increasing the timeout value wouldn't be a fundamental solution. I'd need to identify why the process was slow, rebuild the retry mechanism, retest——even a conservative estimate would take a full day. It was already 11 PM. I had already announced that I would "go public" the next day.
If I chose "fix it before releasing," I'd be breaking a promise. If I chose "release it as is," I'd be handing over something broken. Two options, neither of which was right, were lined up before me.
Why I Chose "Release"
My final decision to release was closer to intuition than logic.
This bug wasn't "doesn't work" but "sometimes doesn't work." It wasn't completely broken. And I thought what I'd lose by not releasing——the opportunity to have people try it, the time to get feedback, my own motivation——was bigger than one bug.
To be honest, I also knew from past experience that if I kept waiting to make things "perfect," I'd never be able to release anything.
Since I started personal development, I can't count how many times I've repeated the same thing. "Just a little more polish," "after I add that feature," "once I've tested it properly"——I've shelved countless things by putting them off like that.
The desire to release something perfect is real. But perfection and release are, in most cases, incompatible. Especially in personal development, time and energy are finite, and I keep raising the bar for "perfection" myself.
I was confident I could fix this bug too. But not "tonight." And when I thought "if not tonight, when will I fix it?", releasing first seemed more realistic. There's no point in fixing something that isn't being used——no one will ever see it.
The week after release, things got worse.
What was supposed to be "once in four times" failures turned into six out of ten runs stopping midway. When I investigated, I found that API response times were slower during certain time periods, and the already-tight timeout setting was taking the full brunt of that impact. When the success rate dropped below 40%, I finally decided this couldn't be left alone.
Emergency Patch and Root Fix
That weekend, I spent 2 hours reviewing the timeout value and processing order. I extended the timeout from 180 seconds to 300 seconds and reorganized the order to include a lightweight connectivity check before heavy processing. It was a mundane change——just modifying a single number in a configuration file.
That alone brought the success rate back above 95% the next day. The time spent: 2 hours. The fix I thought would take "a full day" the night before release actually took 2 hours. I think my estimate back then had been exaggerated by fatigue and panic.
What I regret most about this episode isn't releasing with a bug. It's making a judgment based only on intuition——"probably about once in four times"——without proper measurement.
If I had properly measured 10 runs the night before and understood the numbers as "75% success rate," even if the decision to "release" wouldn't have changed, I could have addressed it faster. Intuition matters, but sometimes numbers are unbeatable. It's less about engineering and more about properly questioning your own understanding.
And I also wish I'd added one line after release: "This isn't the final form yet. If something doesn't work, please let me know"——if you're handing over something imperfect, a bit of honesty about that changes how the recipient perceives it. Hiding imperfection versus sharing imperfection——I think the latter builds more trust as an individual developer.
As I write this record of the day I released with a bug, I'm left with a feeling I can't quite resolve——neither "that was the right call" nor "that was definitely a mistake."
But one thing is certain: because I released it, I was able to fix it. If I'd shelved it, that bug would have existed there forever, unknown to anyone, never fixed. The release didn't break it——the release revealed that it was broken, and I was able to fix it.
I now think personal development isn't a place to pursue perfection, but a place to nurture something while it's running.
That "almost finished" thing in your hands right now——maybe it's okay to release it today.
Lily (@bokuwalily) — Individual developer. Working hand-in-hand with AI to create iOS apps and web services.
