Twelve apartments, twelve buyers, one register
In a multi-unit development every buyer wants something different — and every "I'd rather have oak than tiles" is worth thousands. Tabiquo gives every unit its own file and every variant a price, a status and a signature. What was agreed with whom stops being an email thread.
Why buyer variants end badly
The problem isn't the change: it's keeping track of it. The buyer asks the sales agent, the agent forwards it to the technical office, the office tells the foreman — and six months later the floor is the wrong one, the surcharge was never put in writing, and handover turns into a negotiation.
With several units running in parallel, memory doesn't scale: you need a register per unit. Every apartment has its variants, every variant has a description, a price and a path — requested, approved, applied — with a date on every step. The people building know what to do in which unit; the people selling know what was agreed with whom.
What you can do with Tabiquo
From the development's structure to the signature on each variant.
Units generated in bulk
Floors, staircases and numbers: the development's units are generated in series, codes composed automatically. Twelve apartments in a minute, not twelve files by hand.
Variants with a price
Every customisation request becomes a variant with a description and a cost, tied to its unit — and to the room, when it matters.
A tracked approval
Requested, approved, applied — or rejected. Every step is dated: you always know what was agreed and when.
The per-unit view
Open the unit and see its whole world: variants, status, documents. What belongs to A-2-1 lives in A-2-1.
Documents per variant
Renders, spec sheets, drawings: attachments live on the variant they belong to, not in a shared folder you have to guess through.
The buyer signs in the app
The variant with its price reaches the buyer in the app, and the approval goes on record. No more surcharges agreed out loud.
Who manages units with Tabiquo
Developers
Teams selling off-plan and delivering two years later, with every buyer changing their mind three times in between.
Builder-developers
Companies with a block under construction who must get the right change to the right apartment.
Technical offices
People translating buyer requests into work, who need to know what's approved before ordering.
Sales teams
People promising customisations who need the agreed price written down somewhere.
Why stop managing variants over email
An email doesn't know which unit it refers to, has no status, and gets nobody to sign.
-
Every variant belongs to a unit: no more changes applied to the wrong apartment.
-
The variant's price is written and approved before the work starts.
-
Statuses show what's agreed, what's pending, and what was rejected.
-
The site crew sees the approved variants for their unit, not corridor rumours.
-
At handover, the customisation history is a register, not a reconstruction.
Frequently asked questions
Is it worth it for a small block?
Yes: the value isn't in the unit count but in the register. Even with four apartments, variants with a written price and approval prevent the handover arguments.
Can buyers request variants on their own?
An invited buyer sees their unit in the app, and requests still go through you: you assess them, price them, and only after approval do they become work.
Do variants link to the estimate?
The unit variant tracks the customisation and its price towards the buyer. If it affects the works contract, you also record it as a financial change order on the project — the two registers stay coherent because they describe the same project.
How do you create fifty units without going mad?
With bulk generation: you set floors, staircases and units per floor, and the files create themselves with composed codes. Then you fix the exceptions, not the whole list.
Every buyer remembers the promise. Now you do too.
We'll show you the unit register on a real development, variants included. Thirty minutes, no strings.