Tales From Hack Day: Braze Senior Software Engineer Hal Anil Calculates the Tax Impact of Exercising Options

Three times a year, employees from around Braze take two days away from their normal duties to participate in Hack Days. These events—a long-running Braze practice that reflects how the company creates space for dreaming up and implementing new ideas—provide a chance to encourage innovative thinking, highlight pet interests, and even optimize the Braze platform in ways big and small.

To recognize the work that goes into each Hack Day, Building Braze will be profiling participants with particularly memorable projects or experiences. This week, we’re talking to Hal Anil, Senior Software Engineer on the Frontend Infrastructure and Experience Team.

For the First Time, a Solo Project

Since I came to Braze about two years ago, I’ve participated in just about every Hack Day, always working with other people like designers and engineers. This was the first time that I worked entirely on my own, which has been different from the other Hack Day projects I’ve done in that they were with teams of cross-functional Braze employees.

Just about all of my Hack Day projects have come out of informal conversations with coworkers. Someone will mention a problem they’ve had with Braze, or that a piece of the application could be more efficient. That'll snowball into a broader idea for how to create something that’s meaty enough to show people, but small enough that we can have a functional demo in a day and a half.

Ideas Beyond Braze

Many times, the Hack Day projects relate to Braze, but we’re also encouraged to work on projects that are personal, even if they’re inspired by Braze, in a way. The AMT Calculator & Planner I built came out of a personal need. I wanted to know the tax impact of exercising my Braze options, and calculate the possible alternative minimum tax (AMT) burden. I couldn’t find anything good online that had a deep level of granularity. I wanted a tool that would allow for some scenario-building—like, what happens if I do this, what happens if I change that.

I didn't want to spend hundreds of dollars talking to accountants every time I had a question, so I thought I’d solve this on my own. It’s a pain point that I didn’t think was being addressed.

Start With a Spreadsheet

My idea started with a spreadsheet, as many finance-related projects often do. The more data I threw into the spreadsheet, the more difficult and unwieldy it became. I was looking at multiple years of personal finance data and throwing in a bunch of different scenarios for exercising different options at different dates.

As the universe of scenarios grew, I figured that since I’m an engineer, I could solve this interesting challenge with software. I envisioned an app in which you could input information and see the outcome of exercising options or selling for a particular tax situation. This would help me skip some of those accounting conversations.

Limiting My “Innovation Tokens”

As you get into building a full-fledged web application, the more the features evolve, the more you begin looking at adding the solutions you know pretty well. I knew I’d need some sort of backend to host and store the data and an application layer to compute the taxes at the end. There needed to be some method of hosting the application so that people could access it, and some way of securing it so people would only see what they’re allowed to see.

I read an article suggesting that when you’re working on a new development project, or using a tech framework you’re not familiar with, you get three “innovation tokens,” Essentially you can use up to three new technologies that you’re not as familiar with, but the rest of your project has to use your “boring” technologies that are more stable and battle-tested. Once you use all of them up, you can’t add more, because the complexity of your project will balloon to the point where you won’t be able to maintain it. With this approach, I had to think about my technology choices carefully, in order to figure out where I wanted to be innovative, and where I wanted to play it safe.

Using React was the play-it-safe piece, as was using Next.js with React as my application framework. I find their approach to building web applications really straightforward and logical. Next.js is maintained by Vercel, which also has a hosting solution. These are frameworks that I’m familiar with, so I didn’t need to give up any of my innovation tokens to leverage them.

Since I’m a frontend engineer, I wanted to keep the backend as simple as humanly possible—the path of least resistance. I preferred a relational database because I wanted to do as little of the infrastructure and hosting as possible, and I could make small tweaks. That’s how I landed on Hasura. It was recommended to me by one of my co-workers, Braze Staff Software Engineer Greg Beaver, and I thought I’d learn something new, so I spent one innovation token on that.

The last piece was the authentication layer. For that I used Auth0, which integrates nicely with Hasura. Since I spent two innovation tokens on Hasura and Auth0, I still have one left. I haven't decided how I'm going to use that one yet—maybe on the UI or for some additional features. I’ve been thinking about adding payment options and turning it into more of a subscription product, but we’ll see where it ends up!

Final Thoughts

While a lot of people think of Hack Day as an opportunity to work on projects related to the Braze product that they don’t have the time to do normally, I think there’s just as much value in pursuing this kind of passion project. By using Hack Day to dig into my AMT calculator initiative, I had the opportunity to leverage the tools I’ve gotten to use at Braze while also pushing myself to acquire new skills.

Interested in getting involved in our hack days? Braze is hiring for a variety of roles across our Engineering, Product Management, and User Experience teams. Check out our careers page to learn more about our open roles and our culture.