Software built around the way your company already works

The symptoms that mean a package has run out

Nobody commissions custom software because they want to own a codebase. They commission it because a set of specific, repeating problems has become permanent. These are the ones that come up in almost every first conversation, described the way the people living with them describe them:

• The real system is a spreadsheet. The package holds the invoices, but the actual planning, the actual job list and the actual costing live in a workbook that one person maintains and everyone else emails around. When that person is on leave, the process stops.
• The same record is typed more than once. An order arrives, someone enters it into the sales system, someone else into the production list, and a third person into the dispatch sheet. Each pass is an opportunity for the three copies to disagree.
• No status question can be answered without a phone call. Where is this order, which technician has the part, has this purchase been approved, what did we actually spend on that job. The information exists, but only inside somebody's head or somebody's inbox.
• The exceptions are the business. The package handles the standard case. But the special pricing for one customer group, the two-stage approval above a threshold, the subcontracted operation in the middle of the route, the warranty rule that depends on installation date — those are the parts that make the company money, and they are the parts the package will not model.
• Every change is a quotation. Adding a field, changing an approval threshold or producing a different report goes into a queue and comes back as a consultancy line item, so people stop asking and go back to the spreadsheet.

One symptom on its own is not a case for building. Three or four of them together, on a process that runs every day, usually is. The arithmetic behind that judgement is set out in the real cost of manual work, and the long-run comparison in total cost of ownership: custom versus off-the-shelf.

What this page covers, and what it does not

This page is about operational systems: the software that runs work orders, inventory movement, field jobs, approvals, dealer orders, project progress and the reporting on top of them. It covers how such a system is designed, what is delivered, and what ownership means in practice.

It is not about replacing statutory accounting. Bookkeeping, tax filing and payroll are regulated, they change when legislation changes, and they are the same in every company in a given country. A package maintains that for you, more cheaply than any custom build can. Our default architecture leaves accounting where it is and connects to it — the mechanics are on integrations.

It is also not a description of one product. There is no KodDelta ERP that gets configured for you. Each system is built for the operation it runs, using an architecture and a set of patterns we have applied before. The systems we have delivered on that basis are listed on cases.

The architecture decisions that decide whether it works

Most custom projects that fail did not fail at the coding stage. They failed at four or five decisions taken in the first fortnight, usually without being written down. These are those decisions, and how we take them.

The data model comes before the screens

Before a single screen is drawn, we write down the entities — customer, site, asset, work order, operation, part, lot, contract, invoice — and the relationships between them, including the awkward ones. Does a work order belong to a site or to an asset? Can one job serve two contracts? What happens to the history when one customer record is merged into another? A screen built on a wrong entity relationship looks fine for six months and then fails at the first structural change. A correct model absorbs the change.

This is also where cardinality gets settled. The expensive cases are the many-to-many relationships people describe as if they were simple: one technician visit serving several jobs, one part serving two assemblies with different scrap allowances. Getting those wrong is what produces reports that never quite reconcile.

Roles and permissions are a matrix, not a dropdown

Companies describe permissions as job titles, and job titles are not permissions. A foreman may create work orders but not change prices. A regional manager may see every site in one region and none in another. A subcontractor may see their own jobs and nothing else. A finance user may see cost on every record and change none of it.

We write this as an explicit matrix: for each role, which records are visible, which fields are editable, which actions are permitted, and which need a second approval. Two distinctions do most of the work. The first is between read, write and approve. The second is between record-level scope, meaning which rows you can see at all, and field-level scope, meaning which columns within a row you can see or edit. A system with only the first ends up with every manager as an administrator, and at that point the audit trail is worthless.

The audit trail is a design decision, not a log file

An application log tells a developer what the server did. An audit trail tells the business who changed which value, from what to what, when, and from where. Those are different artefacts, and the second has to be designed in from the start.

The rule we apply: every record carrying money, commitment or evidence keeps its change history. A price change, an approval, a quantity correction, a status transition, a signature, a deletion. The history is written in the same database transaction as the change itself, so the two cannot drift apart, and it is readable by an authorised business user without a database client. This is what makes disputes resolvable — with a customer, with a supplier, or internally — and it is the feature clients most often discover they needed after the fact.

