Forem: SysLayer

Coding Cat Oran Ep4, Speaking Human

SysLayer — Fri, 17 Apr 2026 00:59:49 +0000

The boss called a company-wide meeting. Twenty minutes, conference room, Friday 2pm.

"Oran, you'll present the new system. Show everyone how it works."

Oran had three days to prepare. He felt ready. He'd rebuilt the permission layer, redesigned the inventory module, added the approval workflow. The system was solid.

He made a slide deck. Fifteen slides. Entity-relationship diagrams. SQL snippets. A flowchart of the permission check logic. Technical. Thorough. Accurate.

Friday came. Oran stood in front of the room. Duke and the warehouse crew in the back row. Ms. Lin in the front. The factory floor supervisor. The sales team. The GM.

Oran clicked to the first slide: an ER diagram with five tables and foreign key arrows.

The room went silent. Not the good kind.

He lost them in ninety seconds.

Duke leaned over to a coworker and whispered something. Ms. Lin politely took out her phone. The GM was nodding — but the way people nod when they want you to finish faster.

Oran made it through seven slides before the GM raised his hand.

"Oran. I believe you. The system works. But I have one question."

"Yes?"

"Can you tell me, in plain words, what this system does for us? Not how it's built. What it does."

Oran opened his mouth. Then closed it.

He had spent weeks building the system. He could explain every table, every join, every constraint. But he couldn't say, in one sentence, what it meant for the people in this room.

That weekend, Oran sat at his kitchen table and rewrote everything.

Not the code. The words.

He realized that technical people think in structure — tables, relationships, data flow. But everyone else thinks in outcomes — what can I do, what changes for me, what problems go away.

He needed to translate.

He made a new deck. Three slides.

Slide 1: "What changes for you"

"You'll log in and see only what's relevant to your job. Warehouse sees inventory. Finance sees billing. No clutter, no confusion."

Slide 2: "What you can trust"

"Every approval, every change, every access grant is recorded. If you ever need to ask 'who did this and when' — the system has the answer."

Slide 3: "What you control"

"New hire? Your department head assigns them a role. No ticket to IT. They get exactly the access they need — nothing more, nothing less."

No ER diagrams. No SQL. No arrows.

Monday. Oran presented again. Same room. Same people.

This time, Duke nodded — the real kind. Ms. Lin put her phone away. The sales team asked questions. Good questions. "Can I get a weekly report of my orders?" "Can we add a read-only role for the auditor who comes quarterly?"

The GM said, "This is what I wanted to hear last week."

Oran learned something that day that wasn't in any course he'd bought:

The system doesn't exist until people understand it.

You can build the most elegant schema in the world. If you can't explain it to Duke in one sentence, it doesn't matter.

And here's the thing — this skill made Oran a better developer too.

When he forced himself to describe the permission system as "you see only what's relevant to your job," he immediately spotted a gap in his own design. He hadn't built a dashboard that showed users their own access. He'd built the backend but forgot the human-facing layer.

Translating tech into human language isn't dumbing it down. It's a design review in disguise.

Every time you explain a feature in plain words and it sounds confusing — that's a sign the feature itself is confused.

Oran went back to his desk and added three things to his system:

A "My Access" page where users see their own permissions in plain language
A role summary page for department heads — no SQL, just a clean table
Notification emails when access changes: "You've been granted the Warehouse Staff role by Duke on March 15."

Small features. Huge difference. Because now the system spoke human.

Next episode: Six months later. The GM asks Oran to lead the next project. Oran isn't just the developer anymore — he's the one who decides what gets built. The orange cat grows into a role nobody hired him for.

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

Coding Cat Oran Ep3, Five Tables Changed Everything

SysLayer — Thu, 16 Apr 2026 06:12:43 +0000

Oran spent two weeks doing something that felt like not working.

He sat with the warehouse team during morning receiving. He watched Ms. Lin process purchase orders after lunch. He stood on the factory floor while the supervisor assigned shifts. He even attended the Monday management meeting — the only cat in a room full of dogs — and took notes.

He didn't write a single line of code.

But he filled an entire notebook.

Patterns started showing up.

Every department had the same complaint in different words:

Warehouse: "We shouldn't see pricing."
Finance: "We need to know who approved what."
Production: "The supervisor can assign shifts, but only the manager can approve overtime."
Sales: "I need to see orders but not cost breakdowns."

Oran stared at his notebook. All of these were the same problem.

Who can do what. And who said they could.

He went back to his AI tools and prompted: "best way to handle permissions in a web application."

The AI gave him a middleware snippet with hardcoded role checks. if role == 'admin'. if role == 'manager'. The same pattern he'd already built. The same pattern that broke.

