DEV Community: SysLayer

Coding Cat Oran S2 Ep6 — The Abstract Table and the Gateway

SysLayer — Fri, 15 May 2026 17:18:57 +0000

While three departments argued about column names,
IT built the thing anyway.
It passed the audit. Barely.
Barely is enough.

Day 87. Three days before re-audit.

In Conference Room B, the departments were in a meeting
about whether the report should show defect count or defect rate.
This meeting had been running, in various forms,
for eleven days.

Oran was not in the meeting.

He was in the server room
with his two developers —
Marcus, who knew SQL,
and Kevin, who was very enthusiastic —
and a whiteboard
covered in three tables.

Three tables, Oran had said on Day 60.
That's all we're building.
Everything else is a column.

The design.

The problem with every schema they had tried
was the same problem:
it assumed the data had a fixed shape.

Fixed columns. Fixed relationships. Fixed definitions.

But the data didn't have a fixed shape.
QA's data had a different shape than Engineering's.
Product A's data had a different shape than Product B's.
The shape kept changing because the specs kept changing
because the products kept evolving
because that's what trial production to mass production actually looks like.

You cannot design a fixed schema for a moving target.

So Oran stopped trying to design for the data.
He designed for the events.

-- Table 1: Something happened.
CREATE TABLE production_events (
  event_id      BIGINT        PRIMARY KEY IDENTITY(1,1),
  batch_id      VARCHAR(50)   NOT NULL,
  event_type    VARCHAR(50)   NOT NULL,   -- 'inspection', 'process', 'output', 'material_intake'
  occurred_at   DATETIME      NOT NULL,
  recorded_by   VARCHAR(50),
  source        VARCHAR(50)   NOT NULL    -- 'csv', 'excel', 'api', 'manual'
);

-- Table 2: Here's what we know about it.
CREATE TABLE event_attributes (
  attribute_id  BIGINT        PRIMARY KEY IDENTITY(1,1),
  event_id      BIGINT        NOT NULL REFERENCES production_events(event_id),
  key           VARCHAR(100)  NOT NULL,
  value         NVARCHAR(MAX),
  unit          VARCHAR(20)
);

-- Table 3: Here's what each key means — and when that meaning changed.
CREATE TABLE attribute_definitions (
  definition_id BIGINT        PRIMARY KEY IDENTITY(1,1),
  event_type    VARCHAR(50)   NOT NULL,
  key           VARCHAR(100)  NOT NULL,
  label         VARCHAR(200),
  data_type     VARCHAR(20),
  valid_from    DATE          NOT NULL,
  valid_to      DATE,                     -- NULL = currently valid
  added_by      VARCHAR(50),
  notes         TEXT
);

Three tables.
Every department's data fits.

QA's inspection: a production_event of type inspection,
with attributes for stage, result, defect_type, defect_count, inspector_id.

Engineering's process data: a production_event of type process,
with attributes for temperature, pressure, spec_version, compliance.

Manufacturing's output: a production_event of type output,
with attributes for quantity, shift, line_id, operator_id.

New column needed? Add a new key to event_attributes. No migration.
Spec changed? Add a new row to attribute_definitions with a new valid_from. Old data stays valid under the old definition.
New product line in Q3 with completely different parameters? Same three tables. Different keys.

Kevin said: "This is like... a database inside a database."
Marcus said: "It's EAV. Entity-Attribute-Value. It has tradeoffs."
Kevin said: "What tradeoffs?"
Marcus said: "Querying is slower. You have to pivot the attributes to get a report format.
You lose type safety at the column level.
It's harder to write ad-hoc queries."
Kevin said: "So why are we doing it?"

Oran looked at the whiteboard.
He thought about the spec that changed eleven months ago with no documentation.
He thought about QA's four inspection stages that might become five.
He thought about the new product line in Q3.
He thought about Conference Room B, where the meeting was still running.

"Because the alternative," he said,
"is redesigning the schema every time something changes.
And something always changes."

The gateway.

The schema solved the storage problem.
The gateway solved the input problem.

Three departments. Three data formats. Three ways of working
that were not going to change just because IT asked nicely.

Manufacturing would never use an API.
Their shift supervisors had been using Excel since 2009
and would continue using Excel until they retired.

QA had fourteen Excel templates. Different ones for different products.
They were not going to consolidate them.
Oran had stopped asking.

