Reflect Logo

Check out this interview with Brad Heller, the co-founder and CTO of, a data visualizations and analytics platform for developers. He is also a long-time Orchestrate user, which is why we reached out to learn how he's using our NoSQL database-as-a-service (DBaaS) and what's going on with his new startup.


My passion is building companies and cultures that foster innovation. I'm always looking at things through a new or different lens--the status quo doesn't have to exist. Big data is ripe for a disruption, and we're going to lead that at Reflect. Reflect is located in Portland, Oregon.

You're the CTO; how often do you write code?

It’s actually getting less and less, even though we’re still young. I’m handling a lot of customer success stuff and a lot of product stuff, so I would say I spend about 50% of my time coding.

What is

Reflect is data-visualization-as-a-service. We’re doing for data visualization what Twilio did for communication, or what Stripe did for payments. We’re making it possible for developers to add really great dashboards and reports for their products in just a couple of minutes with our hosted tools and our JavaScript libraries.

What's your programming language of choice?

Go – all the programming communities are starting to move over to Go. I was a sort of an early adopter, I’ve been writing for a year and a half. We use a lot of JavaScript too.

While we were busy with dynamic programming languages and scripting languages, there was all this research work being done in the compiler world (LLBM and GCC), and it’s like we almost forgot about it for some time. Then someone mentioned it, and it was like ‘oh man’ we could actually statically link and compile programs (we had forgotten you can do that) as a super convenient way of distributing software. Go is this super cool mixed-language in that it has the performance of a low-level system like C, but it has the expressiveness of Python.

Why did you build

My co-founder and I had been working on analytics and data visualization for a very long time. I’ve done it from the back-end, and he’s done it from the front-end. We found we were basically building the same infrastructure over and over again. Companies are spending way too much money building and maintaining the teams that enable this stuff. There aren’t great tools on the market that provide a higher level of functionality besides the standard charting libraries. It’s a very unproductive experience creating data visualizations right now.

The third component is that doing data visualization right is really hard -- it’s a well-established science in terms of how humans digest information and it gets screwed up a lot. We can help with the design; we can help choose the right way to visualize your data. Our hope is that since so much of the industry is struggling to get the basics of data visualization up and running, if we can commoditize the process and functionality, we can move the industry forward.

What are some of the challenges you’ve had in building

Our tools replace an entire function within an engineering organization. Often times when you buy a developer tool it replaces an entire horizontal slice in the company, e.g., Orchestrate replaces the database portion. However, our tool replaces more of a vertical slice – we have our front end tools, our middleware for generating report data, and then we have our back end. We have a lot of technology that goes into making Reflect work, so there are a lot of features and functionality that we need to keep an eye on.

Also scaling other people’s databases is challenging. The way that our tool works, we have an agent that connects to your database and then we use that to issue queries to get data out to service data visualization. Often we'll run into random performance problems with other people’s databases that hinder our performance.

What are some of the data challenges you’ve had in building

For our transactional stuff -- we’re inserting ourselves in the middle of a user’s request cycle/their interaction with a company. Our services always have to be on and performing. So doing simple things like checking an authentication key is still valid -- we’re going to do that a lot with our tool, but we also need to do it as quickly as we possibly can, as any performance degradation on our side is going to effect how our customers and their customers see us and them, respectively. Availability is really important and is a reason we delegate that to external services like Orchestrate.

What problems does solve for its users?

It lets people do something that they couldn’t very easily do. You would have to build a team to do it, and now you can get it off-the-shelf by using Reflect. Companies can now get data to their customers in a much better way than they could previously. Some companies may have customers with custom data that wouldn’t be easy to represent in their current system, but with Reflect it’s easy to create custom, on-demand reports.

What’s been the most challenging part of building a product and company from scratch?

The line between genius and crazy is super thin. Sometimes it’s really hard to figure out which side you fall on. There’s been a ton of features/ideas that we think are amazing, but don’t pan out when you put them out in the market. Gut checking yourself early, often, and knowing when to stop is a challenge, but it’s important to discover the checks and balances.

How has Orchestrate helped?

We don't worry about scaling our transactional stuff at all. We deploy in a new data center and Orchestrate is able to handle it, no problem. Multi-region deployment is simple. The different semantics that Orchestrate puts on top of data -- having the graph, search, and events functionality allows us to solve problems without having to think about how the data is structured too deeply. We’ve always been able to get at the data we need without having any significant data performance.

Most-used Orchestrate features:

  • Key/Value (almost exclusively), user data gets stored into Orchestrate, metadata about how accounts are configured gets stored in Orchestrate.
  • Events (for tracking things that don’t belong in Mixpanel).
  • Basically everything behind our API is driven by Orchestrate.

How does do things differently?

We think about visualizations much more holistically. We don’t think about just the graph itself, but the visualization in the context of the graph. A graph is just a part of the visualization. The data is important and different ways of exploring the data that drives the visualization are important.

Anything else you want to share with your fellow Orchestrators?

Sim. Check out – we’re in private beta.

What's your development setup look like?

We use Github for all our orchestration and Trello for managing tasks. 90% of our projects are in JavaScript or Golang (we use ESlint and Golint to make sure everyone is consistent). We also use Gitflow for workflow management, and Docker and Mesos in production. We’ll deploy software maybe 10x a day. We move fast; so our workflow is geared around that.

How’d you find your founder(s)?

I worked with Alex in Cloudability in 2011. I first met Alex in PIE (Portland Incubator Experiment) when I was working on my last startup. At Cloudability, Alex’s side project was working on the front-end, and since I had back-end experience in the same space, we decided to team up.

Why Techstars? Any advice about the program?

Techstars is a global ecosystem that helps entrepreneurs build their businesses. We picked Techstars because we had been working really closely with Chris Devore who is the PM up here. Chris is great and his network is awesome. It was a no-brainer to jump in when the invitation was offered.

I’ve been in and around the TechStars ecosystem for a long time -- with Cloudability -- so I knew what to expect. The advice I would give is that you shouldn’t stress out about your performance relative to the class. It doesn’t really matter. You should focus on what you’re going to do and do the best that you can, and everything else will fall into place.

What's Next?

Sign up for our Developer-focused newsletter CODE. Designed hands-on by developers, for developers. Keep up to date on topics of interest: tutorials, tips and tricks, and community building events.

CenturyLink Cloud – We’re a different kind of cloud provider – let us show you why.