So Oran did something he hadn't done before. He closed the AI and opened Google. Then a textbook. Then a blog post from someone who had clearly been through the same pain.

He found RBAC.

Role-Based Access Control. Not a framework. Not a library. A design pattern. And at its core, a data model — five tables in a relational database.

users. roles. permissions. And two mapping tables to connect them.

The idea was simple: permissions are data, not code.

You don't write if role == 'warehouse_lead' in your application. You store warehouse_lead → inventory:read, inventory:update in the database. The app asks one question: does this user have this permission? A single SQL query answers it.

This changed how Oran thought about everything.

Suddenly, Duke's requirement — "my guys shouldn't see pricing" — wasn't a special case. It was a permission row: warehouse_staff role gets inventory:read but not pricing:read.

Ms. Lin's approval chain? The granted_by and granted_at columns on the role assignment table. Every permission change is a row. Every row is an audit record.

The production supervisor approving shifts but not overtime? Two different permissions: shifts:assign and overtime:approve. One role has both. One role has only the first.

No if/else. No spaghetti. Just data.

But here's what really clicked for Oran. The 5-table model wasn't just a technical solution. It was a communication tool.

He drew the schema on a whiteboard and walked Ms. Lin through it. "This table is your list of people. This table is the list of roles — think of them as job titles for system access. This table is every action the system can do. And these two tables connect them."

Ms. Lin nodded. "So if I want to give the new accountant the same access as me, you just..."

"Copy your role assignments. One query. No code change."

"And I can see who has what access?"

"One report. Anytime."

Ms. Lin smiled for the first time since Oran started.

That night, Oran rebuilt the permission layer. AI helped him write the SQL faster — but the design was his. Every table, every column, every constraint came from the notebook he filled during those two weeks of watching and listening.

He was learning a lesson most developers take years to learn:

SQL isn't just storage. It's where business logic lives. The approval threshold ($5,000) is a value in a table. The permission boundary is a row in a mapping table. The audit trail is a timestamp on every change.

When business rules live in the database, they survive framework migrations, language rewrites, and developer turnover. They survive even when the only dev at the company is one orange cat.

Next episode: The boss asks Oran to present the system to the whole company. Oran learns that explaining a database to non-technical people is a skill nobody taught him — and maybe the most important one.

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

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

SysLayer — Wed, 15 Apr 2026 12:06:15 +0000

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:

Go back to every department
Watch them work — don't just ask what they need
Write down what they do, not what they say
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.

Coding Cat Oran Ep1, The Prompt Programmer.

SysLayer — Tue, 14 Apr 2026 06:30:03 +0000

Oran is an orange cat with no computer science degree.

He learned to code the way most cats do — late at night, alone, watching online courses he bought on sale. JavaScript. Python. A little SQL. Enough to build things that work, not enough to explain why they work.

But Oran could build. And in 2025, that was enough to get hired.

Rust-Belt Manufacturing is a mid-size factory two hours from the nearest tech hub. They make industrial parts — bolts, brackets, fittings. The kind of stuff that holds bridges together but never trends on Twitter.

They posted one job listing: "IT Developer — build our internal systems."

No mention of a team. No mention of an architect or a QA engineer. Just one line at the bottom:

"We need someone who can figure things out."

Oran applied. Oran got the job.

Day one. Oran got a desk, a laptop, and a requirements doc — three pages, written by the factory manager in bullet points:

Track production orders
Manage inventory
Let different departments see different things
"Make it like SAP but simple"

Oran opened Cursor, cracked his knuckles, and started prompting.

"Build a production order management system with 
 inventory tracking, user login, and role-based 
 access. Use Python, FastAPI, PostgreSQL."

Code poured out. Models, routes, schemas, migrations. Oran reviewed it, tweaked a few things, prompted again. By Wednesday he had a working prototype. By Friday he demoed it to the boss.

"This is great," the boss said. "Ship it."

Oran felt invincible. He wrote a tweet that night:

"Day 5 at new job. Full system prototype done. AI is the real senior developer. 🐱"

He got 47 likes. A reply said "king." Another said "this is the future of engineering."

Oran believed them.

But here's what Oran didn't notice during his speed run:

He never talked to the warehouse team. He never sat with the finance department. He never asked anyone what "different departments see different things" actually meant in practice.

He built what the requirements doc said. Word for word. Prompt for prompt.

He didn't know it yet, but the requirements doc was wrong.

Not wrong as in typos. Wrong as in — the factory manager wrote what he thought the system should do, not what the teams actually needed.

And Oran, riding high on demo-day dopamine, didn't think to question it.

That would come on Monday.

Next episode: Oran meets the users. And learns that "role-based access" means something very different to the warehouse manager, the accountant, and the factory floor supervisor.

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