Complete design, creation, and implementation of a commercial management add-on-package for Enterprise corporations.

Through discovery sessions with several clients, we quickly learned there was no such thing as a 'standard' pricing structure.

One client walked us through their pricing model for a single installation type. Rates varied depending on measured area, while separate rates applied when work was carried out at height. This immediately highlighted the complexity of the problem and made it clear that a rigid pricing model would fail to support real-world workflows.

Bolster already contained installation types, but they functioned primarily as simple labels used during documentation.

We needed a solution that could introduce entirely new capabilities while remaining backwards compatible with years of existing customer data.

During research, another pattern emerged.

Many companies did not use a single pricing structure across all projects. The same installation could be priced differently depending on the client, contract, or type of work being undertaken.

To support this, I proposed the concept of Installation Sets.

Rather than maintaining a single company-wide list of installation types, users could create multiple collections tailored to specific clients, contracts, or project types.

The concept also aligned with existing mental models already present in the platform, where manufacturer-provided installation libraries were grouped into folders. By extending this familiar pattern, we were able to introduce significant new functionality without introducing unnecessary complexity.

As research continued, it became clear that costing extended beyond installation rates alone.

To support these requirements, we redesigned the existing Pin Options area into a more scalable configuration system, allowing multiple categories of cost-related data to be managed through a consistent interface.

The final solution transformed installation types from simple documentation labels into configurable costing components.

Most importantly, the system provided the flexibility required by enterprise construction firms while preserving existing workflows and historical data for customers already using the platform.

Site workers place pins directly onto floorplans and complete management-defined templates to document work carried out on site.

Because Installed pins represented completed work, it was immediately clear that costing information should be generated from this data source.

Estimating, however, was far less straightforward.

Early project discussions treated estimating as a completely separate workflow.

The proposed solution required managers to review individual pins and manually create estimates based on the information recorded against each one.

As project scope expanded and development resources became constrained, estimating was ultimately removed from the roadmap and deferred to a future release.

While reviewing existing customer workflows, I identified an opportunity to achieve much of the same outcome without introducing a separate system.

Surveyors and supervisors were already using Action Required pins to document future work during site surveys.

In effect, the platform already contained a record of work that would need to be completed before installation teams arrived on site.

I proposed using Action Required pins as the foundation for estimating.

This enabled surveyors to generate projected values while allowing installation teams to record actual completed work using a separate pricing structure when necessary.

I presented the proposal to Bolster's leadership team and it immediately gained support due to its ability to deliver estimating functionality without introducing significant additional complexity.

Before implementation, we validated the approach with several existing clients, who confirmed it aligned closely with their existing operational processes.

Introducing Installation Sets required updates throughout the product ecosystem.

One challenge was ensuring workers only saw installation types relevant to the site they were working on.

To support this, we redesigned portions of the site creation and project hierarchy workflows, allowing managers to control which Installation Sets were available at different levels of a project.

A core objective throughout implementation was minimising disruption for field workers.

Many users interacted with Bolster exclusively through the mobile application, often while actively working on construction sites.

Rather than introducing significant workflow changes, we focused on enhancing the existing documentation process.

When users selected an installation type, the application dynamically presented only the measurement inputs required for that installation.

This reduced unnecessary data entry while ensuring costing calculations could be generated accurately from the information recorded on site.

By embedding costing and estimating directly into existing documentation workflows, we avoided creating parallel systems that users would need to learn and maintain.

The final solution allowed companies to move seamlessly from survey, to estimate, to installation, using workflows already familiar to their teams.

Rather than asking users to change how they worked, the platform adapted around processes they were already following, resulting in a solution that was both powerful and easy to adopt.

Construction projects often contain thousands of documented installations spread across multiple buildings, floors, drawings, and work packages.

By this stage of the project, Bolster was capable of calculating costs automatically from installation data, but simply displaying a total project value wasn't enough.

The challenge was transforming a large volume of operational data into something managers and directors could quickly understand and act upon.

The Costing Dashboard became the primary entry point into the Bolster Plus ecosystem and one of the most visible demonstrations of the product's value.