Engineering's test equipment could output to CSV automatically
but the engineers had also written some internal tools
that could call an HTTP endpoint if one existed.

So Oran built three doors to the same room.

[ Manufacturing Excel files ]  →  CSV drop folder  ┐
[ QA Excel templates        ]  →  Excel endpoint   ├→ Gateway → production_events
[ Engineering test equipment]  →  HTTP API         ┘            event_attributes

The gateway parsed each format,
validated the data against attribute_definitions,
rejected rows that didn't match,
logged everything,
and wrote clean events and attributes to the database.

Each department thought they were using their own system.
They were using the same system.
They didn't need to know.

Day 89. 11:47pm.

Marcus pushed the last fix.
Kevin ran the import script for the sixth time.
It finished without errors.

Oran ran the audit report query.

SELECT
  pe.batch_id,
  pe.occurred_at,
  MAX(CASE WHEN ea.key = 'output_qty'     THEN ea.value END) AS output_qty,
  MAX(CASE WHEN ea.key = 'defect_count'   THEN ea.value END) AS defect_count,
  MAX(CASE WHEN ea.key = 'final_result'   THEN ea.value END) AS inspection_result,
  MAX(CASE WHEN ea.key = 'material_lot'   THEN ea.value END) AS material_lot,
  MAX(CASE WHEN ea.key = 'spec_version'   THEN ea.value END) AS spec_version
FROM production_events pe
JOIN event_attributes ea ON ea.event_id = pe.event_id
WHERE pe.batch_id LIKE 'PA-%'
  AND pe.occurred_at >= '2024-01-01'
GROUP BY pe.batch_id, pe.occurred_at
ORDER BY pe.occurred_at;

It returned 847 rows.
Each one traceable from raw material to finished goods.
Each one stamped with the spec version that was in effect at the time.
Each one showing which system it came from, which operator recorded it, when.

Oran saved the result as a PDF.

He did not celebrate.
He had learned not to celebrate before the audit.

He closed his laptop.
He went home.
He slept four hours.

Day 90.

Ms. Chen arrived at 9am.
She opened her iPad.
She ran through the checklist.

Single source of truth: pass.
Traceability, raw material to finished goods: pass.
Audit trail for changes: pass.
Data in non-editable, auditable system: pass.
Report format matches customer requirements: pass.

She closed her iPad.

"This is sufficient for certification," she said.
"For now."

For now.

The CEO shook Oran's hand.
The VP of Manufacturing said: "See? We told you we'd cooperate."
The VP of QA was already asking about new fields for Phase 2.
The VP of Engineering wanted to know about the Q3 product line.

Oran opened his notebook.
He wrote the date.
He drew a line under Phase 1.
Below it, he wrote: Phase 2.
Below that: ?

He walked back to his desk.

On the production floor, he passed the QA station.
He passed the line supervisor's workstation.
He passed the shift handover desk.

On the shift handover desk,
open on the screen,
was a new Excel file.

It had three columns.
Someone had just started filling in the second row.

Oran looked at it for a moment.

Then he kept walking.

He had work to do.

The audit was passed.
The system was live.
The data was clean.

And somewhere in the factory,
someone had already started a new Excel file.

That wasn't a failure.
That was just the beginning of Phase 2.

What Oran learned — and what comes next

The EAV pattern solved the immediate problem.
But it introduced new ones that Oran hasn't solved yet:

The permission problem.
QA should not see Engineering's process parameters.
Engineering should not see QA's internal scoring.
The current system has no row-level permissions.
Everyone can query everything.
Oran knows exactly how to fix this.
He wrote a guide about it.
Nobody has read it yet.

The spec versioning problem.
attribute_definitions tracks when each key's meaning changed.
But querying "what did this batch comply with, at the time of production"
still requires careful joins that are easy to get wrong.

The real-time problem.
Everything is batch import. Every four hours.
Engineering wants live process data from the machines.
That's a stream. That's a different architecture.

The customer portal.
The big customer now wants direct access.
Not a report. A live portal. Their login. Their data only.
By end of Q3.

Oran opened his notebook to a fresh page.

Phase 2, he wrote.

Then he started a new list.

← Ep1: The Excel Republic
← Ep2: The Big Customer
← Ep3: The Auditor Arrives · Ep4 · Ep5*

