Scaling From 300 to 400 Lockers: The Malta Expansion Without Downtime

Greenfield smart-locker deployments get most of the attention. The interesting engineering, in our experience, happens during expansions — when a site is already live, the operations team has built habits around the existing system, and you need to add capacity without breaking what works.

Last March we delivered exactly that on a high-rotation site in Malta: an additional 100 lockers added to an existing 300-locker installation, manufactured by our partner Inbeca in the same phenolic finish as the original batch, integrated into the live management portal without taking the site offline.

The brief: more capacity, same operator workflow

The client had been running our system in Malta for roughly two years before this expansion. Their original 300 lockers were deeply embedded in daily operations — shift staff knew the locker rooms, the back-office team knew the admin portal, and HR had built the locker assignment into their onboarding playbook. Anything we added had to fit that workflow, not replace it.

Three constraints set the scope of the project:

1. No service interruption. The site runs 24/7 with consistent high turnover. A multi-day shutdown was off the table — we needed staged installation that left the existing 300 lockers usable throughout.
2. Visual and material parity. New lockers had to look identical to the old ones. Same phenolic colour, same hardware, same door layout. Anything else would have been a visible "phase 2" patch instead of a clean expansion.
3. Single management surface. The admin team should never need to think about "old lockers" vs "new lockers". One portal, one assignment pool, one set of conditional rules.

What we installed

We delivered 100 new lockers in three days of staged installation, executed at the lowest-traffic hours of the day. Each phase carved off one row of existing lockers, slotted in the new units beside them, brought them online in the management portal, and handed the section back to operations before the next shift change.

Hardware specs matched the original phase exactly:

• Phenolic doors manufactured by Inbeca, same colour and thickness as the existing fleet
• Electronic locks rated for the same daily-opening volume as the original install (this site was already pushing 4,000+ daily openings before the expansion)
• PIN-code authentication, which the operator had standardised on for ease of staff onboarding

The software work was the real story

The physical install was three days. The software-side preparation that made it possible took longer — and is where most of the value to the client lived.

API-driven onboarding, with branded customer-facing emails. The client's HR system had already been wired to MyLock Cloud on the original 300 lockers via our REST API. Every new employee gets provisioned automatically: an assignment is created, a PIN is generated, and a welcome email is sent. What we did during the expansion was take the email templates the client had built up over two years and extend them — same logo, same tone, same locker-usage instructions — so the additional 100 lockers behaved identically from the user's perspective.

Automated expiration. A persistent operational issue on high-rotation sites is "orphaned" lockers — someone takes one and never releases it. We had configured automatic expiration after a set window of inactivity for the original 300; the new 100 inherited the same rule on day one. No manual cleanup queue.

Single management pool. The admin portal does not show "phase 1" and "phase 2" lockers. The 400 lockers are one assignable pool, with the same conditional rules applied uniformly. The expansion was visible in capacity metrics; it was invisible in workflow.

What expansions teach you

When we deliver a greenfield install, the success metric is "does the rollout meet spec." When we deliver an expansion, the success metric is "did anyone in operations notice." If the staff just saw 100 more doors one morning and assigned them like the previous 300, the project worked.

The two pre-requisites for expansion projects to go smoothly:

• The original install was built on an API that supports incremental capacity. Hard-coded locker counts, single-batch provisioning workflows, or tightly-coupled hardware/software pairings all turn an expansion into a re-deployment. The MyLock Cloud API treats lockers as a registry — adding rows is a configuration change, not a migration.
• The hardware partner can match the original spec months or years later. Phenolic from a different supplier, or a colour matched by eye, would have shown. Inbeca's ability to manufacture an exact-match second batch is why the install reads as one fleet.

If you are running a deployment that is bumping against capacity and want to plan an expansion without service interruption, get in touch — we will scope what a staged install looks like for your site.