Because Bolster Plus represented a significant investment for customers, we wanted the experience to feel substantial while still remaining consistent with the existing product.

To support rapid iteration, we built extensive high-fidelity prototypes in Figma using reusable interactive components. This allowed us to explore multiple approaches while maintaining consistency across a growing feature set.

One challenge we repeatedly encountered was helping users understand how a total project cost had been calculated.

Costing data existed across multiple levels of a project's hierarchy, making it difficult to surface information in a way that was both detailed and easy to understand.

To address this, I introduced the concept of a Costing Cart.

Inspired by the familiar patterns of shopping carts and invoice breakdowns, the Costing Cart provided a clear summary of how project costs were constructed.

Rather than presenting users with a single total value, the cart grouped costs into meaningful categories and provided visibility into how different areas of a site contributed to the final figure.

Another key challenge was supporting the wide range of reporting requirements expressed during discovery.

Clients frequently needed to generate reports for specific areas of a site rather than entire projects.

To support this, I designed a hierarchical filtering system that mirrored the structure of the project itself.

This transformed report generation from a static export into an interactive workflow, giving users greater control over the data they shared externally.

As costing became more deeply integrated into the product, we also revisited Bolster's existing reporting functionality.

The report generation experience was updated to support costing information throughout the platform, ensuring that financial data could be surfaced alongside the operational documentation users were already familiar with.

The final dashboard transformed thousands of individual installation records into a clear, navigable source of business intelligence.

Rather than simply documenting work completed on site, users could now understand project value, analyse cost distribution, and generate client-ready reports directly from data already being captured within Bolster.

This completed the transition from a documentation platform to a system capable of supporting both operational and commercial decision-making.

Bolster already included a timesheets system that recorded when site workers clocked in and out using the mobile application.

However, the existing functionality focused primarily on attendance tracking rather than cost analysis.

With a major industry exhibition approaching, we needed to deliver a solution within a highly compressed timeframe while minimising disruption to existing workflows.

Through discussions with key customers, we discovered that labour costing was rarely as simple as applying a single hourly rate.

The challenge was creating a system flexible enough to support these variations without introducing excessive complexity.

To solve this, I helped define a new pay-rate framework.

Rather than assigning costs directly to individuals, administrators could create reusable pay-rate profiles representing common working arrangements within their organisation.

The system then combined these rules with existing clock-in and clock-out data to automatically calculate labour costs.

This allowed companies to begin understanding workforce expenditure without introducing additional work for site teams already using the platform.

To support the new labour-costing functionality, I redesigned key areas of the existing timesheets experience.

The previous interface focused primarily on attendance information and contained several components that delivered little operational value.

I restructured the experience around the information managers actually needed to make decisions.

By introducing approval states, companies could validate recorded hours before exporting them for payroll processing, creating a clearer connection between operational activity and workforce payments.

While working on labour tracking, I became increasingly interested in a related area of the product: Job References.

Job References already existed within Bolster and were used by workers when clocking into a project.

However, they functioned largely as administrative labels rather than meaningful operational entities.

Through discussions with customers, it became clear that many organisations operated across multiple sites that were, from a business perspective, part of the same project.

The existing site hierarchy model made this difficult because each site existed as an independent unit.

I proposed a longer-term vision where Job References evolved into project-level entities capable of grouping multiple sites together and becoming the central point for costing, estimating, labour, and reporting data.

While implementing such a fundamental architectural change was beyond the scope of the current release, the concept received strong support internally.

Although the broader project model was deferred, we took several steps to support future evolution.

These changes improved immediate usability while also laying groundwork for a future project-centric model.

Timesheets Plus transformed an existing attendance-tracking feature into a workforce cost management tool.

More importantly, the work uncovered broader opportunities within the product architecture and helped establish a foundation for future project-level reporting and profitability analysis.

The result was not only a new feature, but a clearer vision for how operational, financial, and workforce data could eventually converge into a single system.

Bolster Plus fundamentally expanded Bolster's role within customer organisations.

The release introduced a new commercial offering for Bolster and established the foundation for future financial and operational tooling within the platform.

While adoption varied across the customer base, feedback from customers using the feature was positive and generated further requests for enhancement and expansion.