Coding Cat Oran is a serialized fiction about building real production systems inside real companies.
The EAV schema is real. The gateway pattern is real. The Excel file on the handover desk is very, very real.
The cat is fictional. Phase 2 is not.

By SysLayer · dev.to/syslayer

Coding Cat Oran S2 Ep5 — The Many-to-Many Disaster

SysLayer — Fri, 15 May 2026 17:18:44 +0000

The report table is agreed. No one is responsible for it.
This is a different problem.

The table looked clean on the whiteboard.

Seventeen columns. One row per batch.
Every department's data, agreed, signed, version-numbered.

Oran had been looking at it for three days.
He had a document called Problems with this table.
It had eleven items in it now.
He was still finding more.

Problem 1: One batch, many inspections.

QA inspects at three stages: incoming material, in-process, and final.
Each stage produces a separate inspection record.
Each record has its own result, its own inspector, its own timestamp.

The current table has one row per batch.
One inspection_result column. One inspector_id. One inspected_at.

Which inspection result goes in the row?

Oran sent an email to QA.

QA replied: "Show the final result. That's the one that matters."

Oran replied: "What if the final result is pass but the in-process result was fail and there's no record of what corrective action was taken?"

QA did not reply for two days.
Then they replied: "That's a good point. We'll discuss internally."

Three days later: "Can you just add three columns? One per stage."

Oran looked at the table.
He added three columns.
He stared at them.

Product A has three inspection stages.
Product B has four.
Product C has two, but the second one is optional depending on customer requirements.
The new product line launching in Q3 has a stage that doesn't exist yet.

He deleted the three columns.
He opened a new file.

-- This cannot be one table.
-- This is at least two tables.

CREATE TABLE production_batches (
  batch_id     VARCHAR(50) PRIMARY KEY,
  product_code VARCHAR(50) NOT NULL,
  ...
);

CREATE TABLE inspection_results (
  result_id    BIGINT PRIMARY KEY,
  batch_id     VARCHAR(50) REFERENCES production_batches(batch_id),
  stage        VARCHAR(50),       -- 'incoming' / 'in_process' / 'final'
  result       VARCHAR(20),       -- 'pass' / 'fail' / 'conditional'
  inspector_id VARCHAR(50),
  inspected_at DATETIME,
  notes        TEXT
);

He sent this to QA.
QA said: "That looks more complicated."
Oran said: "It is more complicated. That's because the data is more complicated."
QA said: "Can we think about this after the audit?"

Problem 2: One material lot, many batches. One batch, many material lots.

This one took Oran a morning to find
and an afternoon to fully understand why it was a problem.

A production batch uses multiple raw materials.
Each raw material comes from a specific lot.
Each lot has its own supplier, its own incoming inspection record,
its own certificate of conformance.

For traceability — which is the entire point of this system —
you need to be able to answer: if a defect is found in the field,
which material lot might have caused it?

The current table has one column: material_lot_no.

One column, one lot.
Reality: three to seven lots per batch, depending on the product.

-- Also cannot be one table.
-- This is a junction table.

CREATE TABLE batch_material_lots (
  batch_id       VARCHAR(50) REFERENCES production_batches(batch_id),
  lot_no         VARCHAR(50) REFERENCES material_lots(lot_no),
  quantity_used  DECIMAL(10,3),
  unit           VARCHAR(20),
  PRIMARY KEY (batch_id, lot_no)
);

Oran sent this to Manufacturing.
Manufacturing said: "We don't track it that granularly."
Oran said: "The audit requires traceability to material lot level."
Manufacturing said: "We'll start tracking it."
Oran said: "When?"
Manufacturing said: "We'll discuss internally."

That was eight days ago.

Problem 3: The spec that changed.

This one Oran found by accident.

He was reviewing historical data to understand the migration scope
when he noticed that Product A's defect threshold
was different in the records from fourteen months ago
versus the records from six months ago.

He checked the spec document.
Current version: defect rate threshold 2.0%.
He went looking for the previous version.

It existed in an email chain.
Sent by the previous Engineering manager.
Who had left the company.
Eleven months ago.

Previous threshold: 3.5%.

Which means: batches that were compliant under the old spec
are non-compliant under the new spec.
And batches from the transition period —
when the spec changed but the system wasn't updated —
are recorded against the wrong threshold.

Compliant against which version?

-- The spec is not a column.
-- The spec is a table.
-- With versions.

