Development of a construction company portal: inventory grid and buyer's personal account
Sales in a residential complex break not on advertising but on data consistency.
The developer's inventory grid goes out as an email attachment, a reservation is confirmed in a messenger, mortgage statuses live in correspondence with the bank — and two managers sell the same unit at the same time.
The result is double sales, canceled reservations, and error analysis after the deposit has already been paid.
Apartment reservation accounting in the portal is locking a unit for the approval period with automatic release upon expiration.
Every action is logged: who, when, and on what grounds changed the status, and the inventory grid is assembled from a single database rather than diverged spreadsheet copies. A released unit returns to sale automatically, without manual reconciliations.
The buyer's personal account relieves part of the load from the sales department: mortgage statuses, payment schedule, documents, and construction progress are visible without a call.
A person sees at what stage their bank application is and does not bother the manager at every stage of the deal.
Development of a construction company portal starts with a data model: buildings, sections, floors, units, shares, and encumbrances — plus roles where the manager, bank, and buyer see different things.
Then integrations: bank mortgage statuses, document signing, exports to the developer's accounting system.
Next, we will break down what such a portal is assembled from and exactly where the sales department's time is freed up.
A unified portal instead of spreadsheets: what changes for the sales department
Before the portal, placing a reservation went through correspondence: a manager checked available units with one department, coordinated terms with another, and manually entered the record into a shared spreadsheet.
At every step, a colleague could intercept the reservation, and the buyer waited hours for an answer. In a unified environment, a reservation is placed directly from the property card within minutes: a free unit is locked immediately and becomes unavailable to other managers.
Manual reconciliations between departments are closed because there is a single data source.
Apartment status changes at the moment of the deal and is simultaneously visible to sales, the legal department, and accounting — there is no longer any need to export and compare spreadsheets, and discrepancies do not accumulate by month-end.
The share of status errors falls because transitions are restricted by rules: you cannot mark a reserved unit as "sold," you cannot cancel a reservation without grounds, and you cannot leave a contradictory state. The system does not allow a conflict, so the status in the portal always matches the actual one.
The speed of response to the buyer no longer depends on the manager's workload. The personal account shows the stage of work, the state of documents and payments, and typical questions — mortgage, handover dates, acceptance — are resolved without calling the sales department.
In sum, this is the unified sales environment: one property card, one status, one action history for each apartment. The manager sees inventory and workload in real time, while the salesperson spends time on the client rather than on coordinating data between departments.
Implementation options: platform, customization, custom build
The choice between a ready-made sales platform, customization of the current system, and individual development is determined not by the set of screens but by the portal's growth boundaries.
The key factor is integration with the developer's sales accounting and CRM: exchanging reservation statuses, escrow, and payment schedules accounts for most of the effort.
Therefore, portal implementation options are compared by implementation time, freedom in non-standard scenarios, and support scope.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made sales platform | Standard processes, need to launch the inventory grid and personal account within a short time | Reservation and installment logic is set by the vendor; non-standard payment schemes and bank exchange have to be worked around; part of the data lives outside your environment |
| Customization of an existing system | The website already maintains a catalog and requests, need to add statuses and a personal account | The data schema for new roles often has to be rebuilt; legacy code and lack of tests make every change more expensive |
| Individual development | Multiple legal entities, non-standard sales schemes, strict access requirements | The first working version is released later; you need your own release process and support team |
Standard processes — we take a ready-made sales platform: the inventory grid and buyer's personal account appear within a short time. Customization is justified when the system already manages the catalog and deals.
A custom build is needed if a non-standard payment scheme or access differentiation becomes the core of the portal rather than a detail.
Phased implementation: from process audit to handover
The work order is structured so that risks surface during design rather than on launch day. Each stage ends with an artifact that can be verified; we move to the next one after its acceptance.
-
Sales process audit. We analyze how reservations, contracts, and mortgage applications currently live: who changes a unit's status, where data comes from, and where figures diverge in reports. The output is a process map, bottlenecks, and a list of sources.
-
Data schema and roles. We design a unified model: property → building → section → floor → unit, a status reference, and transition rules between them.
We describe roles with an access matrix — separately for the manager, mortgage specialist, and buyer; every status change is logged.
-
Reservation history migration. We reconcile exports with current registries, merge duplicates, and map old statuses to new ones. Control is by the number of units in each building: discrepancies are resolved before loading.
-
Portal and integration setup. We connect mortgage application intake, payment statuses, notifications to the buyer in the personal account, and exports for reporting.
-
Acceptance checks. We run scenarios on a copy of real data: simultaneous reservation of one unit by two managers, cancellation, the mortgage deal path from application to registration, and inventory grid recalculation. Separately, we look at interface behavior across the full volume of buildings.
-
Handover and training. We provide documentation, regulations, and access, train by role, and document the support and change request procedure.
Access policies, data schemas, and handover regulations
The portal lives longer than any development team. So that a change of contractor does not turn into reconstructing logic from code, we record the rules in documents and hand them over together with access.
- Role matrix. Who sees the inventory grid in full, who sees only their own building, who works with contracts, and who works with mortgage applications; for each role, a set of permitted actions.
- Access policies. Visibility rules by property: the sales department does not export the buyer database, and the contractor sees a unit's status without personal data.
- Data schema description. Entities — property, building, unit, contract, buyer, payment — their relationships and status change history. It allows the structure to be restored without analyzing code.
- Exchange regulations with partner banks. What data is sent for mortgage approval, which fields are mandatory, who on the developer's side confirms the export, and how a bank refusal is handled.
- Support regulations. Update window, release rollback procedure, backup points, incident response, and responsible parties on both sides.
- Employee guides for standard operations: reservation, status change, extension, and report export for the sales department.
Before handover, we go through the list together with your team: we show where the documents are, how to use them, and what is updated with each system change. Describing the sections is not a formality but insurance against dependence on a single contractor.
Case study: developer's inventory grid — metrics before and after launch
Initial state: inventory grid in files and manual reconciliations
Sales were conducted in several spreadsheets: an inventory grid by building, a separate reservation registry, and correspondence with mortgage managers.
A unit's status was changed in one file, and it did not always reach the others — managers called each other to find out whether an apartment was available. Status reconciliation took 5–6 hours a day, and discrepancies surfaced after the contract was signed.
The buyer learned the status only by calling the office: whether the participation agreement was ready for registration, whether the mortgage was approved, which documents to bring.
Each call occupied a manager and left no trace in the system — when the responsible person changed, the deal context was lost.
What was redesigned
The unified inventory grid became the source of truth: a unit's status changes in a single transaction, a reservation places a lock, and release returns the apartment to sale without manual editing.
The buyer's account now shows deal stages, the registration status of the participation agreement, and the progress of the mortgage application — instead of calls to the office.
Property data was synchronized with наш.дом.рф: project declarations and photo reports are pulled automatically, and manual entry for them was removed.
Metrics before and after
Status reconciliation decreased from 5–6 hours to 15–20 minutes a day, and the share of manual operations per deal fell by about three times.
Double reservations disappeared as a category: a lock on a unit prevents two managers from selling the same apartment at the same time, and the change history shows who canceled a reservation and when.
About 70% of buyer inquiries moved to the account, the office workload decreased, and the deal time shortened because the mortgage status is visible to both parties without intermediate calls.
How does a proprietary inventory grid differ from integration with a sales system?
The key question is who owns the truth about a unit's status.
If the portal stores the inventory grid itself, you set the reservation rules: queue, hold period, auto-release, status change history — according to your own regulations, without waiting for modifications from an external vendor.
If the truth lives in an external sales system, launch is faster and there is less of your own code, but any reservation logic runs into the capabilities of someone else's system.
Double entry appears where status is changed in two places.
A manager places a reservation in the accounting environment, while the portal keeps its own log — at peak demand this produces discrepancies: two buyers see the same unit as available, and payment arrives for a canceled reservation.
The cure is not manual reconciliation but the single-writer rule: one environment writes, the other reads.
| Option | When it fits | Limitations |
|---|---|---|
| Proprietary inventory grid in the portal | Multiple sales channels, flexible reservation rules, real-time buyer account | Data integrity and linkage with accounting are on us |
| Exchange with an external sales system | Sales already live in 1C, reservation rules are standard | Reservation logic is limited by someone else's interface |
| Two environments | Accounting manages deals and payments, the portal manages the storefront and account | Need protection against repeated event delivery and nightly reconciliation |
A hybrid is in demand most often: deals, payments, and mortgage statuses remain in the accounting environment, while the portal holds a fast projection for the inventory grid and personal account.
We build the exchange on events, with protection against duplicates and nightly reconciliation of balances — a short communication failure then does not turn into a unit sold twice.
The choice is dictated by the number of simultaneous reservations, the number of sales channels, and the required response speed of the inventory grid. We break down how this determines the portal architecture.
Frequently asked questions about the inventory grid, reservations, and the buyer's personal account
The inventory grid, reservations, and the buyer's personal account are one transactional system, not three screens: apartment status changes atomically, and every change stores its source and time.
Engineering doubts before launch concern not interfaces but integrations — exchange with banks, exports, rights, and behavior under load.
Below is what we check and show the client before work begins.
How are mortgage statuses synchronized?
Confirmations are fetched on a schedule and supplemented by the change log: the application stores the current stage, source, and time.
Discrepancies are not overwritten automatically — they go to manual confirmation, so the inventory grid will not show an apartment as sold before the contract.
How are exports to external systems structured?
The exchange runs through a separate read layer: reporting jobs do not block sales at the moment of reservation. Re-running an export does not create duplicates, and discrepancies with the external system are visible in reconciliation.
What happens to data when the contractor changes?
We hand over the database with its structure and history, files, environment settings, and a description of exchange formats. Acceptance is by checksums and a test run: the new team reconciles the inventory grid before switching.
How are employee rights differentiated?
Roles are built by area of responsibility, not by job title: a manager sees only reservations for their own buildings, and the mortgage department sees deal stages without personal data. All actions are written to an immutable log.
Will the system withstand sales launch day?
The inventory grid is read from an intermediate layer, and the lock is placed at the row level — two reservations for one apartment are impossible. Before launch, we run a load profile with a response time margin.
Let's discuss the task: timeline estimate and work plan for your project
For the development timeline estimate to be a working figure rather than a guess, we need inputs: roles in the portal (buyer, sales manager, lawyer), mandatory first-phase blocks — the inventory grid and the buyer's personal account, and external systems for exchange.
In response, you receive not just one figure but a breakdown by stages with assumptions and risks. What the project work plan will include:
- stage scheme: from inventory grid prototype to production operation, with the duration of each stage and acceptance points;
- scope of work: property data analytics, interface design, development, integrations, load testing, handover to support;
- development timeline estimate in calendar days — separately for our part and for external contractors (bank, sales department);
- sequencing options: personal account and inventory grid first, mortgage scenarios as the second release;
- team composition and working mode: showing working builds every two weeks, a shared task list, and a test bench for your specialists;
- list of inputs missing for an accurate estimate and what each affects;
- acceptance procedure: which checks we consider mandatory before going live.
Send us the task description — we will return with a timeline estimate and project work plan, then a call and fixation of the stage scheme.
