Summary
Building Services Toolbox was an iOS app that provided transparent calculation tools for building services engineers. I built it as a consultant mechanical engineer whilst learning Swift, grew it to global adoption across the industry, and it was shortlisted as a finalist in the CIBSE Digital Engineering Awards 2018 for Best Innovation.
The project demonstrated solving a real professional problem through software: identifying a genuine workflow inefficiency, building a mobile application with transparent methodologies, and scaling adoption organically through word of mouth. I handled everything from engineering research to iOS development to user support, maintaining the platform single-handedly whilst working full-time as a building services engineer and later as a software developer.
The app focused on core mechanical engineering calculations: duct sizing, pipe sizing, simultaneous demand, and daylight assessments. The offline-first architecture and transparent formulae were critical for engineers needing reliable calculations on construction sites. The app was used globally by everyone from consultancy directors to apprentice plumbers, validating the value of domain-specific tools built by practitioners who understand the actual work.
Engineering Calculations in the Field
Building services engineers spend time on construction sites, in design meetings, and doing back-of-the-envelope calculations to validate feasibility or check rough numbers. As a consultant mechanical engineer, I found myself doing the same rough calculations again and again whilst carrying out site inspections or attending design team meetings.
During early stage design team meetings, preliminary sizes for service routes and risers were frequently required. Instead of trying to do rough calculations by hand, having an app to size pipes and ducts quickly meant I could provide immediate feedback on space requirements.
On site, the need was even more acute. If a contractor highlighted a duct clash, I could resize the ductwork with equivalent area on the spot to avoid the obstruction. This ability to quickly redesign meant issues could be resolved immediately, rather than having to say "I'll check that when I'm back at the office and get back to you."
Designing for Clarity and Transparency
I had previous experience with other software tools for building services calculations. However, the majority of them were presented as a "black box". You put in some data and it spits the answer back out. You have no idea what's happening under the hood, which is enough to make any engineer uncomfortable.
The core philosophy behind Building Services Toolbox was transparency over black-box automation. Every calculation in the app exposes the underlying formula, shows intermediate steps, and cites the reference methodology. Users can see exactly what's happening. This served two purposes: it built confidence in the results, and it helped junior engineers learn the methodologies.
The app shows the exact formulae behind all calculations and allows you to change all parameters used, from the dynamic viscosity of air to the roughness factor of copper pipework. Default parameters are provided for everything, but users can adjust them if required. Most never have to, but the transparency is there for those who want it.
Scope and Philosophy
The app focused on calculations that came up weekly, if not daily, in real building services design work. Not obscure edge cases, but the fundamental sizing and checking tasks that every mechanical engineer performs regularly: duct sizing, pipe sizing, simultaneous demand calculations, and basic daylight assessments.
Each tool was designed to work offline with no internet dependency, which proved beneficial for engineers working in basements, plant rooms, and construction sites where connectivity can be unreliable. More importantly, the offline-first architecture kept the technical complexity manageable for a solo developer project.
The app provided a method for quick calculations but was never intended to replace detailed design work. It was a tool for quick checks, site assessments, and preliminary sizing, not a substitute for rigorous design documentation.
Key Features in Detail
The app included a range of calculation tools designed around the daily needs of building services engineers. Each feature was built to be fast, transparent, and usable in the field without internet connectivity.
Pipe Sizer
Size heating and chilled water pipes based on flow rate, power, and temperature difference. The calculator supports standard pipe materials with both manual and automatic sizing modes, showing transparent methodology throughout.
Duct Sizer
Calculate rectangular or circular duct sizes for air distribution systems with manual or automatic sizing modes. The visual interface shows a scaled representation of the duct with calculated pressure drop, velocity, and aspect ratio in real-time.
Water Pipe Sizer (Simultaneous Demand)
Size domestic water distribution pipes for cold, hot, mains, or rain water systems based on fixture counts rather than abstract flow rates. Select outlets using visual icons, and the app calculates pipe sizes for each branch using CIBSE simultaneous demand methodology with configurable demand units.
Multiple Heating Load Sizer
Configure multiple LPHW (low pressure hot water) or CHW (chilled water) loads with different powers and quantities, then calculate the combined load and required pipe size for the main distribution. See both branch and final pipe details with transparent methodology throughout.
Transparent Formulae
Every calculation in the app exposes detailed methodologies, underlying formulae, and variable definitions. Parameters are configurable with sensible defaults, and engineers can choose between internal, external, or nominal pipe diameter standards depending on regional conventions.
Building in Swift for iOS
The app was built natively in Swift, targeting iOS devices. Swift was relatively new, and building the app was an opportunity to learn the language and gain more experience with mobile development whilst creating something genuinely useful. I personally had an iPhone, and it worked well for me and the majority of my colleagues.
Many engineers did carry Android devices, and as word spread, I received requests for Android and even the occasional request for Windows Phone. Despite having Android experience, this was too much work for a solo developer on a free hobby project. The pragmatic choice was to focus on one platform well rather than spread effort across multiple platforms poorly.
All calculations ran entirely on-device with no server calls or internet dependency. Whilst offline functionality was beneficial for engineers working in basements or plant rooms with poor connectivity, the architectural choice was primarily about simplicity. I could have built a server to host pipe sizes, default parameters, and other reference data, but keeping everything local made development faster, maintenance easier, and aligned with the reality of being a sole developer. Keep it simple.
The UI followed iOS design patterns closely with native controls and familiar gestures.
Organic Adoption Across the Industry
Building Services Toolbox spread through word of mouth within the building services engineering community. I never marketed it formally, but engineers who found it useful told their colleagues. The app was originally aimed at consultant building services design engineers, with an emphasis on mechanical. However, as it gained popularity, it was adopted by a much wider range of professionals.
From the feedback received, it was used by everyone from consultancy directors right through to apprentice plumbers. Consultants used it for design calculations. Contractors used it on-site for validation. Commissioning engineers used it for checks. Even trades found specific calculations useful for their work.
The transparency of the calculations built trust. People weren't just using it because it was convenient; they used it because they could verify the logic and be confident in the results.
Analytics
I captured analytics data from the App Store dashboard during the app's active years. Whilst these snapshots don't represent the final figures, they demonstrate the app's global reach and consistent adoption throughout its lifetime.
The global installs show that the app was used not only in Ireland predominantly, but also in the UK, Australia, UAE, and Italy. Australia and the Middle East would be places where CIBSE have a presence, and the construction industries in those countries can be booming at times.
The usage graph is another snapshot showing units per week, or essentially how many installs of the app there were. It's steady enough, ranging from a couple of installs a week up to 15 installs a week, totalling 619 over that period. A decent number of installs for such a niche app, demonstrating how useful people found it.
CIBSE Digital Engineering Award
In 2018, Building Services Toolbox was shortlisted as a finalist in the Digital Engineering Awards in the Best Innovation category. The competition was run by CIBSE's Society of Digital Engineering.
Being recognised by the professional institution was validating. It confirmed that the app was solving a real problem in a way that the industry valued.
The submission emphasised how the app addressed real challenges faced by engineers in the field: preventing delays when quick calculations were needed on site, providing reliable reference material away from the office, and offering complete transparency in all calculations and methodologies. As I noted in the submission, I measured success not by revenue but by the number of people who found it genuinely useful in their day-to-day tasks.
View the original award submission
Maintenance and Natural Retirement
As I transitioned fully into software engineering at CoolPlanet, the iOS app became an ongoing maintenance burden. Apple releases regular iOS updates that can break compatibility, and whilst I wasn't using the app day-to-day in my new role, users continued to rely on it.
This was a free hobby project. I received requests from users when things stopped working, but I had other priorities. Eventually, the app was naturally retired as users upgraded to iOS versions that were no longer compatible. They simply couldn't use it anymore.
Many users got in touch asking whether the app would be upgraded. When a sufficient number had asked and I had some time, I started considering a revival. I'd also been chatting to CIBSE about doing it officially, which opened up the possibility of building something more sustainable.
The Story Continues
Following user demand, I revived the core features as a modern web application in collaboration with CIBSE. The web version currently provides the Duct Sizer and Pipe Sizer (the most frequently used tools) with cross-platform accessibility, allowing me to gauge interest before investing in full feature parity.
Reflections
When I think back to this project and reflect on it today, a few things stand out. Many of these remain relevant to how I approach work:
- Domain expertise is your competitive advantage: I could manage the entire SDLC single-handedly because I intimately understood the problem. I knew which calculations engineers actually needed, what parameters mattered, and where the pain points were. The app succeeded not because of clever algorithms or impressive architecture, but because I'd lived the problem for years.
- Clean code != valuable product: I was early in my software development journey. The codebase had enormous view controllers and strongly coupled code that violated many best practices. If I saw it today, I'd cringe. But it worked, and it solved real problems for thousands of engineers. Shipping something useful beats achieving architectural purity.
- Transparency builds trust with professionals: When I first launched the app, I watched colleagues download it, run a calculation, then immediately open their trusted spreadsheet to verify the result. Once the numbers matched, they trusted the app. Professionals will always verify, so show your working.
- Design for the 90% case: Engineers could open the app, enter a flow rate, and get results in seconds because sensible defaults were applied everywhere. Dynamic viscosity of air, roughness factors, limiting velocities: all had reasonable defaults. Power users could customize if needed, but most never touched the settings. Optimize for the common case and let edge cases opt in to complexity.
- Platform choice has real costs: Native iOS meant beautiful UX and offline capability, but came with ongoing operational overhead. Apple's submission process could take days for review. Each iOS update risked breaking something. Eventually, this killed the app. Not technical failure, just maintenance exhaustion. Web platforms don't have this problem. You push updates instantly and users get them without App Store gatekeeping.
- Keep it simple (stupid): The offline-first architecture wasn't just about connectivity; it kept me from building unnecessary server complexity. I could have hosted pipe schedules, parameter databases, user accounts, all that. Instead, everything lived on-device. Simple technology choices meant I could actually maintain the thing whilst working full-time.
- Focus beats breadth: There was potential for so many more tools, particularly on the electrical side. Cable sizing, voltage drop, diversity calculations - all valuable. I said no because I had other priorities. Resisting scope creep meant the core features (duct and pipe sizing) worked brilliantly rather than having a mediocre suite of half-implemented tools.
- "Build it and they'll come" sometimes actually works: I built this expecting some colleagues in my office to use it. Maybe a few dozen downloads total. Instead, it spread globally and was used by everyone from consultancy directors to apprentice plumbers. Solve a specific problem exceptionally well and word spreads organically.
- Hobby projects don't owe indefinite support: When the app became incompatible with newer iOS versions and users asked for updates, I had other priorities. It was a free hobby project. Letting it naturally retire was okay. Not everything needs to scale forever, and that's a valid outcome. The app served its purpose for several years. That's success, not failure.