CREATE TABLE product_specs (
  spec_id        BIGINT PRIMARY KEY,
  product_code   VARCHAR(50),
  version        VARCHAR(20),
  effective_from DATE,
  effective_to   DATE,          -- NULL means current
  defect_threshold DECIMAL(5,2),
  created_by     VARCHAR(50),
  notes          TEXT
);

-- And the inspection result needs to reference the spec version
-- that was in effect at the time of inspection.
-- Not the current spec.
-- The spec that existed on that date.

Oran sent this to Engineering.
Engineering said: "That's a lot of tables."
Oran said: "Yes."
Engineering said: "Can we just use the current spec for everything?"
Oran said: "Then the historical data is inaccurate."
Engineering said: "Is that a problem for the audit?"

Oran looked at his notebook.
He thought about Ms. Chen and her iPad.
He thought about the word traceability.

"Yes," he said. "It is a problem for the audit."

Engineering said: "We'll discuss internally."

The status meeting, Day 47.

The CEO asked for an update.

Oran presented the schema.
Not the whiteboard table. The real schema.
Six tables. Fourteen relationships. Three pages of documentation.

The VP of Manufacturing said:
"I thought we agreed on one table."

Oran said:
"We agreed on what data to capture.
The structure needed to change to capture it correctly."

The VP of QA said:
"Who is responsible for making sure the data gets into this system?"

The room looked at Oran.

Oran looked at his notebook.
He found the page from Day 1.
He read it out loud:

"Passive cooperation is not cooperation.
If a department does not submit data by the agreed date,
the project is blocked.
That is a management issue, not an IT issue."

He looked up.

"This was agreed. It was signed. The submission deadline for Production data was Day 40.
Today is Day 47. I have not received Production's historical data."

The VP of Manufacturing smiled.
"We've been very busy. We'll get it to you."

Oran wrote the date in his notebook.
He put a small star next to it.

A report that everyone agreed on
and no one was responsible for
is not a report.
It is a beautiful, shared, distributed lie.

The schema was right now.
The data was still in the drawers.
Day 47 of 90.

Next: Ep6 — The Abstract Table and the Gateway
Day 87. Three days before re-audit.
The departments are still in a meeting about column names.
Oran is in the server room with three tables and a whiteboard.

While everyone argued, IT built the thing anyway.
It wasn't perfect. It was enough.
For now.

← Ep1: The Excel Republic
← Ep2: The Big Customer
← Ep3: The Auditor Arrives Ep4*

Coding Cat Oran is a serialized fiction about building real production systems inside real companies.
The one-to-many relationships are real. The many-to-many relationships are real.
The spec that changed with no documentation is, unfortunately, extremely real.
The cat is fictional.

By SysLayer · dev.to/syslayer

Coding Cat Oran S2 Ep4 — The Voluntary Table

SysLayer — Fri, 15 May 2026 17:18:33 +0000

No department wanted to think about the whole picture.
Then they sat in a room with a deadline and no escape.
Oran said nothing. That was the point.

The CEO gave them a room, a whiteboard, and a deadline.

"Figure out what the audit report needs to contain.
You have until noon."

Then he left.

Four department heads. One Oran, in the corner, with a notebook.

Oran opened his notebook and wrote the date.
Then he put his pen down.
Then he waited.

It started the way these things always start.

Production spoke first.
They wanted the report to show output numbers.
Units produced. Units shipped. On-time delivery rate.
Numbers that make Production look like the engine of the company,
which it is,
which is also why they wanted to control which numbers appeared.

QA spoke second.
They wanted defect rates. Inspection pass/fail ratios.
Yield by product line. Corrective action response times.
Numbers that make QA look like the guardian of the company,
which it is,
which is also why they wanted to control which numbers appeared.

Engineering spoke third.
Process parameters. Spec compliance rates. Deviation reports.
Numbers that make Engineering look like the brain of the company,
which it is,
which is also why they wanted to control which numbers appeared.

Each department presented their version of the report.
Each version was a document that made their department look correct
and made it structurally impossible
to see anyone else's data in context.

For forty minutes, they argued.

Oran wrote in his notebook. He did not look up.

Then something happened.

Nobody remembers who said it.
This is important. This is why it worked.

Someone — it might have been QA, it might have been Engineering,
it definitely wasn't Manufacturing — said:

"What does the customer need to see?"

