DEV Community: SysLayer

I Write a Story About a Cat Who Builds ERP Systems With AI. Here's the Real Reason.

SysLayer — Mon, 27 Apr 2026 06:49:39 +0000

Coding Cat Oran is fiction. But everything that happens to him already happened to someone.

`Most developers don't talk about the part where they almost shipped something they didn't understand.
That part isn't in the tutorials. It's not in the conference talks. You won't find it in the post-mortems, because no one writes post-mortems about the times they got lucky.
But it's real. And in 2025, it's happening faster than ever.

Oran is an orange cat. He has no CS degree. He learns to code late at night, alone, with AI tools and online courses he bought on sale.
He gets hired anyway. Because in 2025, that's enough to get hired.
His first job: build an internal ERP system for a manufacturing company. One developer. No team. No architect. A requirements doc written in bullet points by someone who once saw SAP and thought: make it like that, but simple.
Oran opens his AI coding tool and starts prompting.
What happens next is the series.

Why I'm writing this
I've spent years building production systems — ERP, WMS, permission management, traceability systems. Real systems, for real factories, with real consequences when something breaks at 2am on a Tuesday.
I've watched the tools change. I've watched what AI makes easier, and I've watched what it quietly makes worse.
The gap between working prototype and production-ready system is not smaller than it used to be. If anything, it's wider — because now you can generate the prototype in a day, and spend the next six months discovering what it didn't know it didn't know.
Oran is how I write about that gap honestly. Fiction lets me be more precise than a technical post does.

What the series is
Coding Cat Oran is a serialized fiction about a solo developer building real systems with AI tools — and learning, episode by episode, what the tools can and cannot carry.
It's not anti-AI. Oran uses AI constantly. So do I.
It's about the judgment layer that sits above the tools. The part that knows when a five-table schema is actually a trap. The part that asks who maintains this in two years. The part that no prompt can replace.
Each episode is short — under 5 minutes. Each one ends at the edge of a real engineering problem.

Start here
→ Ep1: The Prompt Programmer — Oran gets the job and ships a prototype by Friday.

→ Ep2: What They Said vs. What They Meant — The requirements doc was three pages. The real requirements were not written anywhere.

→ Ep3: Five Tables Changed Everything — The permission system gets a schema. It's almost right.

→ Ep4: Speaking Human — The GM wants a dashboard. Oran learns that "simple" is a political statement.

→ Ep5: The IT Manager Nobody Hired — Six months in. Oran gets promoted to a job that doesn't have a title.

New episodes publish weekly. Follow SysLayer on dev.to to catch them.
If you build systems for a living — or want to — Oran is for you.

Coding Cat Oran Ep5, The IT Manager Nobody Hired

SysLayer — Mon, 20 Apr 2026 01:13:47 +0000

Six months at Rust-Belt Manufacturing. The permission system was running. Inventory was live. The approval workflow hadn't broken once.

The GM called Oran into his office.

"We need a new system for production scheduling. And I want you to lead it — not just the coding. The whole thing. Requirements, design, timeline, rollout."

Oran blinked. "That sounds like a project manager's job."

"It sounds like your job. You're the one who knows how to talk to the teams and turn it into something that works."

Oran walked out with a new title on his business card: IT Manager.

No raise negotiation. No interview panel. It just happened. Because in a small company, titles don't come from HR — they come from trust. And Oran had earned it the hard way.

He sat down and thought about how he got here.

Month 1: He was a prompt programmer. He typed descriptions into AI and shipped whatever came out. He thought speed was the skill. Build fast, demo fast, move on.

Month 2: He met the users. He learned that requirements documents lie — not on purpose, but because the people who write them aren't the people who do the work. He learned to watch before he asked, and to ask before he built.

Month 3: He discovered that the database isn't just storage — it's where business rules live. Permission boundaries, approval thresholds, audit trails. When logic lives in SQL, it survives everything: framework changes, rewrites, developer turnover. He learned to think in tables.

Month 4: He stood in front of a room and failed. Then he stood in front of the same room and succeeded. The difference wasn't the system — it was the language. He learned to translate technology into outcomes. Not "five tables with junction mappings" but "you see only what's relevant to your job."

Month 5–6: People started coming to him. Not with bug reports — with ideas. "Can we track supplier lead times?" "Can we see which orders are late?" "Can we give the external auditor a login?" Each conversation was a mini requirements session. And Oran was running them naturally, without a methodology or a framework. Just a notebook, good questions, and the habit of listening before building.

Here's what Oran knows now that he didn't know on day one:

AI is a tool, not a teacher. It writes code when you tell it what to write. But it can't sit with Duke and watch how receiving actually works. It can't read Ms. Lin's face when she says "who changed that number." It can't stand in a conference room and feel the silence when nobody understands your slide. The decisions that matter — what to build, for whom, and why — those are still yours.

SQL is a thinking language. Not just a query language. When you model a business process in tables and relationships, you're forced to be precise. "Approval" stops being a vague word and becomes: who approves, at what threshold, in what order, and what's the record. The database doesn't accept hand-waving.

Translation is the real skill. A developer who can explain a system to the warehouse manager AND model it in SQL AND implement it in code — that person isn't just a programmer. That person is the architect, the analyst, and the project manager. In a small company, that's the whole IT department.

Oran started the production scheduling project the next Monday. This time, he didn't open Cursor first.

He grabbed his notebook and walked to the factory floor.

One year later, Rust-Belt Manufacturing has four internal systems — all designed by Oran, all running on the same permission model, all speaking human to the teams that use them.

Oran still writes prompts. He still uses AI to code faster. But he decides what to build before he decides how to build it.

He's an orange cat with no CS degree who became the IT backbone of a factory.

Not because he could code.

Because he could listen, design, and translate.

Thanks for following Oran's story. If the permission system chapters sounded familiar — the 5-table schema, the audit trail, the feature-level access controls — I wrote the complete technical guide:

📘 How to Build an RBAC Permission System — Complete SQL Edition

85 pages. PostgreSQL, MySQL 8+, SQL Server. The guide Oran wished he had on day one.

SysLayer — Practical backend guides for developers who build real products.

Try it Now!

syslayer.it.com

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.

Try SQL Generator Now!

syslayer.it.com

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.

Try SQL Generator Now!

syslayer.it.com

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

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.

Try SQL Generator Now!

syslayer.it.com

Coding Cat Oran Ep1, The Prompt Programmer.

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

title: "Oran the Dev Cat — Ep.1: The Prompt Programmer"
published: true
series: "Oran the Dev Cat"

tags: beginners, webdev, career, programming

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.

Try SQL Generator Now!

syslayer.it.com