In December 2002 I joined a company that was nearly bankrupt.
I was twenty-five. A software engineer with no title beyond that. The company was burning cash, and the next product launch had to happen in January — about a month after I started.
By January 2003, the demo shipped.
It was an HTML browser for mobile phones — with packet reduction built in. It rendered HTML, played back MIDI files linked from <a> tags, ran simple background animations. I wrote it in Java.
The server was PHP. There was no engineer for the server-side compression part, so I did that too — also in Java, called from PHP over localhost.
A strange shape, but the deadline was real.
I remember being a little angry. I also remember being much happier than angry. I had shipped something, in a month.
That's how I started designing things alone. Not as a plan. Just: someone had to, and nobody else moved.
The first thing that wasn't a plan
Looking back twenty-three years later, here's something I didn't notice at the time:
I had no responsibility. I was a junior engineer with a deadline. If the demo had failed, the company would have collapsed faster — but the failure wouldn't have been mine to own.
That made it easy to ship.
After that first month, I never really had another hard deadline. Not on the projects I owned. I'd just answer "as soon as I can" and try to deliver on that.
By 2005 I was a CTO. The work didn't get lighter; the responsibility arrived. And here's the thing I didn't expect: the shape of my code didn't change.
I kept writing things by myself. I kept ending up alone on the deep parts. The org chart rearranged around me, but at the bottom — when something had to actually work — I was still just there, writing.
Productivity and accountability don't mix easily. The shape I learned at twenty-five — write it because nobody else will — was the shape that kept showing up after the title changed.
A shape I didn't notice was a shape (2003–2005)
After the packet-reduction tool, I built a music distribution platform for mobile phones. This was the carrier-billed era. Feature phones. Dropped connections in elevators and tunnels.
The carrier had a billing rule that taught me something I wouldn't articulate for twenty years.
The rule was: don't bill until the user's device confirms the download finished.
So the flow looked like this:
- User taps "buy"
- The phone starts downloading (with HTTP Range, because connections drop)
- The server delivers in chunks
- When the device finishes, it sends a hidden completion signal
- Then the server bills
If the train went into a tunnel, the user wasn't charged. The server kept holding the work for as long as the device was alive. Eventually either the download completed and we billed, or it didn't and we ate the cost.
Twenty years later I'd phrase the rule like this:
Nobody knows when a job will finish. But when it does, I want to report it accurately. So I make users wait — and in exchange, I retry as hard as I can until I have a result.
That was already the rule for the music platform in 2003. I just didn't know it was a rule yet.
The shape kept showing up (2006–2018)
In 2006 I started on an e-book distribution platform. Four months from blank page to production. I maintained it for eight years, alone.
The shape stayed the same:
- Direct delivery, no intermediary platforms in the way
- Real-time settlement back to publishers
- HTTP Range support, because phones still dropped connections
- Tar archives generated per request — buttons, branding, rights metadata stitched in at the moment of delivery, not pre-built and stored
I stepped off in 2014. The platform kept running.
By 2018, with someone else maintaining it, it was distributing tens of billions of yen in transactions per year.
It ran for seven years after I left, and then, in 2021, it was discontinued.
Eight years on my watch. Seven more without me. Then it stopped.
Not a tragedy. Not a triumph. Just what happened.
Same shape, bigger numbers (2021–)
In 2021 I started on what's now called LDX hub — a document processing platform for translation, OCR, structured extraction, and AI-assisted refinement.
Different domain. Same shape.
Year Documents processed Characters processed
2021 2,200 ~20M
2022 48,500 ~810M
2023 85,000 ~2.7B
2024 163,000 ~3.5B
2025 351,000 ~8.3B
The numbers grew. I didn't change anything fundamental about how the system is shaped. Jobs are submitted, the API holds the work, the API retries through whatever needs retrying, the API reports when there's a real result to report.
Same as the carrier-billed music platform. Same as the e-book distribution. Same as that strange first month with two languages talking through localhost.
I didn't decide to keep this shape. I just never found a better one.
Productivity and accountability, again
Looking back at twenty-four years, here's the only honest thing I can say:
The shape I learned with no responsibility — the shape that lets one person ship something in a month — turned out to be the shape that kept showing up after responsibility arrived.
Not because I planned for that. Because it was the only shape I knew how to write, and I kept writing it, and nothing about the larger numbers ever required me to write differently.
Whether that means anything for your system, I genuinely don't know.
I haven't found a different shape worth writing.
For twenty-four years, I keep ending up here.
Earlier in this series:
- The Accordion Pattern: Why I stopped writing one fat LLM prompt
- Nobody knows when a job will finish. I'd still like to report it accurately. (scheduled for May 4)
Top comments (0)