Cordango starts every workspace already knowing what a company is, what a person is, who reports to whom and who may see what. You bring the records. Nobody asks you to design the shape of them first, and no later app asks you again.
A new product does not know your company. It does not know that Globex is a customer and a supplier at the same time, that Lena reports to Tomas, or that the workshop crew are contractors rather than employees. So it asks you, and you answer, and now there are two answers.
That is the real cost of another subscription. Not the licence. The re-entry, the drift between the copies, and the integration project somebody eventually has to run to paper over both.
The mistake would be to make you define what a customer is before you can start. You should not have to. What every company has in common is already there on the first day, and the part that is genuinely particular to your business is the part you add.
Companies and people arrive as real records rather than empty tables. Legal identity, addresses, what a company is to you, group and subsidiary structure, the contacts inside it, a researched profile, your teams and reporting lines, who signs in and who may see what.
The things that exist only because of how you work. An opportunity, a project, a leave request, an expense claim, a piece of equipment, an invoice line. They arrive with the apps you add, they live in your workspace, and Cordango never promotes one company’s version of them into everyone else’s.
CRM, projects, time off, expenses. An app is a package of screens, rules and processes over concepts that already exist. It is the thing your team uses, and it is the least permanent of the three.
Apps come and go. The middle layer is where your company’s own model lives, and it survives the app that introduced it.
Nothing below is copied and nothing is synced. Each app adds what it needs to a company model that is already there, which is why the sixth app has almost nothing left to ask.
This is the part that is hard to believe until you watch it. Adding an app is mostly a conversation about what is new, because everything else has already been answered.
Companies, people, teams, reporting lines, relationships and the permission model. Not a copy of them. The real ones.
An expenses app needs an employee and a cost centre. It declares that rather than defining an employee of its own.
Employee resolves to the people already in the workspace. Nothing is created that already exists, and no second directory appears.
Claim, receipt, approval limit. Those are genuinely new concepts and they become part of your company model.
Which is a short list. Approval limits and who signs off, not who works here and what a team is.
The first app is where you answer questions about your company. The tenth is where you answer questions about one process.
| Extends | Other apps can use it | Universal in Cordango | |
|---|---|---|---|
| Opportunity | Organization | ✓ | ✗ |
| Project | Organization | ✓ | ✗ |
| Asset | Person, Project | ✓ | ✗ |
| Leave request | Person | ✓ | ✗ |
| Invoice | Organization | ✓ | ✗ |
| Person | – | ✓ | ✓ |
| Organization | – | ✓ | ✓ |
A concept introduced by one of your apps is available to the rest of your workspace and to nobody else’s. That is the difference between extending a company model and changing a product.
Underneath the friendly version there is a plain contract. An app declares the things it provides and the things it expects to find, which is what lets two apps built by two different people fit together without either knowing the other exists.
Somebody can ask for time off. Any app that needs to know whether a person is available can ask for it, without knowing which time-off app you installed.
A manager can decide. The approval chain comes from your reporting lines, so it is right on the first day.
Work can be opened against a company. Your invoicing app can create one without being part of the projects app.
The app expects people to exist. It does not bring its own list, and it will not start one.
The app expects companies to exist. It points at the record everything else points at.
Three time-off apps can all provide leave.request and leave.approve. Replace one with another and the staffing view that depends on it keeps working.
Installing business software normally means importing your people into it. That is where the second employee list comes from, and once there are two, one of them is quietly wrong within a month.
Here the app arrives with a list of what it needs and reconciles it against what your workspace already holds. Employee is not created, it is matched. The only thing added is the part that is genuinely new, which for a time-off app is a request and a type of absence.
It also means the app inherits your permission model instead of inventing one. Who may approve is already a question your workspace has an answer to.
These are the cases where separate products cost you a project, a subscription or a mistake, and where one company model costs you nothing.
Time off cancels the booked absence, projects surface the work that needs reassigning, assets flag the laptop that is still out, and access ends. In four products this is three integrations and a checklist somebody forgets to run.
The same organization carries the opportunity, the delivery, the hours logged and the invoice line. No customer is created twice, and nothing is synced between a CRM and an invoicing tool at four in the morning.
An approved absence changes who is available, which changes project staffing, which changes what sales can promise a customer. Between separate tools that chain is a spreadsheet, out of date by Tuesday.
None of these are features. They are what happens when the second app already knows what the first one learned.
This is not a feeling. Every app built in your workspace can show what it reused and what it introduced, which is the only honest way to argue that the platform gets cheaper the longer you run it.
The number to watch is the last line. How many questions did you have to answer this time. On the first app it is a real conversation about your company. By the fourth it is a conversation about one process, because the company part is already settled.
One company has employees and contractors. The next has agency staff, a works council and three legal entities under one holding. A third treats its franchisees as customers on Monday and partners on Friday. All three are correct.
That is exactly why the universal set stops at person, organization, relationship, identity and membership. Those five hold in every company we have looked at. Everything above them is yours to shape, and shaping it does not mean adding a field to a product other people use.
Change is part of the model rather than something the model resists. A concept can gain fields, carry a version, and come with a compatibility contract, so an app that depends on it keeps working while the definition moves underneath it.
A person can gain the attributes your company cares about without every other company gaining them too.
A change to a shared concept is a new version of it, not an edit that quietly reinterprets the rows already stored.
Every version that has ever shipped is replayed against the current one, so a field cannot be dropped in one version and come back with a different type in the next.
A rename is a migration rather than a fresh empty column, and an app that expected the old shape is told before it breaks.
The point of writing this down is that schema change is normal. A company model that cannot be changed is a company model that gets worked around.
The fastest way to see this is not a slide. Bring one company you deal with and one process that crosses two tools, and we will show you what the workspace already knows before either of them is built.
About 30 minutes, on a real workspace