The room went quiet.

Not the hostile quiet of a meeting that's going badly.
The different quiet of a room that has just heard
the question it was supposed to be answering all along.

Slowly — without anyone declaring it,
without anyone taking credit for it,
without anyone formally proposing it —
they started building a table together.

What goes in each row.
One row per production batch.

What goes in each column.
Batch ID. Product code. Start time. End time. Shift.
Output quantity. Defect count. Defect type.
Process parameter: temperature. Process parameter: pressure.
Inspection result. Inspector ID. Inspection timestamp.
Material lot number. Material supplier.

What links the pieces together.
The batch ID appears in Manufacturing's records,
in QA's inspection log,
in Engineering's process data.
That's the key. That's always been the key.
Nobody had written it down before.

By 11:45, there was a proposal on the whiteboard.
One table. Every department's data. One shared structure.
Not perfect. Not complete.
But agreed.

Oran had filled three pages of notes.

He had said nothing.

After the meeting, the VP of Manufacturing stopped him in the hallway.

"You didn't say a single word in there."

Oran nodded.

"That was intentional, wasn't it."

It wasn't a question.

Oran thought about how to answer.

The honest answer was: yes.

Because Oran had learned something over two years of trying to get departments
to agree on data structures:

The moment IT proposes the schema,
it becomes IT's schema.
IT's problem. IT's fault when it's wrong.
IT's responsibility to defend in every meeting forever.

But if the departments build it —
if they argue their way to it,
if they write the column names on the whiteboard with their own hands —
it becomes their schema.
They own it.
They have to live with it.
They are much less likely to quietly ignore a system
they helped design.

The best system design meeting Oran ever attended
was the one where he didn't design anything.

He just made sure everyone was in the same room,
with the same deadline,
and no escape route.

That afternoon, Oran transcribed the whiteboard into a document.
He sent it to all four department heads with one line:

Please confirm this reflects the agreement from this morning's meeting.

Three confirmations came back within the hour.
The fourth came back the next morning,
with two small changes to column names
that didn't change anything structurally
but allowed the VP of Manufacturing to feel
that he had contributed.

Oran accepted both changes.
He updated the document.
He added a version number.

v1.0. Agreed. Dated.

Then he opened a new file and started writing the actual schema.

CREATE TABLE production_summary (
  batch_id           VARCHAR(50)  PRIMARY KEY,
  product_code       VARCHAR(50)  NOT NULL,
  line_id            VARCHAR(20)  NOT NULL,
  shift              VARCHAR(20)  NOT NULL,
  start_time         DATETIME     NOT NULL,
  end_time           DATETIME,
  output_qty         INT,
  defect_count       INT,
  defect_type        VARCHAR(100),
  process_temp       DECIMAL(6,2),
  process_pressure   DECIMAL(6,2),
  inspection_result  VARCHAR(20),
  inspector_id       VARCHAR(50),
  inspected_at       DATETIME,
  material_lot_no    VARCHAR(50),
  material_supplier  VARCHAR(100)
);

He looked at the table for a long time.

Then he opened a new document and wrote at the top:

Problems with this table.

And started listing them.

The best system design meeting Oran ever attended
was the one where he didn't design anything.
He just made sure everyone was in the same room
with the same deadline and no escape route.

The table they built had seventeen problems.
He would discover them one by one
over the next two weeks.
But it was their table.
And that mattered more than he could explain.

Next: Ep5 — The Many-to-Many Disaster
The report table is agreed. No one is responsible for it.
One batch. Multiple inspection results.
One material lot. Multiple batches.
One spec. Two versions. No migration plan.

Oran discovers that a table everyone agreed on
and no one is responsible for
is not a table.
It is a beautiful, shared, distributed lie.

← Ep1: The Excel Republic
← Ep2: The Big Customer
← Ep3: The Auditor Arrives

Coding Cat Oran is a serialized fiction about building real production systems inside real companies.
The politics are real. The whiteboard is real. The cat is fictional.
The VP of Manufacturing is, unfortunately, also real.

By SysLayer · dev.to/syslayer

Coding Cat Oran S2 Ep3 — The Auditor Arrives

SysLayer — Tue, 12 May 2026 03:48:43 +0000

She doesn't look at the machines.
She looks at the filing cabinets.

Her name is Ms. Chen.

