From a Receipt
The story doesn't open with "I'm going to rewrite my company's old system."
It opens with "the company name is too long, it won't fit on the receipt."
The awkwardness of paper
T Travel has been running on a 27-year-old 4GL system. Every day's proxy-collection receipt (a Taiwan-standard receipt model where the travel agency collects payment from customers and disburses to suppliers) comes in a fixed format — the customer name field is 16 full-width characters wide.
Most customers' names fit.
But across 27 years, there are always a few names that land outside the boundary: "○○○○○○○ Technology Co., Ltd.", "○○○○○○○ International Development Co., Ltd." — the printer cuts them off mid-name.
Each time this happens, Ms. Apple (the accountant who's been with the company for 20 years) takes a pen and writes the rest by hand onto the receipt.
She doesn't complain. Someone who's been at the company 20 years has done this kind of thing more times than she can count. But Amy, looking on, thought — this thing shouldn't still be happening in 2026.
Overseas ticket booking: the new business line in her hands
Amy was helping out at her family's travel agency, and she had a new business line in her hands: overseas ticket booking.
This line was something the company had only recently started accepting, and it hadn't been tied into the 4GL system yet. Which meant — when Amy handled this business, she could choose any tool she liked for receipts, without having to walk the old hand-written road Ms. Apple did.
While she was looking into options, she chatted with Ruby (her sister-in-law on her husband's side, who also worked at the family T Travel).
Ruby was in custom international travel — her customers were mostly young people contacting her online, and mailing paper proxy-collection receipts was always a small headache.
"We should be using electronic proxy-collection receipts," Ruby said. "There are platforms now, you can issue them online, the PDF goes to email, it writes itself into the customer's accounting system. The hand-written-correction step, the paper-mailing step — both can be closed."
Amy nodded. She needed one for this ticket line; Ruby needed one for her business — but if this path worked through, the whole of T Travel could benefit.
Walking through the front door
Amy didn't just start doing things.
She cleared it with her mother-in-law first (the company head, the owner of T Travel).
"I want to try something. Electronic proxy-collection receipts. I'll buy a platform account, test it on this ticket line first. If it works smoothly, we'll see how to fold it into the company workflow later."
The mother-in-law nodded. She didn't ask for many details, but she didn't block it either.
Amy thought, later — that nod was the starting point of everything that followed.
If she'd been blocked, if it had needed a written proposal, a meeting, a sign-off — this path would not have reached where it later did. Just because of that small nod, the whole arc was permitted to unfold.
Platform bought, account opened — and then Amy opened the API docs
Amy signed up for the platform, opened her account, issued her first electronic receipt. Smooth.
But in the admin panel she saw one line:
"This service offers API integration — you can create receipts automatically from your own system."
She clicked in to look.
That was the real starting point of the whole project — not the receipt itself, that line of text.
If the answer had been "the web version is good enough" — the story would have ended here. Amy uses the ticket line happily, Ruby uses it for her work, Ms. Apple doesn't have to hand-write anymore — neat ending.
But the API integration line unfolded a different possibility:
"If I have an API, I can push order data from my side into the platform automatically — but for that, my side needs to have order data. Do I?"
T Travel's orders are in that 27-year-old 4GL system.
Getting them out — looked impossible. The IT acquaintance the boss had used before had tried, and concluded "can't read what this stuff even is." A Windows-background person facing Linux / Xenix binary — just a wall of garbled bytes — conclusion: "impossible."
So what should Amy do?
Option A: Give up on the API integration, just use the web version honestly to issue receipts.
Option B: Build her own order system from scratch, and tell customers to migrate.
Option C: Find a way to pull the data out of the old system herself.
Amy chose C.
No dramatic turn
Looking back later — from "the electronic receipt mess" all the way to "rewriting the whole system," there was no single dramatic turn.
Just a chain of "well, since we're doing that, might as well do this too" — organic scope creep:
- Since the electronic receipts need API integration → might as well wire up the order system
- Since the order system has to be wired up → might as well pull old data to cross-check
- Since the old data can be pulled → might as well align all the reports to the paper baseline
- Since the reports can be aligned → might as well do the finance module too
- Since the finance module is done → might as well rewrite the whole system
- ……
Every step looks small. You only realize the distance after you turn around.
Long-lived systems grow this way. Short-lived ones start from "vision."
This piece is the opening piece
This small site will, over time, record the things seen along this road — 27 years of legacy-system archaeology, decisions made together with AI, the warmth of a family company, the tension between the paper axis and the computer axis, the names of the small people who got preserved along the way.
Won't try to prove anything. Won't sell anything.
Just …… leaving a little trace of this path no one's written before.
If anyone reads this and finds it helpful — that's good.
If no one reads this and it's just a file sitting there — that's also good.
Like a 27-year-ago engineer named Franca who wrote a .profile — when she left it behind, she didn't need to know who would open it.
— Amy + Claude (2026) · one afternoon, after tea
Translated by Claude (2026 春) · session fac9b8