One source of truth per entity

In any company running more than one system, some records exist in two places. The customer list is in accounting and in the operational system. Stock is in the warehouse system and in the online store. The failure mode is not that data lives in two places; it is that both places consider themselves authoritative and quietly diverge.

So the source of truth is declared per entity, in writing, before code is written: products and price lists flow one way, stock movements and service invoices the other, and each side knows which fields it is allowed to originate. This single decision determines whether reconciliation is a monthly report or a monthly argument.

Status fields become state machines

A status column with eight possible values and no rules about which value may follow which will, within a year, hold records in impossible combinations: dispatched but not produced, invoiced but cancelled, closed with an open sub-task. Modelling status as a state machine — a defined set of states, the permitted transitions between them, and who may make each transition — removes that whole class of data corruption. It also gives you SLA clocks and escalation rules almost for free, because both are properties of transitions.

Where the system stops

The last decision is the boundary: what this system does not do, and which neighbouring system does it instead. Written down early it is a design; discovered late it is a change request. The usual boundaries are statutory accounting, payroll, CAD and product design data, and regulated filing.

Package or custom: the criteria that actually differentiate

When we tell you not to build

Custom software is the wrong answer more often than a software company is supposed to admit. These are the cases where we say so:

• A package already fits. If the process is genuinely standard and a package covers it, buying is cheaper and faster, and we integrate with it rather than replace it.
• The process has not settled. A workflow still being invented, due to be redesigned twice this year, should not be encoded yet. Encode it once it stabilises, or encode only the part that already has.
• Nobody owns the process. If no one internally can answer detailed questions about how the work is done today, and no one is accountable for deciding how it should be done tomorrow, the project has no counterpart and will drift.
• The volume does not justify it. A task done twice a month by one person is annoying, not expensive. Automate the fifty-times-a-week task first.
• Judgement work. Pricing a non-standard deal, assessing a thin credit file, handling an escalated complaint. Software can assemble the evidence; the decision stays with a person. The full boundary is on business process automation.

What is delivered

A working system is one deliverable. The rest of the handover is what makes ownership real, because ownership you cannot exercise is a clause rather than an asset. Each engagement delivers:

Ownership, stated plainly

Source code, database schema and intellectual property transfer to the client. The licence is perpetual and covers unlimited users, so adding warehouse staff, field technicians or external subcontractors does not change what you pay. Hosting is your choice: your own servers, or cloud infrastructure in a jurisdiction you select. Annual maintenance is optional at 12, 18 or 25 percent of build cost depending on response time and scope — optional meaning the system keeps running if you do not take it, not that support quietly ends.

The test of whether ownership is real is simple: could a different engineering team take this system over without us. That is why the document list above matters more than the contract wording. The argument in full is on source code ownership and vendor lock-in, and the packaged-software trade-off on package versus custom.

How a build starts

1. Discovery and written scope

   We walk the process with the people who run it, list the entities, the roles and the exceptions, and mark the boundary with existing systems. Output: a functional scope broken into milestones, each with a fixed price and an acceptance test.

2. Clickable prototype, 2–4 weeks

   Real screens, real navigation and the actual rules, before the main build is funded. Your team runs their own cases through it. A change at this stage costs a conversation; the same change after the build costs a milestone.

3. First production module, 2–4 weeks

   The highest-volume process goes live first, at $3,000–6,000 for a single focused module. It runs alongside the manual method until the outputs match, then replaces it. You have a measured result before the second decision.

4. Expansion on the same core

   The next department, an integration bridge, or an AI layer over documents the first module already collects. A multi-department system is $8,000–15,000 over 4–8 weeks; a full platform starts at $20,000 over 3–6 months. Each step is a separate decision with its own price. The bands are on pricing.

Operational variants of this approach are described on manufacturing, field service, dealer portal and project tracking. Systems we have built on it include Elevatora SAHA (lift maintenance and field service, multi-tenant), Elevatora İMALAT (lift-component manufacturing), SEMP Group (group-wide operations), SmartHukuk (legal technology) and PAP (pharmaceutical import and export process tracking).

Frequently Asked Questions