She arrives at 9am with a rolling carry-on bag,
an iPad in a hard case,
and the specific kind of calm that belongs to people
who have seen this before.

Many times before.

The plant manager gives her a tour.
New equipment. Clean floors. Calibrated instruments.
He is proud of the production line.
He should be. It's good work.

Ms. Chen walks the line for two hours.
She says nothing.
She writes nothing on her iPad.

Then she turns to the plant manager and says:
"I'd like to see the production records. All of them. Going back eighteen months."

The plant manager smiles.
He has been preparing for this question.
He did not prepare for the answer to be complicated.

Here is what Ms. Chen finds:

The production floor: acceptable.
The equipment: calibrated, documented, within spec.
The documentation:

Batch records exist in three formats across four departments.
No single record contains the full picture of any batch.
To trace one production run from raw material to finished goods,
you would need to:

Find the batch number in Manufacturing's daily log (Excel, by shift, by month, one file per month, stored on the shift supervisor's PC)
Cross-reference with QA's inspection log (different Excel format, different batch number convention, stored on the QA lead's laptop)
Find the process parameters in Engineering's test folder (password protected; the VP is in a meeting)
Locate the material lot number in the incoming inspection binder (physical binder, shelf B3, organized by receipt date, not by lot number)

Ms. Chen does not do all of this.
She does enough of it to write, in the Notes field of her iPad:

Traceability: not demonstrated.

She meets with the CEO at 2pm.

She is direct. She is not unkind.

"Your production capability is real," she says.
"Your quality control process is real.
Your documentation system
is not a system.
It is hope organized into folders."

She opens her iPad and reads from the checklist:

Single source of truth for production data: Not met.
Traceability from raw material to finished goods: Not met.
Audit trail for process parameter changes: Not met.
Data stored in auditable, non-editable system: Not met.

"You have ninety days," she says.
"If these items are addressed at re-audit,
we proceed with the contract.
If not—"

She doesn't finish the sentence.
She doesn't need to.

The emergency meeting is Monday, 8am.
All senior managers. No exceptions.

The CEO does not raise his voice.
He doesn't need to.

He says: "Everything goes into a database. Oran is the project manager."

Then he looks at Oran.

Oran has been in this company for two years.
He has fixed the printers.
He has recovered someone's corrupted Excel file at 11pm.
He has set up the WiFi in the new warehouse.

He has never been a project manager.

He has also never wanted to be one.

But he has been taking notes since this meeting started,
and he has been thinking about this problem since the yield rate argument
three months ago,
and he knows — with the specific certainty that comes from
having already tried to do the thing the wrong way —
that there is no version of this that works
if IT just builds a database and waits for departments to fill it.

So before he says yes,
he stands up.

He writes three things on the whiteboard.

1. The timeline is IT's decision.

"The audit deadline is ninety days from today.
That does not mean the system is delivered in ninety days.
That means the system is delivered in whatever time it takes to build it correctly,
and the scope is defined by what can be done correctly,
not by what the deadline demands.
If the scope doesn't fit the timeline,
that is a conversation about scope.
Not about overtime."

The VP of Engineering shifts in his seat.

2. Resourcing is non-negotiable.

"I need two additional developers.
I need budget for tooling — database licenses, server infrastructure, testing environment.
I am one person. One person cannot build a traceability system for six product lines
in ninety days and also answer the help desk tickets
and also be in four status meetings a week."

The VP of Manufacturing starts to say something.
Oran continues.

3. Passive cooperation is not cooperation.

"Every department will have data submission deadlines.
If a department does not submit data by the agreed date,
the project is blocked.
That is documented as a management issue,
not an IT issue.
I will not absorb delays caused by other departments.
I will document them and escalate them."

He looks at the room.

"I want this in writing.
Signed.
Before the project starts."

The room is quiet for a moment.

Then the VP of QA says: "I think that's reasonable."
The VP of Engineering says nothing, which Oran writes down.
The VP of Manufacturing smiles — the specific smile of someone
who has already decided what they are going to do
and it is not what they are about to say —
and says: "Of course. We'll cooperate fully."

Oran writes that down too.
He writes the date next to it.
He puts a small star next to the VP of Manufacturing's name.

The CEO looks at Oran for a long moment.
Then he nods once.

"Ninety days," he says. "Make it work."

After the meeting, Oran walks back to his desk.
He opens his notebook to a fresh page.
At the top he writes:

