How developers describe their work
Listen to how people in a real estate company talk about their day and one thing stands out: they describe their work by project. A CRM executive talks about the units left in Tower B. A store manager talks about the cement at one particular site. A director asks what a project has collected and what it has cost so far. The company has several departments, but the work itself is organised around projects.
A lot of business software is organised the other way — by department first. Sales has one system, purchase another, accounts a third. Each keeps its own list of projects, and the lists slowly drift apart. Joining them up becomes someone’s job at the end of every month.
One project, many modules
We built Proprite the other way round. The project is the top-level record. Towers, floors and units, rate and payment plans, bookings, purchase requirements, purchase orders, activities, inspections, indents, bills and petty cash all belong to a project.
Each department still has its own module, designed for the work it does. But every module reads from and writes to the same project. A confirmed booking produces the payment schedule that demand letters are built from. A shortfall at the store becomes a requirement in Purchase. A passed inspection lets the next activity start. Nobody re-enters what another team has already recorded.
Access follows the project
Organising around the project also answers a question every developer with more than one site faces: who should see what? In Proprite, staff are given access to specific projects, and their role decides what they can do inside each one. A site engineer on one development does not see the store of another. People who work across several projects use a project switcher to move between them.
This keeps each screen relevant to the person using it, and it keeps sensitive figures — collections, supplier rates, contractor ledgers — with the people responsible for them.
Shared record, separate responsibilities
Organising around the project does not mean everyone can change everything in it. Roles still separate the person who enters a transaction from the person who approves it. The store enters supplier bills and the purchase manager approves them. The site engineer records contractor work and the quantity manager approves it before it reaches the contractor ledger. The project is the shared record; roles decide who can change which part of it, and when.
Reports without assembly
The last benefit shows up in reporting. Because every team works in the same project record, MIS reports come from the transactions themselves — bookings, payments, activities, NMR, indents, purchase orders, bills and issued cash. There is no separate reporting spreadsheet to maintain, and reports respect the same project-level access as everything else.
Organising around the project is not a feature you can point to on a screen. It is the reason the other features connect, and it is why we describe Proprite as one connected system rather than ten separate tools.