A decade ago, leaders at Edmonton, Canada-based Rohit Homes, began to question the industry assumption that friction, rework, and information gaps are the cost of doing business. These leaders, including Rohit Gupta and Adil Kodian, focused on tighter execution, clearer accountability, and the belief that operational excellence could be repeatable.
What emerged became BuildBase, an internal solution designed to solve small problems experienced in the home building process. The platform helped reduce noise, improved alignment, and unlocked measurable gains in efficiency, revenue, and revenue per employee for Rohit Homes. The tool was never intended to be commercialized, however the platform has become a tool for home builders to achieve similar efficiencies and reduce the waste and rework common in the industry.
Kodian, executive vice president of Rohit Homes and the architect of BuildBase, and Gupta, president of Rohit Group, spoke with BUILDER about the origins of BuildBase, the role of technology in the home building sector, and the vision for BuildBase’s future.
Courtesy BuildBase
Adil Kodian (L) and Rohit Gupta (R)
In an industry that is resistant to technology or a laggard, what perspective do you have on technology and what it can provide for those who are adopt and embrace it?
Kodian: If you Google Edmonton real estate, what shows up is that we are either the most or the top three most affordable housing cities in all of North America. If you are home builder in the most affordable city in North America, you are probably not making much money. We came to technology not from wanting to do something flashy, but as a survival tactic. The level of competition in Edmonton is insane. We came into technology to make sure we could build housing in the most cost-efficient way possible. We started with eliminating basic things like waste on site. Then we looked at it further. We thought, if we employ eight people on accounts payable, that is also where we will lose money. Let’s go into e-payments, digital trackers, online payments.
Great ideas and transformations are born during adversity. Software like BuildBase was written in a city where adversity was the norm, not booms. As we are coming off a boom, now is the time to look at every possible competitive advantage. At Rohit, we produce a revenue per employee of more than $3.4 million. That is the level of efficiency that leads you to be cut throat and effective using software.
How did the solution that became BuildBase become an in-house creation rather one utilizing existing platforms?
Kodian: Software that is available at the industry level, it feels like a bunch of software developers got together and tried to approximate what problem they think the builder may be facing. To do what BuildBase does, you have to buy 10 or 12 different products. Then you have the situation where your data person is logged into three different apps, they data enter into one app, and they turn around and data enter into a different app, and data enter into a third app. The error rate multiplies. You can buy an amazing product to do warranty, an amazing product to do accounting, and do sales CRM. They just don’t talk to each other. They don’t assume the other exists. For the builder, we are stuck operating 15 different things. They are all great, but they don’t talk to each other. That was the case in 2007. That is the case today. Largely specialized software that all do very niche things very well.
Gupta: Home building is a very complex set of systems. When we talk about it, depending on the builder, we are talking about more than 100 tasks that have to be pulled together. When you look at it, there is a 1:10 multiplier of people that work for the home builder versus how many people visit on the site on a daily and monthly basis in a single home. The complexity of the system is significant. Most solutions that exist are built around solving a problem. There is no standardized protocol by which they communicate to each other or how the solutions are brought together. It takes a team that is just frustrated with what their existing solution set is and wants to keep reinvesting. We didn’t just do a dollar investment into the asset; we made a business investment that took about a decade before we started the commercialization process of BuildBase.
It’s not that the brilliance is in that we’ve created a solution that solves all problems, the intelligence is creating a system that becomes a protocol standard that we can move forward, and other things can lever off of as we go forward. By creating a single source of truth, we discovered waste that exists in the system.
What are the first steps you take when you are in the thought collection and development phase of the initial solution that became BuildBase?
Gupta: We started solving small problems. As we started solving small problems, we got frustrated with our own solutions. We said they were too disparate and asked how do we agglomerate them into one solution. That’s why we are on version 90. It’s a learning journey. One of the challenges I find is that technology businesses are either exploring or they are harvesting. When you are in harvest mode with software, you stop reinvesting into it. We are not in the harvesting model, we are investing.
Kodian: To date, we have never created a project charter for BuildBase. When we sat down and tried to write requirements for what the software would be, we didn’t know. What we did instead, is said we would create features in six-week increments. Those features and capabilities must be usable to regular people who are not software experts. When we wrote version 1 through 5 or 6, we wrote it using SQL server, handwrote the code, and solved basic problems: How do we get documents out to the trades so we don’t have to ship bulk pieces of paper? By version 10, we realized the underlying platform choices we had made were inappropriate. So, we threw the whole thing out and we re-wrote it. This gave us the option to walk away from garbage that we had added on. Over a period of five or six years, we made sure that every six or eight weeks, everyone got used to seeing something new added to the platform. The excitement kept building. Our team started seeing real annoyances get solved. As we started solving these incremental problems, we realized we could solve this other problem that we didn’t even think about solving.
How do you design and plan a system to operate intuitively without training?
Kodian: All of our user interface is designed with storytelling in mind. When you log onto BuildBase, the interface looks like it was designed for kindergarteners. If you pick up a kid’s toy, you see big buttons that you can press and then it makes sounds. We’ve designed BuildBase with that level of simplicity. The reason for that is we really understood that A) the user has no patience to sit through training, B) the person is typically wearing gloves in the field, and C) our use base is used to left-swipe, right-swipe. Each interface does a maximum of three things. Microsoft Word can do thousands of different things, it’s multipurpose. We have no ribbons; we have barely any menus. It is designed to be simple; press this button to go see the document, press this button to go approve the PO.
We also created special purpose interfaces only. We looked at what role we wanted to access each interface. It was better for us to create extremely granular goals and extra interfaces. Even though all interfaces connect with each other, the salesperson only sees the information they need to see, there is no information overload. The accountant may use the same data, but sees it in a way that only shows them what they need to see. It wasn’t about privacy, it was about making sure the human brain in each role is not overloaded.
As a result, we have no training. For 80% of the people that use BuildBase, they are going to be pressing the same four or five buttons as part of their job. They very rarely will need to venture into other parts of the software. The biggest enemy to scale is onboarding time. Whether it is into software or homebuilding. We are a large volume production builder. We fully load everything, to the specifications. We took the same discipline to product and software. We want the person to be productive to make revenue and profit happen weeks into their job, not years into their job. Having software that is intuitive and simple is extremely important. If it takes someone six months to train to cash checks in our organization, it is too long.
Was there any hesitance or reluctance in adoption among team members or outside vendors in the initial phase?
Kodian: We had two early guiding principles. No big bang rollouts and do not rollout anything that requires training. To this day, we do not offer any training. We must design interfaces that have only three clicks on it. We follow the Apple model. Your Apple phone comes with no training manual because it is easy to figure out, intuitive. When designing software, we didn’t want to change people’s lives overnight. That creates a lot of pushback because change management becomes a problem. Just solve extremely small problems and every iteration can only improve. Good features survive into the next generation of software; bad features eventually get weeded out of the system. Eventually, this just became culture for our business. It became a culture of innovation with small micro-changes.
What does the feedback loop look like during the development and iteration process?
Kodian: We used various tech options to keep track of every possible complaint we got. We had a small help desk we would centralize the complaints and do a little triage to verify whether the complaints were real. Every six-week release would have a release note that said these bugs have been addressed, these bugs have not been addressed. We were generally always moving toward a more progressive direction and we took care of communicating exactly what we were touching and what we were not going to touch. That was what saved us in terms of employee pushback.
How did BuildBase help with efficiency and what efficiencies did it unlock?
Gupta: We used to operate in two municipalities, we produced 450 homes a year, 300 lots a year in land development, and we had 180 employees. Today, we are close to 240 employees, we produce 700 lots a year in land development, we have 1,400 units, we are in five major municipalities, we have a retail development arm, we have an office development arm, and we have an infrastructure development arm.
For the team members that could adapt to the technology changes, their quality of life improved tremendously. Most of the gains that we saw were in the reduction of communication of ‘What is the status of something’ or ‘Can you pass me this document?’ That transfer of knowledge increased but the amount of communication decreased. The amount of errors and transcription errors reduced. The amount of re-work also reduced. The effective tact time on administrative files reduced also. Lastly, it creates future optionality. One of the core items that the BuildBase team has delivered upon is they have created new data extraction systems, they have given us the precursor to integrating Microsoft Fabric into our systems so that we can be AI-ready and enabled. Everything has been set up from a data architecture side that gives us optionality to transition to the new economy as it takes place. It makes us far more friendly to recruiting younger people into our shop.
As you look back on the BuildBase journey to date, what are some of the biggest lessons learned?
Gupta: I would argue that the historical concept that you have 1 – 2% of your budget for technology needs to be 3 – 5% and you need to try to figure out how to deploy that budget. It’s not so much that all 3 – 5% will be effective, it’s that there must be research and development that is taking place within our organization so that we can experiment. We as business leaders in an environment of volatility need to make sure that we exist in a space that we experiment and we give our teams the room to experiment and allow grassroots solutions to come up and help us.
Kodian: When we started this journey, there was a lot of uncertainty. There wasn’t an inkling of commercialization of the software; we are a home builder. We set out to solve our own problems. We lived in fear of burning through money, we lived in fear of losing half our team because we made them angry. In hindsight, we should have had more confidence in ourselves. We slowed down because we were overly worried about the risk to the organization in the transition.
What is next for BuildBase?
Kodian: My belief is that the world’s largest home builder will not build homes. Let me explain, the world’s largest cab company doesn’t own vehicles. It’s a gig economy-based product. We believe that the world’s largest builder will not build homes, but will provide everything that leads to the building of homes. Data, systems and services, capital, land, design, plans, etc. The world’s largest home builder will be a marketplace where a lot of builders will provide services, and we will act as the platform technology that connects from A to B. That is what true scale looks like for me, personally.
Today’s scaling plan is to make a builder that is an add-water, instant builder. If you go to a new city, you still must find lots, you have to find capital. But what if the underlying infrastructure, the office admin, the receptionist, the accounts payable, the invoicing, the treasury function, and the lending management, all showed up on day one? We are reducing 70% of the risk of startup.
Gupta: When I was coming through this business, I was a guy who was hamstrung by the systems, and I had to replace a bunch of systems. Today, if there is a younger version of me coming into the shop, if they want to create new tools, new data sets, new ways of communicating, there is no reason they can’t use a platform like [BuildBase] and employ it effectively. This is a platform for creativity. From my perspective, the number one thing is to put this tool in the hands of the users as fast as we can and let them see what they can create.
