New Developments: Andrew Homeyer (Halp)

Introduce yourself and your team!

I'm Andrew Homeyer, and I was the CTO of Halp. We are a conversational ticketing platform. When you work in a company of any decent size, you have these cross team questions,like, can you help me replace my keyboard if you're talking to an IT team, or even if you're talking to like sales ops, like, hey, can you help me with this order?

These requests used to happen over email, but with today's modern systems it's all through Slack or Microsoft Teams. And once your company starts growing, these things become unmanageable, there's no traceability, and things get dropped. You feel really bad about like, oh, I've totally forgot about your ask. And people just keep sending you DMs.

Halp is that ticketing system that lives inside your chat tools. We had amazing growth in the last year, and then we were acquired by Atlassian. So now Halp is an Atlassian product. It sits alongside JIRA and Trello and Confluence, and our mission is still to help companies of all sizes manage those internal requests.

We are a business of 30 people or so now, so we're still pretty small, but we're growing fast.

How do internal tools help your company grow?

At Halp in particular we care about avoiding undifferentiated, heavy lifting; let's work on what the secret sauce is of our business, right? Like how can we focus on what our customers need, what can we build and solve for them? And that usually does not include internal tools.

We used to not want to spend any effort building internal tools. It's like what's the, the easiest, quickest way for us to give our sales team and our support team the things they need to actually get things done.

What kinds of internal tools does your team build and maintain?

One particular example that happens all the time is our billing infrastructure. We use Stripe for subscriptions, so there's always something a little bit off: this customer needs a specific discount or they're going to need their trial extended, or something weird happened with their renewal. And you have to just modify a few things – you could go along into Stripe that works sometimes. But often times they need to go touch our actual database where we keep our employee records.

Even opening a ticket and having an engineer touch the database – we don't love doing that. Anytime you're touching data, something is usually going to break down the road. So just having a super lightweight system, just give them a text field where it's they have a coupon code, just type in here – that's great. This took five minutes and now it works and don't have to think about it again.

What does your internal tool stack look like?

We're SaaS first. We don't have on-prem anything for Halp. So when it comes to internal tools we just provide access to whatever SaaS tools people need to tie the bricks together.

Retool is really one of the only things that connects them. We have the normal things like Slack, and then there used to be Google Docs that's now Confluence, and just a stack of where we store information and how we communicate. But beyond the list of things every company sort of uses, nothing really.

We don't have anything homegrown. We don't have any internal system that we've built ourselves.

What's the most frustrating part of building and maintaining internal tools?

This is rewinding pre-Retool at a former company. We thought it was so cool to have our own internal tool stack, building a customer health dashboard and tying all this data together. And it always becomes someone's pet project. It's never important enough to get prioritized investment.

It's useful. But the people using it, it's internal customers as opposed to external customers. And it's always a layer on top of like, there's always a different way to solve that problem, but the internal tool makes something easier, but there's always a workaround that might be a really difficult work around, like open a ticket with the data team or something, or just look through Salesforce and you'll find it eventually. So it's hard to want to prioritize it because there's always something more important.

And the risk is there too, right? Anytime you have something that has access to all the data, and it's not something that you really think about, and usually it's hacked together. So it's not following the right security practices. It's just this vulnerability waiting to happen that someone accidentally makes the repo public or someone accidentally commits their read-write database key to this repo or you end up writing these god apps that have access to too many things. And security is often not really thought about with respect to those things. And it's like your biggest hole in your organization. If you don't think about it.

How does your approach differ between internal tools and the core product?

It's changed, right? Do we need this built into the product? If so, how does that weigh against other product priorities? If not, is there an easier way to solve this problem? Can we just expose this through an internal tool?

So we do things that don't scale since we're still sort of in that model of how can we unblock people? Like what's the bottleneck in the business. It might start with, hey, we have a custom script, like a migration that will go do something. We're running this like once a week, let's throw this behind an API, and let's tie this to Retool, and let's give it a button, nothing fancy, but cool it's a button instead of a script and that button can be pressed by a couple more people. And then eventually it's like, cool, we're pressing that button a lot. should this be a feature inside the product that customers can do for themselves?

It's probably time for us to prioritize that and get that actually done, but it lets us make really small investments to unblock the team when there are more important things to work on.

When should you build an internal tool vs. buy it?

We're so SaaS heavy that from the product to Segment, to Workato, to Salesforce, to Autopilot drives a really eloquent customer adoption flow, and that process can be tweaked and modified by a salesperson, or someone in marketing.

So it's pretty amazing that all the developer has to do is say like "cool track this event." And then it gets sent to the right places. And then all these other systems are built on this event bus. That's so cool when you can decouple engineering effort from getting things done outside of product.

How do we enable sales and marketing to have what they need just to go get shit done? So I think that question of like do you build it yourself, like build vs. buy - technically we're building, but we're using building blocks that are no-code type things, where you can hack it together in a way that yeah, it's sort of brittle, but it actually works.

How do you measure your success and improve your internal tools?

I might say we don't really need to. So there are bigger initiatives across Atlassian where we're documenting (this is for Workato) the man hours saved by adopting a no-code pipelines type thing. They're justifying a large expense to have Workato available to everyone inside Atlassian. And so they have to justify that with man hours saved. I think that's a fine corollary for internal tools. I think for us, you're growing fast, you essentially are throwing money at problems as opposed to throwing time at it.

So how can you move faster without intentionally burning money to remove blockers as opposed to spending time to do it the right way. So I think, especially for startups, going back to that idea of work on what's important to you. Yeah. You don't have money to spend it either, but I think that's the same argument of how can you get away with just tying things together.

There's also the rule of threes and tens where your company's whole processes usually change every 3, 10, 30, and 100 people – sort of scaling up that way. So you expect these systems to start to break down at those points and you have to rebuild it anyway, but for whatever stage you're in, if you can hack together and focus on the more critical parts of your business, then do that.

So justifying the cost of internal tools, is more about what's the fastest way to remove a bottleneck, especially on the go-to-market side of the business. And if we can either spend money or do something together, use no-code type solutions to give them what they need without taking meaningful engineering effort, then it's pretty easy to justify.