Introduction
Picture a development of 24 dwellings spread across two cores and six floors. On paper it is one building: the same three-bedroom layout, the same standard kitchen, the same bathroom in every flat. The moment buyers start signing, that uniformity evaporates. The buyer on 2B wants an island kitchen, the one on 4A asks to swap the standard tile for porcelain across the whole living room, a couple on the ground floor wants two bedrooms knocked into one, and another buyer wants nothing changed at all. Suddenly the developer is no longer running one typical dwelling but 24 distinct homes, each with its own change list, its own extra cost, and its own approval status.
Where do most small developers end up tracking all this? A spreadsheet. One tab per floor, one column per buyer, colour-filled cells for approved versus pending. It works for the first few weeks and falls apart the moment a sales rep promises a change the site manager never sees, or when nobody can say whether the modification on 3C was priced before or after the contract was signed. The problem is not the spreadsheet. The problem is that the dwelling unit does not exist as a real object anywhere. In Tabiquo it does, and everything else — rooms, floor plans, incidents and buyer variants — hangs off it. Here is how to build that structure without burning an afternoon per core.
The mistake of treating a development as one project
Why a "type" dwelling is not enough
A repetitive residential development invites an obvious shortcut: define one dwelling and always work against it. The trouble is that the buyer does not buy the type, they buy their flat, and they want it different. If your tool only knows the overall project, every customization becomes a loose note living in the sales rep's inbox or in the architect's head. When the quantity surveyor walks the site to set out 5B, there is no single place to read what was changed in that specific flat.
That is why Tabiquo breaks the development down into real units. Each dwelling is a ProjectUnit object with its own structured identity: floor (level), core or staircase (staircase), door number (number), and a code composed automatically from those parts. Tell it floor 2, core B, door 6 and the system produces the code 2B6; with no core it joins floor and door with a dash so "1" and "1" read as "1-1" rather than the ambiguous "11". That code is the dwelling's number plate, and you use it everywhere: on the plans, on the incidents, and on the customization list.
The units layer switches itself on
You do not have to wrestle with settings to surface this layer. Tabiquo enables it automatically when the project type is multi-dwelling — a residential building or mixed use — and keeps it on whenever units already exist, as a safety valve against a misclassified project. A single-flat renovation is not cluttered with menus it does not need; a 24-dwelling development has them from day one. The admin panel then shows a Units entry inside the project navigation, alongside Planning, Documents and Incidents.
Standing up 24 dwellings in a minute, not an afternoon
The bulk generator
Creating 24 dwellings by hand, one at a time, is exactly the kind of repetitive chore nobody should be doing. The unit generator asks three things: how many floors the block has, which cores or staircases exist (you enter them as tags: A, B), and how many dwellings sit in each group per floor. It multiplies those out and shows a live count before you confirm: 6 floors × 2 cores × 2 dwellings = 24 units. Hit generate and all 24 are created with their code, floor and core already assigned.
You choose the numbering to match how the dwellings are actually identified in that development. There are three modes: per floor (the counter resets on each floor, the classic "1A, 1B, 2A, 2B"), per staircase (the counter runs across all the floors of the same core), or progressive (a single run from 1 to 24 for the whole building). The generator is additive, never destructive: if one core has a penthouse with a special layout, you generate the homogeneous block first and then add that one-off unit without the system touching or renumbering what already exists, because it skips any code already taken.
Rooms, once and for all
Twenty-four empty units solve nothing; each dwelling needs its rooms. This is where most tools make you repeat the same work 24 times. Tabiquo offers two paths depending on the moment. If you have just generated the block and no dwelling has rooms yet, you use apply rooms to all units: define the list once — living room 22 m², kitchen 9 m², master bedroom 14 m², bathroom 4 m² — and it is created in one shot across every selected dwelling, with a toggle to limit it to the empty ones so nothing is duplicated.
The second path is clone rooms from a dwelling you have already configured. Set up the "type flat" carefully — including width, length, height, floor finish, ceiling type and skirting — and copy that configuration to every other dwelling that has no rooms yet. That is the difference between standing up a repetitive building in a minute or going flat by flat. To guide you, the units table itself suggests this pattern whenever any dwelling still has no rooms, and when the project starts empty it shows a guided empty state spelling out the three-step flow with a button that drops you straight into the generator.
Variants: the heart of customization
One variant per change, with its status and cost
Here is the core of the problem that destroys spreadsheets. Every change a buyer requests is recorded in Tabiquo as a variant (UnitVariant) attached to their dwelling and, optionally, to a specific room inside it. The variant carries a title, a description, a cost and a status that follows a clear flow: requested → approved → applied, with rejected as the exit when a change cannot go ahead. Each transition stamps its own timestamp: when it was requested, when it was approved, when it was executed on site.
Take that 4A buyer who wanted porcelain in the living room. You create a variant titled "Swap standard tile for porcelain in living room", attach it to that dwelling's living room, set a cost of €1,200 and leave it as requested. When the buyer signs off on the upgrade, you move it to approved and the system records who approved it. When the tiler executes it, you mark it applied. At no point does that change live as a loose note: it is glued to the dwelling, to the room, with its amount and its full trail. And if the buyer attaches a quote from their own kitchen supplier or a reference photo, those files hang off the variant itself.
Traceability with no effort
Developments breed arguments months later: "was this approved before the contract?", "who said yes to merging the bedrooms?". Both units and variants carry an automatic activity log that records the meaningful changes — title, status, cost, description — with author and date. It is not a feature you have to switch on or feed: every time someone moves a variant from requested to approved, it is written down. When the awkward question lands six months later, the answer is in that dwelling's history, not in anyone's memory.
Everything else hangs off the unit
Plans, rooms and incidents per dwelling
The unit is not just a card with customizations on it: it is the anchor for all of that flat's documentation. Rooms link to their unit, project floor plans can be tagged to a specific dwelling when you upload them, and incidents are tied to their unit through the same field. This matters on site. When the site manager opens a damp incident in the 2B bathroom, they bind it to that dwelling. Later, reviewing 2B for handover, they see at a glance all of its incidents, rooms and plans without filtering through the hundreds of records across the whole building.
Tabiquo's floor-plan viewer already lets you pin incidents onto the plan with a severity-coloured dot. In a development, that plan can belong to a specific dwelling, so the pin is doubly located: on the plan and on the unit. So that floors line up between units and plans, the floor field shares the same autocomplete in both places — you do not end up with a "3" on the units and a "Floor 3" on the plans that the system never connects.
From the office to the site: web and app
The units layer does not stay locked in the admin panel. The developer manages from the desktop — generating the block, cloning rooms, approving variants — while the site team consults from the mobile app. The API exposes a project's units, their creation and editing, and even the bulk generator itself, alongside the full variant lifecycle with its status changes. The buyer or client, depending on permissions, can view the dwellings too. Each unit travels with its room and variant counters, so on the project summary a widget shows the grid of dwellings with how many rooms and how many customizations each one carries. At a glance you know 2B has racked up five variants and 5A none.
Conclusion
Managing a development is not managing a building: it is managing many dwellings that share a common origin but diverge the instant the buyer arrives. The spreadsheet fails because it treats that common origin as reality and leaves the differences — the customizations, the extra costs, the approvals — as notes in the margin. Tabiquo flips it around: each dwelling is a real object with its code, its rooms, its plans and its incidents, and every buyer change is a variant with a status, a cost and a trail. You generate all 24 units in a minute, clone the type-flat configuration, and from there each dwelling carries its own story without you rebuilding it by hand. When handover comes, you do not dig through six Excel tabs — you open the dwelling and it is all there.
Tabiquo is the web platform and mobile app built for architecture studios and small developers who run real construction. If your next development is more dwellings that look identical on paper and turn out different in practice, stop fighting spreadsheets and give each unit the place it deserves inside the project.