When TestFit pulled in $20 million in new funding earlier this year, the startup shared aspirations of growing the team to nearly 50 people.
So when CTO Ryan Griege revisits the nascent days of the startup, the funding doesn’t just illustrate the Dallas-based company making a name for itself in the market — but underscores the significance of the journey traversed by the technical co-founder.
“The first version of TestFit was a humble command-line utility to help Clifton Harness, my co-founder, lay out apartment units at his day job. It didn’t even have a user interface!” Griege said. “But from day one, it already solved a real problem that helped him do his job more efficiently. TestFit grew to automate the tedious, error-prone steps, like counting parking stalls, and allowed him to focus on designing and developing better buildings.”
TestFit helps professionals in the architecture, engineering and construction industry make data-informed choices for their developments. Its design software helps assess if a site is suitable for a project’s respective needs.
Griege credits the relationship he has with Harness for powering the startup forward.
“My co-founder and I have worked together for almost a decade at this point, across various projects. We’ve developed a deep understanding of each other and can move quickly towards almost any goal,” Griege said.
So how has it all come together from a product and tech perspective? Connecting with Built In, Griege shared how the organization has navigated the growth as it seeks to innovate within the industry.
Why did the company need to build this product?
Most of the architecture and development world is designing commodity buildings with inefficient tools. When it takes weeks to put together a few designs and coordinate them across several organizations, there’s a strict limit on how many variations you can look at before green-lighting or killing a project. TestFit can make this process 100 times faster, allowing our customers to achieve better outcomes on their projects much more quickly than before.
“Most of the architecture and development world is designing commodity buildings with inefficient tools.”
What role did you play in developing and launching the product? What tools or technologies did your team use?
I was the only software developer for around the first two-and-a-half years of the company, so I built the initial version of the product and have contributed to many of the updates since then.
I chose to write the application in C, which is not very common these days. I had recently been burned by chasing the complexity of other tools and languages and wanted to restore my focus on outcomes instead of methodologies. Using C forced me into that mindset on a daily basis.
Additionally, I grew frustrated watching computer hardware get more powerful each year, only for software to become more sluggish. We wanted to create a solution that works as fast as the person piloting it and creates a sense of awe around how truly incredible computers are.
“We wanted to create a solution that works as fast as the person piloting it and creates a sense of awe around how truly incredible computers are.”
What obstacles did you encounter along the way?
The biggest obstacle we’ve had to overcome is a hesitance to innovate in the architecture, engineering and construction industry. The past 6 years feels like an eternity in startup time, but it’s a small flash in the pan for an industry that has to deal with large and expensive physical assets that are built to last for decades. Our track record of consistent updates for several years has started to open up doors that felt impossible to crack when we started.
Designing an entire building in less than a second is no easy task. Luckily, most software developers love solving hard problems. The journey is certainly tough, but we give people the freedom to tinker while ensuring that the goals of our work are aligned with customer needs. The payout of seeing a design adapt to new constraints in real time is always rewarding.
What teams did you collaborate with in order to get this across the finish line?
At some point, I reached the limit of what I could do alone on the engineering side. We stayed small, but I brought on a few other software developers to help expand what I had built for high-density apartments and to reproduce into other typologies, like lower-density housing and industrial. While each type of building is different, we’ve worked together to build a common internal language and ethos for what a TestFit-designed site plan means.
We’ve also collaborated with a few external partners, but generally the AEC industry is behind the curve on technology creation and adoption. We would love for others to start their own companies so we can partner with them to drive innovation across the industry.
When you think of other companies in your industry, how does TestFit compare when it comes to how you build and launch new products?
Several of our engineers have a background in video game development and those fingerprints are found in the software. We have run-time and memory budgets for various parts of the software. We have a target frame rate to hit. Again, there’s an emphasis on performance that isn’t found in many other business-to-business tools. A lot of software teams focus on rapid iteration internally, but few focus on building tools that foster rapid iteration for their clients.
“A lot of software teams focus on rapid iteration internally, but few focus on building tools that foster rapid iteration for their clients.”
Organizationally, we focus on keeping teams small, giving them autonomy and trying to remove any impediments to rapid progress. We’ve added a lot of people to the team in various roles who have backgrounds in architecture, engineering and development — they have helped us develop a deeper understanding of our customers.
