Buildertrend
Sales Tax Implementation
Challenge
Implement sales tax functionality across Buildertrend’s financial workflow so users can set tax on projects, mark items taxable, and tax automatically calculates across financial features.
Solution
Design and implement a cohesive and streamlined new experience that establishes a new pattern and functionality that provides users the ability for tax to be calculated on items across projects.
Methodology
• Systems thinking
• Customer advisory board
• Pilot group rollout
• Wireframing/prototyping
• Usability testing
• Root cause analysis
• Data/evidence-driven design
• Design engineering
• AI-augmented development
Tools
• Sketchpad & Pen
• Claude + Claude Code
• Databricks
• Figma Make
• Lovable
• Mixpanel
• Chameleon
Deliverables
• Sales tax functionality across the end-to-end client-facing financial features for builders
• Tax also syncs with accounting software integrations offered
About Buildertrend
Buildertrend is the leading residential construction management platform. Since 2006, Buildertrend has empowered contractors to take control of projects, bringing efficiency, organization, and seamless communication to all areas of their businesses.
Builders can stay on top of costs, supplies, staff and more in, all in one convenient place – and take on more projects without adding paperwork and stress. For over 1 million users across 100 countries, Buildertrend has made it easy to run successful projects and deliver a five-star experience to homeowners.
Users
Primary user:
Residential general contractors ($1M+ annual revenue)
Secondary users:
Clients of general contractors (homeowners, property owners, etc.)
Subcontractors and vendors
Impact at a glance
The problem
For the entire life of Buildertrend, 20+ years, tax has been a missing feature. Not an edge case, but a core gap across a builder’s financial workflow: estimates, proposals, bids, selections, allowances, change orders, and budgets. It was one of the biggest detractors of NPS and a real churn risk.
Complexity didn’t just come from adding a tax field. Buildertrend serves builders across the world, and how tax gets handled is vastly different in each region and by contract types - not just rates, but entirely different tax structures and variations in what is considered taxable.
The real difficulty came from retroactively calculating tax within financial workflows that had never had it, releasing the work in valuable small slices, and managing the change that came with each one. It also meant learning construction tax itself, arguably one of the most complicated things in construction.
Our hypothesis is that by providing the ability to set, apply, and manage tax, we will eliminate tax as a top reason our users churn and stop using our product.
What we did
Solving tax meant ensuring a simple and consistent interaction for how to set and manage tax, as well as displaying tax amounts in a clear and understandable way.
For example, on an estimate, items get marked taxable which is the same interaction pattern as change orders, selections, allowances, and bid line items. A proposal generated from an estimate will clearly display which items are taxable, showing a clean and simple breakdown at the end of the proposal for clients that displays a ‘Subtotal’, ‘Tax’, and ‘Total price.’
More difficult design work surfaced on things in Buildertrend like the Job Price Summary and Job Costing Budget.
The challenges stemmed from the fact that both pages serve different audiences with different trust needs.
Job Price Summary - client-facing page that can always be seen by clients, so it needs to read like a receipt in order for clients to easily scan and understand a job’s total price, including tax
Job Costing Budget - a builder-facing page, and builders choose whether or not a client can see it - using progressive disclosure here was key.
In the client pricing section of the Job Costing Budget, a builder can expand columns to see tax amounts, and a popover on the data visual above the table provides a more detailed price breakdown as needed.
Design strategy
Above all, I wanted builders to feel that setting tax and applying tax to items was simple, accurate, and consistent - while earning trust through intentional change management.
If an item was marked taxable early in the financial workflow, builders should be able to trust it will flow downstream and calculate accurately throughout a job.
Tax is handled and applied very differently that depend on a multitude of factors, so I wanted to be thorough and understand how tax worked across different regions, contract types, and how it showed up in a project’s budget or reports.
"We make sure items are taxable - that was a big thing I've been working on with Buildertrend. Tax was the biggest killer, so it's awesome that we've been working with Andrew and we're finally getting tax on items.”
- Ellingsen Construction, Inc. (Washington, U.S.)
“Honestly, with the way I have everything dialed in and pre-programmed now, everything’s been great. Adding the tax feature was life-saving for sure. It’s super efficient.”
- Shell Basix (Florida, U.S.A)
Earning trust
Earning trust from users in this work came from effective change management.
Tax had been missing for the entire life of Buildertrend, over 20 years, so this wasn't a small feature add or minor update.
Rolling it out all at once would have been overwhelming for users, and we needed to get calculations right across each region's different tax rules, in addition to limiting how much change users had to absorb at once.
Releasing it in slices meant each piece could be verified and released with little to no risk. It also meant telling users "end-to-end tax is coming" with each release, because the feedback after each one was consistent: "I like this, but I need it across my whole financial workflow."
Trust wasn't just about calculations being correct in the moment, it was earning confidence that the full solution was actually on its way.
Outcome and impact
Since release, tax feedback in NPS has reduced significantly, and went from a common detractor to something that has become infrequent in feedback.
Adoption started slow but is growing steadily, especially with the example of the jump in usage with tax on Change Orders. It began with a small pilot group of 15 builders who tried it before general release, and increased roughly 10x on day one of releasing to all users. It nearly quadrupled in usage within that first week of general release. Total adoption across all tax-enabled features has increased to now thousands of builders, continuing to grow week over week.
We also saw a notable shift in international adoption: the majority of our top tax users are outside the US. That tracks with how tax law works in those regions, Australia, New Zealand, and Canada tax nearly everything, while the US is much more fragmented in what's taxed, if it passes to the client, and what it's applied to.
This work established a new pattern for setting and managing tax now used across:
Estimates and Proposals (including Bids on Estimates)
Change Orders
Selections and Allowances
Job Costing Budget
Financial Reports
Additionally I also effectively led designers to align on standardizing terminology in the product to now reflect tax-inclusive values, as well as became a resource for others as a subject matter expert (SME) while teaching others about tax.
I worked with other designers to ensure tax is considered in future work on financial features so we’re not adding this functionality but ignoring it as we design in the future.
How I design
This project reflects how I lead design in complex, integrated systems:
I focus on designing trust, using change management to effectively roll out a complex feature like tax in small yet valuable releases
I design new patterns that scale across a product while leading teams to implement the solution, ensuring a streamlined and consistent experience
I eagerly dive into new, complex problem spaces, utilizing AI and quantitative and qualitative data throughout the process to minimize risk and validate the solution
While tax is just one part of financials on a construction project, ensuring it calculates accurately for builders across regions and contract types was crucial in this work.