Day 1.

Below it:

Things that are true:
— The system doesn't exist yet.
— The data is in twelve drawers.
— Three departments will say they're cooperating.
— Two of them mean it.
— The one who doesn't will be the most enthusiastic in every meeting.

He draws a line.

Below the line:

Things I can control:
— What I agree to.
— What I document.
— What I build.

He looks at that list for a while.

Then he opens his laptop and starts writing the schema.

The battle for the data hadn't started yet.
But Oran had just made sure that when it did,
he would not be the one who lost it alone.

Next: Ep4 — The Voluntary Table
No department wanted to think about the whole picture.
Then they sat in a room with a deadline and no escape.
Oran said nothing. That was the point.

← Ep1: The Excel Republic
← Ep2: The Big Customer

Coding Cat Oran is a serialized fiction about building real production systems inside real companies.
The audits are real. The ninety days are real. The cat is fictional.
The VP of Manufacturing is, unfortunately, also real.

By SysLayer · dev.to/syslayer

Coding Cat Oran S2 Ep2 — The Big Customer

SysLayer — Sun, 10 May 2026 11:09:28 +0000

The contract that changes everything is almost signed.
Every department says yes. Every department means no.

The CEO stands in the conference room holding a folder.

"If we land this account," he says,
"we run at 80% capacity for three years.
Stable revenue. Everyone keeps their job."

The room nods.

Oran counts the nods.
Twelve people. Twelve nods.

He writes in his notebook: zero commitments.

The customer is large. The kind of large that has its own supplier requirements document — forty-seven pages, updated quarterly, with a compliance checklist at the end that takes two people a week to fill out.

Page 31, Section 4.2:
All production data must be stored in a centralized, auditable system. Traceability from raw material intake to finished goods shipment is required. Excel-based record-keeping is not acceptable for Tier 1 suppliers.

The CEO reads this paragraph out loud.
Then he closes the document.

"All data goes into a shared system," he says. "Oran will build it."

The room nods again.

The meeting ends at 11am.

By noon:

QA has locked their defect log in the filing cabinet.
Engineering has added a password to their process parameters folder. The password is the VP's dog's name. Nobody else knows this yet.
Manufacturing's shift supervisor has started CC'ing nobody on the daily output report.

By 3pm, Oran sends an email to all three departments:
Please share your current data files so I can assess the migration scope.

By 5pm, he has received:

One reply from QA: "I already sent it to you last week."
No reply from Engineering.
One reply from Manufacturing: "Which data do you mean specifically?"

Oran checks his inbox. Nothing from QA last week.
He checks his spam. Nothing.
He replies to Manufacturing with a list of seven specific data types.
Manufacturing replies: "Let me check with my team."

That was Tuesday.
It is now Friday.

Here is what Oran understands, sitting at his desk at 6pm with an empty inbox:

Data hoarding is not laziness.
It's not incompetence.
It's rational.

Think about it from the VP of Manufacturing's perspective:

If Manufacturing's output numbers are the only output numbers, then when something goes wrong on the line, Manufacturing gets to define what went wrong. They control the investigation. They control the conclusion.

If the numbers go into a shared system, QA can query them. Engineering can query them. The CEO can query them. Manufacturing becomes readable instead of narrated.

That's terrifying if your department has anything to hide.
Even more terrifying if it doesn't — because then everyone else can see that too,
and use it to argue their own case.

Information asymmetry is job security.

Every Excel file in every drawer is a locked door.
Oran is being asked to remove all the doors.
Nobody wants that. Not really.

That weekend, Oran writes the first real schema draft.

Not the final one. Not even close.
But the first honest attempt to answer the question:
What data do we actually need, and who owns each piece of it?

CREATE TABLE production_batches (
  batch_id        VARCHAR(50) PRIMARY KEY,
  product_code    VARCHAR(50),
  start_time      DATETIME,
  end_time        DATETIME,
  shift           VARCHAR(20),
  line_id         VARCHAR(20)
);

CREATE TABLE inspection_results (
  result_id       BIGINT PRIMARY KEY,
  batch_id        VARCHAR(50) REFERENCES production_batches(batch_id),
  inspected_at    DATETIME,
  inspector_id    VARCHAR(50),
  defect_type     VARCHAR(100),  -- whose definition?
  defect_count    INT,
  outcome         VARCHAR(20)    -- pass / fail / conditional
);

