How Buildots’ R&D frees developers to focus on what matters

At Buildots, we’re reshaping how the construction industry manages progress and efficiency, using AI to tackle its most complex challenges.

What began as a rudimentary tracking tool just six years ago is steadily evolving into a platform that – by harnessing AI and massive amounts of data – is shaping up to set the standard for construction visibility and efficiency.

From the beginning, I knew that driving this industry revolution would require an environment where developers could focus on what truly matters. With developer time always in high demand, we made using this as efficiently as possible a core value of our department.

Basically, we want each developer to be able to create a lot of value in a short period of time while maintaining the quality we need. Sounds easy, right?

Here’s how we do it in Buildots’ R&D, complete with some (maybe) relatable experiences along the way.

We allow for undisturbed focus

Here’s a recipe for killing productivity – take a skilled developer’s day, sprinkle in a short meeting every couple of hours, and add frequent context switches.

We encourage our developers to have long periods of focus time. This means that any scheduled meetings are clustered together, and we ensure production issues disturb as few people as possible (not that we ever have these, of course).

Also, we communicate via the least obstructive channel possible – Slack for non-urgent matters and email for things that can wait until tomorrow.

We give our engineers responsibility and autonomy

Our engineers don’t have to go through ‘official channels’ and bureaucracy to solve problems. They can contact other teams or departments, talk to whoever they need, and get it done.

We also take this one step further. Developers at Buildots enjoy considerable freedom over the execution process itself. Want a design review? Go for it. Feel confident skipping it? That’s fine, too. Engineers make the calls on which tests to add, performance standards, and how collaborative to be in these decisions.

A click and it’s done

At Buildots, we know you’ll do it less if something is a hassle.

Take alerts and notifications, for example. We wanted our developers to easily add alerts and Slack notifications about things they want to know about. But instead of adding friction to the process, we made it as simple as adding a log message. These days, we get automatic alerts when a process takes longer than usual, a niche feature we think about deprecating is used, or even when an expensive cloud resource is sitting idle and needs to be shut down.

We create solutions, not silos

We want to make sure whatever we do benefits anyone who can use it. When developers create a helpful tool, they share it with the entire department, looking for ways to make it valuable across the board.

Need to change some code in another team’s domain? That’s no problem. Our engineers are free to contribute code across team boundaries whenever necessary. This level of trust and fluidity eliminates bottlenecks and fosters a culture where everyone feels empowered to solve problems.

By breaking down silos, we make sure team lines don’t limit great ideas and solutions.

Development to production in minutes

We want developers to push to production frequently and confidently, so we’ve designed a frictionless process. Tests are deterministic, easy to write, and don’t take ages to run. Once a developer wraps up their task, they’re just one click and an automated CI/CD pipeline away from seeing their code live in production. This allows us to deploy to production several times daily and prevent ‘idle time’ before a feature starts generating value.

Your developer environment is ready when you are

In less than the time it’s taken you to read this article, a Buildots developer could’ve used a simple Slack bot command to launch a full production-like environment with all the services, versatile data, and capabilities they may need.

This is useful for many reasons, as it allows us to:

Easily test platform-wide performance
Test infrastructure and systematic behaviors that are harder to spot in unit tests
Share a code branch in progress with our product managers to review
Get a ‘prod-like feeling’ before merging code to production

The result? Testing features is straightforward, swift, and true to life.

Our people are experienced and self-driven

As much as we like to take credit for building a developer-first culture, our success is mainly due to our individual team members. Each and every person on my team is super experienced, smart, and brings a ‘senior’ mindset, coupled with a good dose of common sense.

We’re building a culture where developers do what they do best: innovate, solve problems, and push boundaries. Want to join us on this journey? Check out our current job openings.