You’ve probably heard that building software is basically free now.
That’s only true if you’re starting from scratch. It’s a different story at a company like JLL, a commercial real estate firm that’s been around for about 200 years.
Sharon Hunt leads product for JLL’s property management technology. That includes Building Engines, a company JLL acquired. Its software runs the day-to-day of commercial buildings: work orders, visitor access, inspections, and tenant requests. JLL uses it in every building it manages and also sells it to other property management firms.
When Sharon’s team first tried AI coding tools on their main product, the results weren’t usable. So they spent a year getting the product “AI-ready,” and now they ship about 4x faster. But that created a new problem: the people around the product can’t keep up with how fast it changes.
In this episode, we get into:
Why AI struggled with an older codebase, and the cleanup that made it 4x faster
Why the new bottleneck is how much change your sales team, support team, and customers can absorb
How clear customer metrics got engineers bringing their own product ideas
When to ship small fixes right away and when to hold changes for one big release
1. Slow down to speed up: Getting an older product ready for AI
Building Engines’ main product, Prism, was rewritten in 2018. That’s recent for a company founded in 2001, but eight years isn’t exactly new for software. Parts of the code had little documentation, logic was nested several layers deep, and the front end was mostly custom-built with no shared design system.
When the team pointed AI coding tools at it, the AI got just as lost as a new hire would.
“What we learned trying to deploy, and speed up development on this application using Claude early on, was that Claude was running into a lot of the same challenges that our new engineers were running into.”
The team decided to clean up first. They started small. A team of three or four rebuilt the tenant portal, a lower-risk part of the product that tenants only use now and then. It took about a quarter instead of the year they’d estimated. Along the way, they built reusable AI workflows and adopted Solstice, a JLL design system built to work well with AI tools. Then they used that playbook to help a 70-person R&D team start rewriting the main app for property managers.
That rewrite is now about 80% done. The team works through about four times as much as before, and cleared more than 100 backlog requests along the way. The cost was real: they mostly stopped shipping major new features for about six months to get there.
Product takeaway: If AI tools are struggling in your codebase, they may be hitting the same problems your new hires do. Fixing those problems (clear structure, documentation, a shared design system) pays off for both. Test the approach on a low-risk part of the product first, then use what you learn to scale it.
2. The new speed limit is how much change people can absorb
Once the engineering team got fast, the bottleneck moved somewhere else. Every change has to be learned by sales, so they can sell it accurately. Customer success has to learn it so they can answer questions, and implementation teams have to learn it so they can onboard new buildings.
Then there are the users. Property managers use the product all day to do their jobs, so constant big changes wear them out. Their tenants are also customers, and if tenants get frustrated, that frustration comes back to the property team and then back to JLL.
“It’s all of the scaffolding and the enablement around the product...it’s human absorption that’s the new limiting factor.”
Sharon would still rather have this problem than the old one. Being too fast for your organization beats being too slow for your market.
Product takeaway: When AI speeds up your engineering team, check what slows down next. Plan for how quickly sales, support, and customers can learn what you ship, and treat that capacity as a real constraint on your roadmap, not something to deal with after launch.
3. Give the team a “why,” and they’ll find the ideas
Before the rebuild, the roadmap was full of urgent, disconnected requests: features for new countries, and gaps to close so clients moving from older Building Engines products would sign. None of it added up to a strategy.
Sharon replaced that with three measurable benefits for customers:
Saving property staff time on repetitive work, so they can spend it on tenant relationships
Increasing net operating income by finding ways the product can raise revenue or cut costs for a building
Faster deployment, so a new building or account can go live quickly
Every feature request now gets checked against those three. How many people use this workflow? How much time would the change save? The result she’s most excited about:
“I’m seeing for the first time a lot of really great ideas coming back from the R&D teams, specifically developers, because now they understand these metrics.”
Engineers also have more time to explore the product, spot any issues, and fix them on their own. And when teams visit buildings to watch people work, they can come back with a working prototype the same day. That used to take weeks or months.
Product takeaway: “Build this by April 1st” gets you a feature. “Here’s the problem and why it matters” gets you ideas. Define a few customer benefits you can measure, share them with the whole team, and use the time AI gives back to get engineers closer to customers.
4. Ship small fixes now, save big changes for one release
If your team can ship 100 new features in a day, most customers will never find them. Sharon’s approach is to make the workflows people already use better before adding new ones. Take certificates of insurance: property staff used to type in every field by hand. Now they can drop in a file and let the product fill it in, all inside a step they already know.
For releases, she splits changes into two groups:
Small fixes ship right away. Things like letting users select all in a dropdown don’t need training.
Big workflow changes wait for one release. Her team is rethinking inspections so an engineer can just take photos, record a video, or dictate notes instead of filling out a questionnaire. That changes the reports, the mobile app, and everything downstream, so it all ships together.
“We’ll be making so many changes, you want to be choiceful with what you ask your customers to absorb.”
Product takeaway: Sort what you ship by how much it asks users to relearn. Ship small fixes continuously. Bundle changes that alter how a workflow works into one release, with training ready for customers, sales, and support at the same time. Now that building is cheaper, rethink whether a small first version is still the right call.
Chapters
00:00 Introduction
04:08 Why AI struggles with an aging codebase
05:16 Making JLL's Prism AI-ready by rebuilding the tenant portal in one quarter
09:03 AI lets you ship 4x faster, but users can only absorb so much change
12:07 JLL paused major features for six months to go slow to go fast
19:57 Improving existing workflows instead of building new features
22:19 Finding friction with data, site visits, and engineers’ own ideas
27:22 When to ship small tweaks and when to hold back for big releases
31:48 Conclusion
Links
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.