He looks at defect_type VARCHAR(100) for a long time.

Then he adds a comment:

-- TODO: who decides what goes in this field?
-- QA: scratches are defects
-- Engineering: scratches are cosmetic unless functional
-- Manufacturing: scratches don't exist unless the customer notices them
-- Need one definition. Agreed in writing. Before we build anything.

He doesn't know it yet,
but that comment will take six weeks and three meetings to resolve.

Monday morning.

Oran arrives early. He prints two copies of the schema draft.
He puts one on the VP of QA's desk.
He puts one on the VP of Engineering's desk.

He slides a third copy under the VP of Manufacturing's door,
because the VP of Manufacturing is already in a meeting
that started at 7am
and will apparently last until noon.

Then he goes back to his desk and writes an email to the CEO:

The technical build is straightforward. The prerequisite is data governance — a written agreement on definitions, ownership, and submission timelines, signed by each department head. Without this, I can build the database, but I cannot guarantee the data inside it will be correct.

I'd like thirty minutes on the agenda for next week's leadership meeting.

He sends it before he can change his mind.

The company was about to get its biggest customer.
The data was in twelve drawers,
four password-protected folders,
and one Excel file that only opened on Linda's laptop.
Linda was on maternity leave.

The database didn't care.
It was waiting.

Next: Ep3 — The Auditor Arrives
She doesn't look at the machines.
She looks at the filing cabinets.

← Ep1: The Excel Republic

Coding Cat Oran is a serialized fiction about building real systems inside real companies.
The politics are real. The cat is fictional. The filing cabinets are very, very real.

By SysLayer · dev.to/syslayer

Coding Cat Oran S2 Ep1 — The Excel Republic

SysLayer — Sun, 10 May 2026 10:51:45 +0000

A story about trial production, three departments, and three versions of the truth.

It's 7am on the production floor.

Three people are standing around a whiteboard.
One is from QA. One is from Engineering. One is from Manufacturing.
They are arguing about a number.

The number is the yield rate for Product A, Batch 7, last Tuesday.

QA says: 87%.
Engineering says: 91%.
Manufacturing says: "Depends on which shift."

All three are holding laptops.
All three are looking at Excel files.
All three are right.

Oran is an orange cat. No CS degree.
He learned to code at night, online, on his own time,
with AI tools and courses he bought on sale.

He got hired anyway. It's that kind of year.

His job title is IT. His actual job is: whatever nobody else wants to do.

This week, his job is to reconcile the production data.

He sits down. He opens all three Excel files.

The columns have different names.
The formulas have different logic.
The defect definitions are different.
QA counts a scratch as a defect. Manufacturing counts it as cosmetic. Engineering doesn't count it at all unless it affects function.

Same scratch. Three categories. Three numbers.

Oran closes his laptop.
He stares at the ceiling for a long time.

Here is what Oran understands, sitting in that chair:

The data problem is not a data problem.

It's a political problem dressed as a data problem.

Each department's Excel file is their scoreboard.
Their evidence. Their alibi.
If QA's numbers are the official numbers, QA controls the narrative.
If Engineering's numbers are official, Engineering does.
If they merge into one system, someone's score gets worse.

Nobody built these spreadsheets to hide information.
They built them to protect themselves.
That's different. And it's harder to fix.

Oran opens a blank document.

He doesn't start with a database schema.
He doesn't start with a system architecture.
He starts with a question:

What would it mean for all three of these numbers to be correct at the same time?

He writes:

Inspection timing is different. QA measures at end-of-line. Engineering measures at each station. Manufacturing measures at shipment.
Defect scope is different. Three departments, three definitions, never written down anywhere.
The data is collected by different people, at different times, with different tools, for different audiences.

One batch. One production run. Six data points that look like contradictions but are actually just context.

The problem isn't that the data is wrong.
The problem is that there's no single place that holds all of it together.

That evening, Oran writes the first three lines of what will eventually become a database schema.

He doesn't know that yet.
He thinks he's just taking notes.

-- What actually happened
-- Who was there
-- When

He looks at the three Excel files one more time.

Then he writes a fourth line:

-- And what "defect" means in this context

There were three versions of the truth.
Everyone was lying. No one was wrong.
The database didn't exist yet.
But the problem did.

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 S1 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 S1 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 S1 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 S1 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 S1 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