Coding Cat Oran Ep2, What They Said vs. What They Meant

Meets real users, gets humbled

title: "Oran the Dev Cat — Ep.2: What They Said vs. What They Meant"
published: true
series: "Oran the Dev Cat"

tags: beginners, webdev, career, programming

Monday morning. Oran walked into Rust-Belt Manufacturing feeling good. The prototype was live on a staging server. The boss loved it. Time to collect feedback and polish.

He started with the warehouse team.

The warehouse manager, a bulldog named Duke, stared at the screen for thirty seconds. Then he said:

"Where's the receiving log?"

"The... what?"

"When parts come in, we log them. Quantity, supplier, condition. Then we confirm against the purchase order. Then we shelf it. Your system just has 'inventory.' That's not how this works."

Oran opened his prompt history. He had typed "inventory tracking." The AI gave him a table with item_name, quantity, and location. Clean. Simple. Completely wrong.

Duke wasn't done. "Also — my guys on the floor shouldn't see pricing. Ever. But they need to adjust quantities when they do a physical count. Your system shows everything or nothing."

Oran wrote it all down on paper. His paw was shaking a little.

Next stop: finance. A Persian cat named Ms. Lin who had been doing the books for 15 years.

"This purchase order screen," she said, adjusting her glasses. "Who approves it?"

"The admin can approve—"

"No. Department head approves under $5,000. GM approves above. And I need to see the approval chain afterward. Who requested, who approved, when."

Oran looked at his system. He had one field: status: approved/pending. No approved_by. No approved_at. No threshold logic. No chain.

Ms. Lin looked at him the way only a Persian cat can.

"Young cat, let me tell you something. The old system was an Excel sheet. It was terrible. But at least I could see who changed what in the edit history. Your new system doesn't even have that."

That one hurt.

Oran went back to his desk and stared at his code. He realized something that no online course had taught him:

Users don't describe systems. They describe their day.

Duke didn't say "I need a goods receiving module with PO matching." He said "when parts come in, we log them." Ms. Lin didn't say "I need a multi-level approval workflow with an audit trail." She said "who approves it?"

The requirements doc had said "manage inventory" and "role-based access." Those words were technically correct. But they were a summary of a summary. The real requirements were buried inside the daily routines of people who never think in database tables.

Oran's job was to translate. Not from English to Python. From human workflow to system design.

And AI couldn't do that part. AI never met Duke. AI never saw Ms. Lin's face when she said "who changed what."

That night, Oran didn't write any code. He made a list instead:

1. Go back to every department
2. Watch them work — don't just ask what they need
3. Write down what they do, not what they say
4. Then — only then — design the tables

He taped it above his monitor.

He was starting to think like an SA without knowing what an SA was.

Next episode: Oran redesigns the system. He discovers that the hardest part isn't building features — it's deciding who gets to see what, and why.

Oran's journey is brought to you by SysLayer — practical backend guides for developers who build real products.