Around 2400–2300 BC, the city of Ebla, in what is now northwestern Syria, kept one of the earliest large administrative archives known. When archaeologists excavated its royal palace in the 1970s, they found thousands of clay tablets and fragments recording trade, rations, textiles, metals, diplomatic correspondence, and word lists. The archive was not merely storage. It was the working memory of a state: who owed what, who received what, and on whose authority.
Ebla Labs is a software studio based in Idleb, not far from that site. The connection is more than a name. The problems Ebla's scribes solved are, in a very real sense, the problems we work on every week for clinics, traders, manufacturers, and public programs: recording transactions accurately, controlling who can see and change records, and keeping a trustworthy history of what happened.
Records are a model of the world
A ledger is a data model. Ebla's administrators had to decide what to record about a delivery of textiles: the quantity, the type, the recipient, the date, the official who authorized it. Leave out a field and the record cannot answer a question someone will inevitably ask later.
Modern software faces the same choice, only with tables and schemas instead of clay. When we design a data model, we start from the real entities and events of the business rather than from what is convenient for a framework or a screen. In practice that means:
- Model events, not just states. An invoice is "paid" because a payment happened. Storing the payment as its own record preserves who paid, when, and how much, instead of overwriting a status field.
- Name things the way the business does. If the warehouse says "dispatch note," the system should not call it "shipment_v2." Shared vocabulary reduces translation errors between people and code.
- Separate reference data from transactions. Customers, products, and price lists change slowly; orders and stock movements change constantly. Treating them differently keeps reports consistent over time.
Authority shapes access
In a palace economy, not everyone could issue goods from the storerooms. Who was allowed to act, and on what, was built into how the administration worked.
In business software, permissions are often bolted on at the end as a list of screens a user can open. We recommend the opposite: design access control alongside the data model. A permission should express a business rule, such as "a branch manager can approve refunds for their own branch up to a limit," rather than a technical one like "user can access /refunds." In our projects we design for:
- Roles that mirror real responsibilities, reviewed with the people who hold them.
- Scoping by organizational unit, so data is filtered by branch, department, or program before it reaches the screen.
- Separation of duties for sensitive actions, so the person who creates a payment is not the only person who can approve it.
Provenance is a feature
Administrative records of this kind note the goods, the quantities, and the people or places involved. That context is what turns a list of numbers into evidence.
Software needs the same property. An audit trail answers three questions about any important record: who changed it, when, and what it looked like before. We treat this as a core feature, not a compliance afterthought. Practical guidance we follow:
- Write audit entries in the same database transaction as the change, so the history cannot silently drift from the data.
- Store before-and-after values for sensitive fields, not just "record updated."
- Make the audit log append-only for application users, including administrators.
- Expose history in the interface, so operators can answer their own questions without filing a ticket.
Designing for longevity
The tablets of Ebla survived partly by accident: the palace burned, and the fire baked the clay hard. Software does not get that kind of luck. Systems outlive the frameworks used to build them, and data outlives the systems.
That is why we favor open, well-documented formats, explicit database migrations kept in version control, and export paths that let an organization take its data elsewhere. Whether we build on .NET, Laravel, or Next.js, the goal is the same: the records should remain understandable to whoever inherits them in ten years.
From stylus to schema
The tools have changed from reed stylus to TypeScript, from palace storerooms to Azure and AWS. The responsibility has not. Organizing operational knowledge so that people can act on it with confidence is an old craft, and we try to practice it with the same care.
Whenever we start an ERP, a document system, or an AI assistant, the same three questions come before any technology choice: What must be remembered? Who may see and change it? How will we prove what happened? Answer those well, and the decisions that follow become far easier.