How we build

emko cloud is a small product with an unusually large surface. That only works if the decisions underneath it are made carefully and written down.

We decide once, and we record why

Every non-obvious modelling decision in emko cloud has a written record — what we chose, what we rejected, and what we're still unsure about. A few examples of the kind of thing that ends up there:

Currency belongs to a price list, not a price book. So one book can hold euros and dollars at the same time, and a company selling into two markets doesn't need two catalogues.
We removed machine-generated data from business records. A derived artefact that a model produced is not business data, and storing it next to business data blurs what a record means.
Money is a value with a currency, never a number. Floating-point money is a bug you find in an audit, years later.
A reference to another record is typed as that record. Not as text that happens to contain an identifier.

The open questions and unresolved contradictions are written down too. We would rather have a visible list of things we haven't settled than a tidy document that quietly papers over them.

The model comes first

The nine modules aren't nine codebases. Each record type is described once — its fields, its relationships, its ownership — and the working system is generated from that description: storage, operations, interfaces, tests.

That's why one small team can credibly run sales, orders, inventory, products, projects, hiring, learning and a marketplace as one product instead of nine.

It's also the extensibility story. A record type specific to your business is the same one-file operation as one of ours. No fork, no plugin API to outgrow, no "we'll consider it for the roadmap".

Boring where it counts

One process to run. No orchestration.
Standard interfaces, so your own tools can talk to it.
No hard deletes, so mistakes are recoverable.
Tenant isolation below the business logic, so a bug can't leak across it.

We spend our novelty budget on the domain model, which is where it pays, and nowhere else.

How it works · The assistant · Security and architecture · Pricing