Summary
KUBO supplies modular buildings for purchase and does not provide modular camp rental services. This guide is for rental-fleet owners, camp-service companies, dealers and similar operators that want to buy dormitory, office, sanitary, storage or support buildings from KUBO, add them to their own fleet, and then rent or deploy those assets to their own customers.
Effective modular camp rental fleet planning means standardising the repeatable building platform, asset families, connection positions, documentation and serviceable components without locking every purchased unit to one end customer’s requirements. The first order should satisfy an anchor project while remaining compatible with later projects wherever practical. KUBO can discuss detachable building configurations, controlled options, module identification, packing, spares and repeat-order compatibility around that purchasing objective.
The Procurement Decision: Buy a Reusable Fleet Platform, Not a One-Customer Camp
A project owner buying accommodation for one remote site can optimise a building package around that site’s immediate requirements. A rental-fleet owner has a different commercial problem.
The fleet buyer is purchasing capital assets that may later move to another project, serve a different customer, undergo inspection or refurbishment, and return to service in a different configuration. That changes the specification question from:
What camp should we build for this customer?
to:
What building families should we buy so the first customer can be served without making the fleet unnecessarily difficult to reuse for the next customer?
That is the core decision behind modular camp fleet procurement.
For a rental operator, standardisation should therefore focus on the parts of the building package that benefit from repeatability: the selected modular system, dimensional logic, compatible connection positions, controlled component families, module coding, documentation, inspection basis, packing assumptions and repeat-order reference.
Other requirements legitimately remain variable. Room occupancy, internal partitions, climate conditions, utilities, site foundations, local approvals and some shared facilities can change substantially between projects.
The practical target is not maximum uniformity. It is a controlled fleet architecture in which the operator knows which elements are fixed, which are selectable options, and which must be reviewed again before each deployment.
This distinction also keeps the commercial relationship clear. KUBO’s role is to manufacture and export modular buildings purchased by the fleet owner. The fleet owner then decides how those purchased assets are rented, allocated or deployed to its own customers.
Project owners seeking to rent a camp directly from KUBO, obtain local hire pricing or find a local rental provider are therefore outside the purchasing scope covered here.
What Should Be Standard Across Purchased Fleet Assets?
A strong fleet specification separates the controlled core from the project-variable layer.
The controlled core is where repeatability can simplify future purchasing, maintenance, packing, identification and compatibility checks. The variable layer is where customer, site or jurisdiction conditions can legitimately change.
| Specification area | Good candidate for fleet standardisation | Usually re-confirmed for each customer or project | Why the distinction matters |
|---|---|---|---|
| Building platform | Selected structural/module family, controlled external dimensions for the chosen configuration, common component philosophy | Projects requiring another building system, unusual footprint or significantly different operating condition | A common platform makes repeat purchasing and compatibility checking easier without forcing every project into one product type. |
| Asset families | A limited catalogue of repeatable dormitory, office and selected toilet, warehouse or support configurations | Unusual shared facilities or customer-specific functional buildings | The operator can manage a deliberate fleet instead of accumulating unrelated one-off designs. |
| Connection positions | Commonly planned interface locations where the selected configuration permits control | Actual utility sources, distribution design and local connection requirements | Repeatable connection planning can reduce unnecessary variation while preserving project-specific utility engineering. |
| Component strategy | Replaceable components, controlled spare-part identification and repeatable service items | Components changed because of climate, customer specification or a revised system | Serviceability is more useful when the operator knows which parts belong to which fleet standard. |
| Module identity | Module codes, product family and configuration records | Current customer, site assignment, refurbishment status and project-specific modifications | The fleet manager needs to know what each purchased asset actually is, not merely count total modules. |
| Internal layout | A small number of controlled dormitory or office layout families where commercially justified | Occupancy, partitions, furniture, privacy level and customer room standard | The building platform may remain compatible even when the internal use pattern changes. |
| Climate and MEP options | Predefined option families and documented interfaces where available | Climate, electrical conditions, HVAC duty, water and wastewater conditions | These variables can materially affect compatibility and should be rechecked for the next project. |
| Foundation and site interface | Defined information required before project release | Ground conditions, foundation design, levels, access and drainage | A reusable building still meets a different physical site every time it moves. |
| Approval documentation | Controlled manufacturer drawings, specifications and product records | Jurisdictional engineering review, permits and authority requirements | Factory consistency supports repeat orders, while site approval remains project-specific. |
The key procurement principle is that standard modular rental units do not need to be identical in every detail.
A better standard is a documented system with known compatible variants. If the rental company approves two dormitory layouts on one controlled platform, those can still belong to the same fleet standard. If electrical or climate options are intentionally identified and recorded, those options do not destroy standardisation either.
Problems begin when every customer order introduces another uncontrolled variation with no clear relationship to existing assets.
Buy a Complete Fleet of Building Functions, Not Only Bedrooms
Accommodation usually attracts the most attention because resident capacity is easy to count. A camp, however, operates as a group of functions rather than a collection of beds.
KUBO’s workforce camp planning approach considers functions that may include accommodation, kitchen and dining areas, toilets and showers, laundry, welfare spaces, clinic or isolation rooms, administration and utility interfaces. The required ratios are project-dependent, and peak demand can matter more than a daily average.
For a rental-fleet buyer, this raises a more useful portfolio question:
Which building functions should be purchased as reusable fleet assets, and which should remain more project-specific?
Dormitory buildings are an obvious fleet family when accommodation is a recurring part of the operator’s business. Offices can also be suitable repeat assets because different customers may need broadly similar workspaces even when internal arrangements change.
Selected toilet, warehouse, storage and support configurations may also fit a repeat-purchase strategy when their interfaces and use conditions are controlled carefully.
Shared facilities can be more variable. A large kitchen, dining building, welfare area or clinic may depend more heavily on resident count, shift structure, catering method, equipment schedule and utility demand. For those functions, the operator may choose to standardise the planning approach and interface requirements without freezing one universal building configuration.
This produces two useful layers in the purchased asset portfolio:
- Fleet-controlled building families: assets expected to move between projects with inspection, repair and limited controlled reconfiguration.
- Project-specific shared facilities: buildings or functional areas whose size, equipment or service model may need to be redesigned or re-selected for a particular customer.
The point is not to exclude shared facilities. It is to give each function the appropriate level of standardisation.
How KUBO Detachable Buildings Can Support a Purchased Rental Fleet
KUBO’s detachable container building system is relevant to rental-fleet procurement because its published scope includes contractor and fleet-owner use and detachable configurations for dormitory, office and toilet/warehouse applications.
For buyers purchasing fleet assets, the manufacturer-side discussion can cover the selected system and configuration, expected duty-cycle inputs, common grid and connection-position planning, replaceable components, module identification, inspection, spare-parts planning, protected packing, reassembly and recommissioning considerations.
Those controls become especially useful when the purchase is expected to support multiple later deployments rather than one permanent destination.
One published KUBO detachable configuration also shows why fleet specifications should remain configuration-specific. For that described configuration, KUBO publishes:
- external dimensions of 5950 ร 3000 ร 2800 mm;
- loading references of 17 units per 40HQ or 7 units per 20GP; and
- an assembly reference of approximately four workers and three hours for module assembly.
These figures apply to the described configuration rather than every possible KUBO detachable building. A customised or refurbished unit requires a new packing and execution review, and the module-assembly reference should not be interpreted as complete occupied-camp handover time.
For a fleet owner, that limitation is operationally important.
An asset register should not describe everything simply as “detachable camp module.” The operator should be able to identify the specific configuration, option family and relevant documentation attached to each purchased asset. Only then can it determine whether a returned unit is compatible with the next customer brief and whether previous packing or assembly assumptions still apply.
Test the First Purchase Against a Second Customer Before Order Release
The best time to discover that a fleet standard is too narrow is before the first purchase order.
A practical method is to test the proposed asset package against two different customer briefs.
The example below uses a hypothetical 72-resident construction camp as Customer A and a later hypothetical 96-resident remote project as Customer B. These figures are analytical assumptions only. They are not KUBO customer projects, quotations, market-demand claims or recommended universal camp sizes.
| Decision item | Customer A: hypothetical 72-resident anchor project | Customer B: hypothetical later 96-resident project | Fleet procurement conclusion |
|---|---|---|---|
| Dormitory requirement | Calculate required modules from 72 residents and Customer A’s approved occupancy variable bA | Calculate required modules from 96 residents and Customer B’s approved occupancy variable bB | Do not hard-code one universal beds-per-module assumption. Standardise the compatible platform and approved room-layout families. |
| Office buildings | Size from Customer A’s project team and workspace brief | Recalculate from Customer B’s organisation and workspace requirement | The office family may remain common even when quantity or interior arrangement changes. |
| Sanitary buildings | Determine quantity and arrangement from the first project’s resident profile, peak use and utilities | Recheck population, peak period, utility source and operating conditions | Do not convert the first customer’s sanitary ratio into a permanent fleet rule. |
| Climate package | Select for Customer A’s climate and operating condition | Review against the later project’s different climate | Treat climate-sensitive equipment as controlled options or re-release items. |
| Electrical and utilities | Design around Customer A’s connection conditions | Recheck source, distribution and local site conditions | Control interface information, but confirm actual site utilities before redeployment. |
| Shared facilities | Define around the 72-resident operating model | Re-size around 96 residents, shifts and service level | Some shared buildings may remain project-specific even when dormitory and office assets come from the standard fleet. |
| Reusable fleet core | Purchase repeatable dormitory, office and suitable support buildings for the anchor requirement | Check released assets from the first project against the second brief | Expansion should cover the compatibility shortfall rather than automatically duplicate the whole first camp. |
| New purchase trigger | Anchor requirement minus any compatible existing released assets | Later requirement minus released compatible assets after inspection and reconfiguration review | Expansion quantity should be based on usable released capacity rather than total owned count. |
The dormitory calculation can be expressed without inventing a universal occupancy figure:
Customer A required dormitory modules = ceiling(72 รท bA)
Customer B required dormitory modules = ceiling(96 รท bB)
Here, bA and bB represent the approved resident capacity of the selected room configuration for each customer.
If both customers accept the same room standard, the variables may be equal.
If one customer requires a different privacy level, internal partitioning or room arrangement, the values may differ even though the underlying building platform remains compatible.
This second-customer test is valuable because it exposes over-customisation before production begins.
If nearly every asset in the proposed first purchase would require substantial redesign before it could serve the second plausible customer, the fleet may be too closely tied to the anchor project.
If, by contrast, the platform, component strategy and most interfaces remain usable while only selected interior, climate or project-specific elements change, the purchasing strategy is closer to a reusable fleet model.
The First Purchase Should Already Define How Expansion Will Be Calculated
A rental operator should establish its expansion logic before the first order leaves the specification stage.
Otherwise, purchasing can become project-by-project: each new customer triggers another complete package even though some compatible assets already exist inside the fleet.
The most important distinction is:
Owned quantity is not the same as released reusable quantity.
A module may be legally owned by the operator but still be unavailable for the next project because it is:
- currently deployed to another customer;
- reserved for an upcoming project;
- returned but not yet inspected;
- waiting for repair;
- under refurbishment;
- being reconfigured; or
- incompatible with the next approved customer specification.
A more useful calculation for each building family is:
Released reusable quantity = owned quantity โ on-deployment quantity โ reserved quantity โ quantity awaiting inspection or repair โ quantity incompatible with the next approved configuration
The later purchase requirement becomes:
Expansion quantity = maximum of zero and (next-project required quantity โ released reusable compatible quantity)
That formula changes the procurement conversation.
Instead of saying, “We own 100 units and the next customer needs 120, so we should buy 20,” the fleet operator first establishes how many of the 100 units are actually released, serviceable and compatible.
The purchased expansion quantity is then calculated from the remaining shortfall.
Use a First-Order and Expansion Gate Before Every Repeat Purchase
A repeat-order process should connect operations, maintenance and procurement rather than allow those functions to work from separate counts.
| Gate | What the fleet owner checks | Release decision | Procurement effect |
|---|---|---|---|
| 1. Asset identity | Module code, building family, approved configuration and current records | Can this asset be evaluated against the new brief? | Prevents unlike configurations from being counted as interchangeable inventory. |
| 2. Commercial availability | Currently deployed, reserved, returned or unassigned | Is the asset genuinely available for the required project period? | Separates total ownership from usable availability. |
| 3. Post-deployment inspection | Physical condition after the previous project | Release, repair, replace components or hold | Prevents returned but unchecked assets from being counted as ready fleet. |
| 4. Configuration compatibility | Layout family, interfaces, relevant MEP/climate option and next customer’s brief | Reuse directly, reconfigure or exclude | Establishes the true compatible quantity. |
| 5. Packing and relocation review | Next transport route, packing status and any configuration changes | Reuse previous assumptions or create a revised plan | Customised or refurbished units may need a new packing review. |
| 6. Site release | Next location, assembly capability, foundations, utilities and project interfaces | Proceed with deployment planning or hold for missing inputs | Separates building compatibility from site readiness. |
| 7. Expansion calculation | Next-project requirement minus released reusable compatible quantity | Purchase the remaining shortfall by building family | Turns repeat buying into controlled fleet expansion rather than duplication of the previous project. |
This gate is especially useful when the fleet includes several generations of purchased assets.
Two units may look similar in an inventory list while differing in connection position, internal configuration, component revision or climate package. The gate forces those differences to be checked before the procurement team counts them against the next requirement.
Relocatable Camp Asset Management Begins With an Accurate Asset Register
A reusable building design alone does not create a reusable fleet.
The operator also needs lifecycle records that allow procurement, operations and maintenance teams to distinguish between assets that are owned, assets that are serviceable and assets that are genuinely ready for the next project.
A practical asset record should allow each purchased unit to be associated with:
- module code;
- product or building family;
- approved configuration;
- relevant drawing or specification revision;
- key replaceable components;
- inspection status;
- repair or refurbishment history;
- configuration changes;
- packing status; and
- current deployment or reservation status.
This is where manufacturer-controlled product information and fleet-owner lifecycle records meet.
KUBO can support the supplied building’s system/configuration documentation, module identification, inspection basis, spare-part planning and repeat-order discussion. The buyer then maintains the commercial and operational history of those assets throughout its own rental or deployment activities.
When a building returns from a customer’s project, the process should not move directly from returned to available.
A more controlled sequence is:
- Receive the building back into the fleet record.
- Confirm the asset identity and configuration actually returned.
- Complete the relevant post-deployment inspection.
- Record damage, missing components or items requiring replacement.
- Decide whether the unit remains in the same configuration or requires controlled refurbishment or reconfiguration.
- Confirm the next packing and relocation assumptions.
- Compare the released building against the next customer’s room, climate, utility and site brief.
- Count it as reusable capacity only after those checks are complete.
This record discipline also improves repeat purchasing from KUBO.
A request such as “we need another 30 units” does not tell the manufacturer what the new order must match.
A request linked to a known building family, option set and existing documentation gives a much clearer basis for checking repeat-order compatibility.
Standardise Deliberately Without Freezing Out Future Customers
The strongest fleet standard is not necessarily the one with the fewest configurations.
A rental-fleet owner may reasonably decide that one detachable platform supports two controlled dormitory layouts, several office arrangements or a limited set of climate options. Those variants can still belong to the same fleet architecture if they are intentionally defined and documented.
The important distinction is between controlled variation and accumulated customisation.
Controlled variation has a purpose. The buyer knows why the option exists, when it should be selected and how it relates to existing assets.
Accumulated customisation happens when one customer requests a change, the next customer requests another, and the fleet eventually contains many configurations that cannot easily be compared or combined.
The two-customer commonality test helps prevent this drift.
It also highlights which variables should not be permanently frozen into the fleet.
Occupancy is one example. A room arrangement accepted by one project should not automatically become the standard for every later customer.
Sanitary ratios are another. A 72-resident project’s toilet or shower configuration is not automatically correct for a later 96-resident project with different shifts or resident profiles.
Electrical supply, HVAC duty, utility sources, wastewater arrangements, site foundations and authority requirements can also change between deployments.
A repeatable building package should make those changes easier to manage, not pretend they do not exist.
Decide Which Shared Facilities Belong in the Purchased Fleet
Dormitory and office assets are relatively easy to think about as individual fleet units because their functions can often be described at building or module level.
Some shared facilities deserve a different procurement approach.
A kitchen and dining complex, clinic, welfare building or other communal facility may depend on:
- actual resident numbers;
- shift timing;
- catering model;
- foodservice equipment;
- peak-use demand;
- storage requirements;
- utility availability; and
- the customer’s operating procedures.
For those buildings, the fleet owner may decide to purchase selected repeatable elements while keeping final sizing and equipment scope project-specific.
This still supports a structured supplier relationship.
KUBO can review the required camp functions and discuss which detachable dormitory, office, sanitary, storage or support configurations fit the purchased fleet core and which shared facilities need their own project review.
That avoids forcing every function into the same level of standardisation.
For operators already dealing with assets that must be moved or reduced after a project, KUBO’s guidance on downsizing and relocating a project camp addresses that later-stage operational decision.
The procurement problem here occurs earlier: buying the fleet so that future reuse can be evaluated more systematically.
Define the Purchased Building Package and Local Project Interfaces Separately
Fleet procurement becomes clearer when the repeatable manufacturer scope and the changing project interfaces are identified before order release.
Through KUBO’s dealer and distributor partnership route, the manufacturer-side discussion can include:
- system and configuration review;
- building drawings and specifications;
- factory quotation and production coordination;
- packing and shipping documentation;
- spare-parts assumptions; and
- repeat-order compatibility.
The fleet owner controls the commercial asset strategy: target customer types, approved building families, allowable options, asset-status rules, inspection and maintenance processes, and the conditions that trigger the next purchase.
Each later project still needs its own site inputs. These can include foundation conditions, utility interfaces, local assembly arrangements, engineering review and applicable approval requirements.
Keeping those layers separate prevents two common procurement errors.
One is assuming that a repeat building automatically means a repeat site.
The other is allowing every new site condition to trigger unnecessary redesign of the purchased fleet asset itself.
The objective is to keep repeatable building features repeatable while treating genuine site differences as project interfaces.
What to Send KUBO Before Buying the First Fleet Batch
A rental-fleet buyer does not need to complete a full engineered camp package before starting the purchasing discussion.
A compact procurement brief is more useful if it shows both the first requirement and the intended reuse model.
Prepare:
- your company type and the customer or project sectors the fleet will serve;
- two representative customer briefs, or one anchor project plus the next likely project type;
- required building functions such as dormitory, office, sanitary, storage and support buildings;
- approximate resident or user ranges;
- expected relocation pattern, frequency or typical routes if known;
- known room-standard, climate or utility differences between target projects;
- your local assembly and maintenance capability; and
- any existing fleet configuration that a new purchase must match.
These inputs allow the discussion to move beyond a generic unit quotation.
KUBO can use them to review a purchased building package, identify which features should remain common across the fleet, define controlled options, review packing and spare-parts assumptions, and establish how a later repeat order should relate to the original batch.
Procurement FAQs
Does KUBO rent modular camps directly to project owners?
No. KUBO supplies modular buildings for purchase as a manufacturer and export supplier. The intended buyer for this fleet-planning approach is a rental-fleet owner, camp-service company, dealer, distributor or similar operator purchasing buildings for its own asset base. That buyer can then rent or deploy the purchased buildings to its own customers under its own commercial model.
Should every building we purchase for our rental fleet use the same internal layout?
No. The more useful objective is controlled compatibility rather than absolute uniformity. A fleet owner can standardise the building platform, component strategy, identification method and selected interfaces while maintaining several approved layouts. Occupancy, privacy, partitions and customer room requirements should still be checked against each new project before assets are released.
Can we use our total owned module count when deciding how many additional buildings to buy?
Not reliably. Repeat purchasing should use the quantity that is both released and compatible. Some owned assets may still be deployed, reserved, awaiting inspection, under repair or unsuitable for the next customer’s approved configuration. The expansion order should cover the shortfall remaining after usable released capacity has been confirmed.
Can KUBO’s published 5950 ร 3000 ร 2800 mm and container-loading references be applied to every fleet building we buy?
No. Those values relate to the specific published detachable configuration. KUBO lists 17 units per 40HQ or 7 units per 20GP and approximately four workers and three hours for module assembly for that described configuration. Customised or refurbished units require a new packing and execution review, and the module-assembly reference is not a complete occupied-camp handover time.
What information should we send before asking KUBO to quote a first fleet or expansion purchase?
Send your target customer or project types, two representative briefs where possible, required building functions, approximate resident range, expected relocation pattern, known climate or utility differences, and your local assembly and maintenance capability. If you already operate compatible assets, identify the configuration the next order needs to match. KUBO can then discuss the purchased building package, controlled options, packing and spares assumptions, and repeat-order compatibility.
Discuss Your Modular Fleet Purchase Plan
If your company is building a new rental fleet or expanding assets you already own, the most useful starting point is a concise procurement brief rather than a fully engineered camp package.
Prepare your target customer or project types, two representative briefsโor one anchor project plus the next likely projectโrequired building functions, approximate resident range, expected relocation pattern and local assembly/maintenance capability.
KUBO can use those inputs to discuss which detachable dormitory, office, sanitary, storage or support configurations should form the purchased fleet core, which requirements should remain controlled options or project-variable, how packing and spare-parts assumptions should be handled, and how future orders can remain compatible with the buildings already in your fleet.
Discuss Your Camp Fleet Supply Plan
Sources and References
- KUBO Detachable Container House โ detachable configurations, fleet-owner use, inspection, packing and reassembly references
- KUBO Workforce Camp Solutions โ accommodation, sanitary, welfare, administration and shared-facility planning
- KUBO Dealer and Distributor Partnership โ configuration review, documentation, quotation, production coordination and repeat-order support
- KUBO guidance on downsizing and relocating an existing project camp
