51. Tony Thai, Founder and CEO of HyperDraft, Revolutionizing Legal Tech with Engineering Precision

Okay, welcome everyone to the security podcast of the Silicon Valley. I'm here today with a very special guest, Tony Tai, the founder and CEO of Hyperdraft. Welcome to the show, Tony. Hey, John.

Thanks for having me, man. So looking at your background, you've worked in many different jobs in many different industries. How did you end up where you are today as the founder of Hyperdraft? Yeah, you and I met when I was in that last phase as an attorney at a big law firm.

But it all started actually as a software engineer, developing enterprise B2B software in my early 20s. And during that time, I was working with a lot of lawyers and frankly, a little bit frustrated by the feeling that they didn't understand what the business objectives were. Like any self-respecting engineer, I thought I could do it better and just went to law school as a result. When I talk to engineers, like such as yourself and like other folks, like when I say, oh, wasn't happy with the legal service that I got.

So I thought I could do it better. Like a lot of engineers, like that's the most engineering, like engineer thing you could have said. There's just not a lot of people that are wired to go and do something themselves. Yeah, I mean, I went to law school, didn't think I'd practice in private practice, like representing clients like yourself.

Yeah, thank you very much for the representation. Yeah. I was most appreciated. No, people like you, it's one of the many reasons why I stuck around because I was like, oh, well, if I'm facing this problem, then there's going to be a handful of folks like John who need my help.

Might as well help the community out instead of you having to go to law school. So for all of our listeners, just for the context, back in the day when I was a founder at a company called Peacemaker, Tony worked at, where was it? It was Goodwin. And you got paired up with us and you were our primary contact for all of our legal need.

And it was just a spectacular back and forth. And we had to fix a whole bunch of things. We messed up with our founding of the company and we did some patent and Tony was always on the ball. And then, you know what I mean?

Like all in all, like you guys were a pretty like okay case. If we're getting surgical with it or medical with it, like coming with a lot of different cases. I think your guys was pretty routinized. I want to say you came through John Runyon and McCusker, but I can't remember.

I don't remember what partner it was. Yeah. Do you know what John Runyon? No.

Okay. One of the co-founders of Peacemaker, he had worked with someone there before, had lots of good experiences. And that's how we ended up with Jetson. Pretty cool.

But I remember one day you showed up and you were like, oh, I have to share with you some news. I'm moving on. I'm going to do something new. And you made me guess.

You made me guess like what you were doing next. And I just remember thinking to myself, wow, he's so excited. Like there's a little twinkle in his eye and everything. And like just all of this positive energy.

I'm like, you're way too excited to be doing anything except starting your own company. Why didn't you warn me, man? You were already on the side. You should have been like, what are you doing?

Well, I thought you were getting into it. It's the best thing and the worst thing both at the same time. There's no, there's never any like right time to do that. And you just got to pull the trigger.

You just jumped in. And now look at you. This is amazing. Yeah.

I saw how much fun you guys were having. And I'm like, I wanted on that action. Yeah. We started Hyperdraft actually a few years prior.

I started. It was a moonlight bootstrap project. It was. And I don't know if you remember my schedule, but like working at a big law firm was not very conducive to those types of arrangements where you're grinding from 7 a.

m. to 11 p. m. and coding from 11 p.

m. to 2 a. m. It was a passion project to say the least.

But yeah, we started a few years earlier. One of the things that you learn about apparel is insecurity with this, but like one of the things you learn or are trained to do at the law firm is to be risk averse. Right. And they constantly tell you because like our jobs are to help clients navigate risk and reduce risk as much as boss.

If I'm being honest with you, one of the reasons why I didn't leave was like I was so trained at that time to avoid risk. And there's really nothing riskier, especially in a professional like services vertical than to start your own business. And it took a handful of my clients to convince me over a course of 12, 13 months that I should be doing this full time, not half time. It's amazing to have that type of support in your life and surround yourself with people that believed in you and saw the potential in you and in the company and in solving the problem that you're going after.

And that's awesome too, actually, that you came up through the ranks through a software engineering background and then cut over into law a little bit. Yeah. A lot of people look at me funny because they're like, there's just no way you could be decent at both. And it's funny because for me, it's the same thing.

It's just like slightly different context, right? Depends on which hat I have to wear. I'm still a lawyer. I still practice on occasion and I had to put on a different hat, but you still use, try to use at least the same logical patterns when you think through stuff.

So honestly, the coding background was really important for my development as an attorney because having that ability to, or the need to craft logic through code translated perfectly over to doing contracts and deal work and anything requiring legal documentation. So that was helpful. And I would say it seeded concept around the business, right? I'm sure that folks on listening to the podcast that still don't know what we do.

So at HyperDraft, we build dev tooling for lawyers and business professionals. So what does that mean? Like we, we focus on document generation and digital workflows because we found that the legal field was lacking tooling in that space. And as an engineer, we build so many tools for ourselves.

For me, the natural progression was as a lawyer, like I need to build tooling for myself and the other folks in this vertical. I remember you downloaded to me way back in the day when it was an early version of your product. And I remember thinking to myself, wow, now lawyers have an IDE, an integrated development environment. And they could just sit down and they could share snippets and auto-completion.

And it was really, it looked really nice. Yeah. A big time favor. It was.

When I built this software, when we started designing all that stuff, we did ask a lot of lawyers like their input. But the reality of it was, these are tools that most people in the outside world assume that we have. Which is funny, right? Because you hear this common complaint that lawyers bill by the hour and they take too long on stuff.

And that they're being fraudulent with their app. No, the reality is we're just that slow, right? If a contract took a long time, it actually took a long time. It probably took longer than they billed you, frankly.

So I wanted to reduce that because if we look at it, like these lawyers have such amazing raw compute, right? And not to objectify them, but they have such amazing raw compute. To spend their time on so many like small, tedious things, not that it's not important, it's important, but to do it in a more streamlined manner, like that's going to be key to apply that raw compute to stuff that matters rather than just the mundane. Yeah.

Yeah, absolutely. And so as you've built out this product, I'm sure you've gotten a much wider view of the legal community in general. And I'm really curious to hear your insight of what sort of relationship do you see that cybersecurity has with legal? Yeah.

Just before we started, like I was talking, I mentioned one of my good friends and former colleagues and an advisor to hyperdraft is a guy by the name of Steve Singer. He's currently heading up LegalZoom's InfoSec. We met when I was in-house at this private equity portfolio company and we hit it off like immediately. There's a ton of overlap now.

I'll tell you the story or the few stories that he would tell me. As a corporate attorney in-house, one of the things that we're taught is, and we like to remind people, is that if we're doing our jobs, you're not going to hear about this. Right. A corporate attorney should be not non-impactful, very impactful, but in the sense that if they're doing their job, then risk is being avoided.

So you're not hearing about them and their work that they're doing constantly. Same goes for InfoSec, right? The same goes for cybersecurity. If the job's being done correct, you're not really going to hear about it.

And that causes a lot of issues because that's a surefire way for business units and certain stakeholders to take for granted the need to have those teams, the need to have the tooling, the need to think about the objectives for those teams because they're controlling for risk. So you don't really need them until you absolutely need them, right? Whether you've got a security breach or you've breached some sort of agreement, right? You don't need them until you realize, oh, crap, I'm far out of my depth in terms of the potential downside for the risk that this may create.

So in that sense, just from a perspective of attack surface, like we share a lot of the same kind of risk management and neglect from businesses, frankly. Yeah, I get that. And it's almost like one of those thankless roles. If you're doing your job really well and you're staying out at the neutral for the wrong reason, then there'll be no breaches and companies that you're servicing or legal conundrums in the legal space.

Very quiet. You're not a high visibility. Yeah, like we said that until it goes wrong, right? Until it goes wrong.

And then when it goes wrong, like it goes south, it goes very south. So when it goes south, what sort of what sort of cars are you seeing drive down that road as things go south? Anything specific in the right there in hyper draft space that you've noticed? Yeah.

I actually, a lot of what I should have could is, you know, I'm sure like you're rolling your eyes and people listening are rolling their eyes because it's in many respects. One of our jobs is to be the paranoid people. To say that, hey guys, like we should really worry about this. But one of the things you pick up over time and with experience is to avoid the cry wolf syndrome and to pick and choose when to say, hey guys, now's the time, right?

Like that's a particular issue. For us in the hyper draft world, I've learned a lot through the process as well. You mentioned us as an IDE and we really do truly think of ourselves as the IDE and digital workflow systems for these large enterprises. But that's from the provider perspective, right?

From the demand perspective, it's actually something that I've learned over the last few years running this company. It's like sometimes clients come to you and they don't know what they want and they don't know what they need. So they think that they can purchase a solution that is going to be the silver bullet for solving their either compliance issue or security issue. But in that respect, it's really just a point solution in the sense that it's a point solution in time for a particular demand, like pain point at that particular point.

So with the hyper draft tooling on a legal side, like a lot of folks come to us and say, hey, this is what we think our problem is. And then as our team digs in deeper, realize, actually, that's not the problem, right? Your problem is you have no process. So lack of software, lack of productivity and streamlining, this is not necessarily the problem.

The problem is you lack the discipline to set in place all these plans and procedures for how to send a contract through, how to mitigate risk, how to evaluate risk through that pipeline. And we can help with that, but software is not going to do that. But there are plenty of platforms that do claim to be the McAfee of contract generation and workflows. And what I've learned over time is just to tell them, like, give it a go.

If somebody is going to argue with you over like using an out of the box solution versus actually spending the time to evaluate the problem set and figure out different operating procedures, they've already have their mindset. And so you wait for them to make that first mistake and then hopefully it's not fatal. Right. Hopefully it's just a lesson learned and you can move on with it.

Exactly. So in terms of folks that are using hyperdraft, what industries do you see are most common? There's different types of law you to attract a certain pipeboat use case maybe? Yeah, we serve like we're pretty industry agnostic for the most part.

However, we have found many companies in finance, real estate and healthcare have come to us because they have particular needs. And actually, this is where the great crossover for our industries, which is they need something hyper customized that's very complex, but also needs to be secure and in a controlled environment. And for us, that's our specialty, right? Coming from enterprise development background, like I started this with enterprise in mind.

And so those industries have those particular security and kind of complex deal needs. And so we found ourselves servicing a lot of those folks. And frankly, we turn away probably more work than we take because some clients come to us and like I mentioned, they don't really know their problem set. And there's no use in the overkill of the hyperdraft platform for some folks.

Like many folks can just get away with mail merge, right? Like just spend a few hours learning how to do that and we don't have to get involved. And yeah, we get hit up by everyone. But yeah, I'd say that just three folks are vertical.

Finance, real estate and healthcare. Nice, nice. Your go-to-market strategy is, it sounds very bottom up with people trying it out, maybe coming to you or is it a, what's your go-to-market strategy? Go-to-market strategy is actually more top down than anything.

Because yeah, it's more top down. It's at an enterprise level. You need purchasing power, not only that, but you need purchasing decision-making power. So usually it's a department that says, hey, we have X number of agreements or deal types.

We're too slow. Everything's being done manually. Great use case. And this is probably further on the, like the edge case.

We had a client that came in, they did term sheets and these long form agreements. Term sheets would take them eight hours. And then the long forms would take them anywhere from like 20 to 30 hours. Everything done manually.

And for them, time is money, right? For every one of those contracts that's not going through, they're not making money. So the head of that department came to us and said, pay you guys to make this faster. It doesn't even need to be perfect.

It just needs to be faster than what we currently do. And so we cut down the time from eight hours down to 15 minutes for that term sheet, which is insane. Like an insane improvement, right? Just from a period.

That's huge. You're getting a big payback for every single term. Yeah. Well, get a kick out of this, man.

Like from the 20 to 30 hours it took for the long form agreements, like we cut that down to three hours. And that three hours is mostly just manual review of the stuff that needed to be done, could be done in an automated fashion. And this is where the lawyers that bring all of those superpowers to the table can focus on their superpowers instead of like cart around or putz around with their mundane bits that are important, but that software can help with and that you can reuse maybe. John, I'm actually curious about your experience here, because let me describe to you the lawyers scenario.

And I think this, I think the InfoSec cybersecurity is similar. I'm putting on my lawyer hat now. When you're a lawyer, your clients don't really appreciate the amount of work, like technical work that you do. So like when you and I were talking, I could be wrong, but you probably appreciated me more because like we would jump on a phone call and I'd talk you through it.

And I'm enough of a business person that I know, hey, this is what John wants to hear. And frankly, like if I'm John, I don't want to hear this and this, like I'll take care of it. Just controlling for that messaging. But I'd go back and stay up all night getting your deal docs done.

You didn't know that. You weren't sitting there with me. And what we're trying to get lawyers to do more of is it's not that you're just losing all that time, that 20 to 30 hours that you're losing worth of quote unquote billable work. We want you to spend that time now working with the client, understanding their needs and talking through with them.

Like, how do we see around corners? Right. Okay. So we've done these deal types.

Like how can we make this more streamlined? How can we anticipate risk? Where have we failed before? Those are quite, those are statements that not a lot of lawyers are willing to have with their clients.

Right. Like I'm very happy, like not very happy, but willing to sit down with the client and be like, all right, John, let's do a postmortem on this last deal that we did. What did you think that we did well? And then what did you think that we did that you'd like us to change?

I'm not crumbling that we might change it, but I want to hear it. And that's not something that like a lot of lawyers want to do. But the reality is the value proposition and their skill set, the clients greatly benefit from those types of interaction. Yeah.

I'm curious if that's the same on the cybersecurity side. No, it's definitely on the cybersecurity side. And it resonates a lot with the industry in terms of the evolution that I've seen and just how to write software, how to build software. At first, in the beginning, it was very just like waterfall design model.

You get into the grind, you just turn out code and you, it's very disconnected. But now, like with agile development, everyone is talking to each other. We're doing postmortems. There's incidents that happen in the cloud or in your data center.

You do. You want to go back and you want to revisit those things. And there's much less time, I would say, banging on the keyboard and much more time spent engaging with each other. And so there was a natural evolution, I would say, in engineering.

It sounds like it's nudged in that same direction in the legal space. And I think that will result in better uses of folks' time, better products. It'll help folks see the bigger picture. And I'm a firm believer that when people see the bigger picture, that you can trust and you can delegate and people can help you solve really hard problems.

Instead of having to get in there, having to micromanage everything, having to, quote unquote, like not trust folks around you. You do want to trust folks. You want to surround yourself with incredible talent, but you want to help them understand the big picture so that they can contribute to that mission without you having to be part of all of those little nitty gritty. That's why I really enjoyed us working together because I felt like you really got that.

You saw that. And you didn't need the tools to help with that. But one of the issues is if like writing documents, writing code in an engineering perspective takes so long, there's not a very good motive to move into that space where you talk to each other more. It's communication.

Yeah. And speaking of the overlaps between the two worlds, maybe share with us a little bit about what makes hyperdraft approach to cybersecurity and the resulting legal issues unique. Yeah. I worked as a lawyer for so many different clients and seeing the security breaches or sorry, security incidences.

Security. Um, security incidents. Yeah. Allegedly.

Security incidents. Yeah. Possible. We mean.

Yeah. Yeah. Allegedly some actor took our. I understand the need for InfoSec's role in so many different deal points.

And for us, we're, when we're talking about proprietary information, if you're working with the business, what's more proprietary than like how they make money. Right. Like the contracts that are down to how they make money and the strategy behind it and what they need to do and the negotiation. So there needs to be a lot of trust in systems that they're not sharing that data, leveraging that data, leaking that data.

So that I would say that first and foremost, that's a main concern for a lot of our clients. And one of the reasons why we've been successful is because I had people like yourself to look up to and Steve Singer, who I would hold on a lot of these things because their perspective is InfoSec, like legal, like hyperdraft is the first line of defense. Right. Right.

It's only a first line of defense. Having a good, strong first line defense. That's a good thing. But the rest of it is around communication, training, and trusting your colleagues and business units to do the right thing.

I would say a lot of our successes in terms of winning over clients and having clients pick us over competitors is our approach to solving the problem. It's so cheesy for me to say, let's really, truly in the team and architecture. There are other solutions out there, plenty of other solutions out there, especially in the doc gen space that claim to solve, especially in the contract management base, which I'll be honest with you. Nobody's been able to explain to me like what makes their contract management special.

That's like you telling me, Hey, Tony, like I've, I have 50 different replacements for GitHub repos. And you're like, that's cool. I don't see the need for it, but sure. And so like we take it with much more like GitHub and GitLab type approach to it, which is let's look at the use case.

Where are their problems? How do we solve it for them so that they have immediate value proposition to them? At the same time, look after them and figure out how they can control for security risks and legal risks. Yeah.

I don't know if that was a good answer or response to your question. No, that's no, that's perfect. It's you bring to heart the, what matters to your customers and what matters to your customers. It sounds like a big chunk of it is cyber cybersecurity and the approach to actually solving problems and delivering value right away.

Tony, you've noticed no doubt that AI is exploding right now. Bubbles or new technologies and things that I probably people have thought they'd never seen in their lifetimes. And it's accelerating at a rapid pace. What type of AI features do you guys offer to your customers?

Yeah. We have seen the kind of boom of AI features as we're one of the OGs, right? Like we did this before the hype. You can testify that part.

Absolutely. Our AI features are similar to what's useful for the engineering space. I think of it like completion. Co-pilot.

Auto-completion, yeah. Co-pilot, type of generation. And I was actually hoping to transition to this because the same security risk that is evident in AI driven code is also a big issue in legal. So we are hesitant to push AI heavy products.

Something my CMO and I talk about all the time is it's often touted as a product. It's just a feature, right? The assist and the ability to work in a more streamlined fashion is a feature. It is not a standalone product.

And again, I would say that our customers come to us because we understand the data and we understand the business practices and the legal models for how it works. Not because we claim to be able to replace their headcount with AI. I think that's, so that's a lead into my next question is what's the impact the AI advancements are having on the legal industry as you see it? Does not replace the headcount.

I think it's still pretty early to tell. Let me tell you it from my perspective on the coding side, right? And like I still code. I use Co-pilot.

It's incredibly useful. Much of the time, it's 60, 70% of the time. But as I use it and I see our junior engineers use it, I reviewed their code and I'm constantly reminded of the difference between a senior engineer and a junior engineer. The thing that it can't place is the time and experience that it takes to learn what good architecture, what good patterns look like, thinking ahead.

And fortunately or unfortunately for the legal profession, like time still needs to be spent learning different mental models required for their practice. There's just no surrogate from that until Neuralink or one of these other startups can inject knowledge into our brains and basically train the neural pathways without, without us having to actually experience any of this stuff. It's just not going to happen in the sense of, oh, we can completely replace. It can augment.

It can help streamline people like myself who have over a decade of experience. And so we already know where we're going with it. We already know how we're architecting this contract, this deal, whatever legal document that we're dealing with. It's not going to make, my view of it is it's not going to make that big of an impact.

It'll expose probably way more of the weaknesses for folks that have been able to hide behind just doing the road work. But I don't think it's going to really upend that services arm. Yeah, I totally see that. I think that all of these LLMs and the code completion models that are out there, they're another tool in our toolbox.

Just like an IDE didn't turn a junior developer into a senior developer, but it is a good tool to help save time, to help save some money, maybe ship some code faster, maybe find some bugs earlier in the process rather than later. And I see LLMs and all of these new models and the advancement as another tool, not here to replace people. It's here to enhance. You use the word augment.

I like that word. It's a good program. In the security space, I grew up with the, as a hacker. And we've talked about this before, like hacker had a different term back then, like hacker is someone who likes tinker.

Like these days, I think they're more like DIYers or stuff like that. But I do think about it from a, like a, how do I break a system type of perspective? If I was a kid, I would be wet in my chops seeing all these folks try to build APIs with LLMs. I think that is one of the dumbest things I've ever heard.

And especially from a security perspective, like I could think about so many different attack services when we're introducing prompt engineering into API endpoint calling and payload formulation. I'm, this is like basic stuff that you learn as a security professional with command injection and stuff like that. Now they're just opening it up for you and just saying, Hey, actually you can send any prompts. We're going to try to use our LMs to, which is a probabilistic model to interpret what the end, what the API call is supposed to be.

Here's some dice. It's on physics. It's the difference between the probabilistic super small particle science. That's the all probabilities versus like the Newtonian stuff, which is pretty sad.

Both of those worlds. Like that perspective. Yeah. It's different.

Yeah. From a high, we see it too. In a sense that maybe we'd take it more on the development side, but like at the end of the day, we've experimented with a lot of these, you know, newfangled tools only to realize, nope, we're still gonna have to do work. It's a, it reminds me of being a kid and reading cliff notes.

I don't know if you remember that. Oh, I remember that. Yeah. Yeah.

Yeah. I mean ginormous or read just a couple of things. Just. Yeah.

Yeah. Now that I'm older and understand how this works a little bit better, like there's only so much information you can get from an abstraction layer, right? There's only so much you can get and to have utmost trust in coursework based on, on, on cliff notes. And maybe some people were listening to like, I did great with cliff notes.

Screw reading. Oh, all right. Yeah. You realize over time that even if it saves you time, like it, it doesn't eliminate the need to, for someone to have reviewed the code or reviewed the contract thoroughly.

And not only just review, not only just review, but understand why it's bad. Right. Right. If something that I try to remind people this, everybody thinks AI is going to drive everyone to the right side of a curve.

That's not how big data works. Yeah. You've got, you, you, you've got the law of big numbers and regression to the mean. And most data is garbage and most public code is guess what garbage.

And what's being pumped out to you unless it's fine tuned. And in, in, in many respects, like coding much like legal work, it's subjective in many senses, right? Everyone's got a little bit of a different style, a little bit of a different pattern. It can't be relied on for high quality work.

It just can't. You still got to rely on people to understand that overall architecture. Yes. Both in software and in.

Yes. Yes. What have you learned from your experience from building hyperdraft? So many things like just a top, top item.

The one big one. Oh, you'll never do something again because you learned this or you'll never do something the same again because you've learned this thing. I learned this recently, like embarrassingly. It actually had to do with something we were architecting and we're proud on our software architecture.

But when I originally started the business, the thought was like delegate scale, right? Boy, was that a mistake, man. Like architecting a solution with the intent that you can delegate certain portions because somehow you would be able to scale faster is such a mistake because you end up paying for it or somebody pays for it down the line and end up redoing the work twice. And it's not to say that you can't architect stuff where you can build it as a team, work on it as a team, but you should never build or design with delegation in mind.

You have to understand from the ground up how the system works and that will build a more robust product and more robust architecture than thinking, oh, somebody else is going to handle like the little gritty parts. So it's a bit more abstract, but yeah, I don't know if that resonates with you or no, it totally does. I've been bit by that once or twice. Like thinking like, oh, I'm just going to, here's a little thing, a black box that inside side can just push over here.

And then the thing that comes back is not a, doesn't fit the bill. Maybe it, it, it did by the API, but how it did that underneath the hood is no way it's going to possibly scale past, no, a thousand or can scale it horizontally or need vertical scale or all sorts of little, God, or like the instant. And you're like, no, why is there state flying around as you could have been stateless. Like if we approach it the Southern way, I've seen that once or twice.

The, now that you've brought up physics, which is one of my favorite topics, like I'll bring in two concepts, right? One, you can't create energy, right? There's always a lot of thermodynamics, right? Like the preservation of it.

And so if we're taking shortcuts, we're paying the price somewhere, somehow, right? That's it. And then as I remind people with cryptography all the time, the strength of cryptography is directly proportional to the amount of energy put in directly. So if it's didn't take that much compute, didn't take that much time, then the security is lower.

That's just how algorithms work. That's just how it works. Yeah. So if you think about that with any task in life, if you take a shortcut, you're going to be paying for it somehow, some way.

Things are okay with that. And some things aren't. Yeah. I also, even with all of that in mind, keeping that top of mind, I also will always try to bring a sense of understanding, maybe even a sense of like compassion or empathy towards decisions that were made in the past that were maybe the right decision to make in the past.

That then you get to a huge success. 100x. And then everyone feels warm and fuzzy about the success that you've had from the point when that decision was made. Because if you had made a different decision, the company could have gone into a different direction.

Because maybe you spent way too much time solving something that didn't really need to be solved yet. So just having compassion for ourselves, I think is like super important for mental health. I laugh about it because so often like the engineers, when we go through the code, they'll see comments. I comment a lot.

That's why people ask me how engineering has influenced my legal skillset. Seldom do people ask how my legal background has influenced my engineering skillset. I write a lot of comments. And the fun, like the funniest ones we run into are ones where I'm like, note from Tony.

I know this is stupid. Right? Like I like guys, I like, I know we're going to fix this. And if you're the one, I'm sorry, I owe you a copy.

There's plenty of those in the code base. I was, I saw, I remember I saw one that I wrote. I wrote a line like three years ago. It's like a throwaway line.

I didn't think we'd look at it. So I'm reading through the code. I think a lot of people can relate to this. I was reading through the code and I'm like, what piece of crap, dumb person wrote.

And you click on it and the Git blames at Tony Tai. And it's just like, oh, crap. Yeah. It happens all the time.

It's pretty funny. It's very funny. Yeah. And with Git, there's no, everything is accounted for.

It's right there. You can go back. You can even look at the message that showed up with it. What was happening back in the day without like the thing.

Listen, you said you give people kind of room and empathy for having me decision at the time. Like I do the same. And so we've grown, right? Every day that I'm writing code, I'm getting better.

That's why LLMs are not going to replace humans. That's a hot take, brother. I'm in agreement with you. That's a hot take.

But apparently, I don't know why, but yeah. Well, because you're going against all of the grandiose visions that the bubble have. It's the religion of the moment. Again, I may jump on board.

You're a heretic. From an actor perspective, there's so much in me that just wants to mess with all these different systems. Because I want to be the guy that needs misinformation, right? Like that would bring me so much joy.

I saw one recently that was that really got me going. This is the intersect of the two. There was a car dealership. Have you seen this?

No. A car dealership that had a chat bot. And with prompt engineering, one of the users was able to get them to offer him a car for like 100 bucks and agree to the deal. And I'm thinking to myself, I'm like, he did it as a joke.

Imagine. Just imagine the possibilities of like how much access to a system you can get. Could we do that with a house in California? This would be down for that, man.

Okay. Okay. What do you think the impact? What would you like the impact of the technology that you're building in HyperDraft have on the greater, the bigger picture and the legal community in general?

One of the things I mentioned earlier was I want lawyers to spend more time with their clients. I know it sounds weird, but one of the reasons why we want people to save the time is to spend more time in their community, talking to client, talking to their network community, whatever it is. Because I think that's where the real value is. There's only really what I consider two really human practices, right?

There's the medical field doesn't get more human than that. We're maintaining the body. We're focused on the body. And then the law is social governance, figuring out what binds us, what responsibilities we have to go through on the day-to-day.

As the work has gotten more grueling, more technical, all that stuff, I feel what I've seen is a detachment between the lawyer, what used to be referred to as the counsel. You know, that's why we refer to lawyers as your counsel. We moved away from that to technicians. And we'd like to bring that back because I think we can solve a lot of problems with the raw compute of a lot of these brilliant minds.

We're stuck in the mire of doing the day-to-day and not thinking about, nor should they, thinking about how to remove those bits so that they can spend more time with their clients and other people. Yeah, I love it because at the end of the day, it is always a people. And it's actually a litmus test that I use every once in a while. If I find myself doing something, then I can't very quickly articulate or convince myself that I'm improving the life of a fellow human being.

And it doesn't even matter if that's like a fellow engineer, a salesperson, a customer, or even my future self. Myself as a human being, too. My future self. If I can't convince myself that someone's life is good.

Yeah. Yeah. Okay. Okay.

I'll take that. Yeah. Okay. Well, I stop.

And you have to always make sure that the things that we do are connected back to a human, right? Even if you're in the code and you're engineering and you have to make a decision about do you use a signed int or an unsigned int? And our non-technical readers are not going to understand what that is. But it's just a very nitty-gritty technical thing that no one ever thinks is going to have an impact on someone's life.

But you actually could. And you actually can. And if you can't see the connection between those two things as an engineer, just slow down and see the bigger picture. Can I tell you?

I'll tell you just a quick anecdote on that. Because we can be taught stuff all day long. But until you make mistakes, I truly believe that until you make mistakes, those neural pathways aren't really that embedded. Because I've been warned about all this stuff.

That's right. When I was a very junior engineer, I'm saying like very early 20s, I was working on this finance system. When you're eight years old. Yeah.

Okay. All right. Yeah. I'd be surprised if you were interested in an eight-year-old with the system.

But I was working with like a big accounting system. We're transitioning over from one system over to something that I was working on. And did all this testing. D-Day came, transferred over the primary interface to what I built.

And immediately we started running into issues. Like records were not going through. Numbers weren't adding up. And I was scrambling.

This was like one of my first jobs. I was so stressed out. And then just going through the records. I'm like, this isn't, this is financial system.

So when I said I'm going through records, there's 10, 000 records going in a minute. It's not like I can just sit and go through all of it. And this is way back in the day, right? The arkham sheets flow.

Stay up all night. I finally figure out what it is. Users are typing in O instead of zeros into these fields. So I'm excited that I feel like I've solved the problem.

Go to my boss at the time. And he just chews me out. And I'm looking at him like, dude, it's the users that are stupid. Like I'm not the idiot.

And he's just like, your job is to anticipate stupid. Your job is to anticipate humans. Like developing software is for humans, not for other robots who know the input. And I'm thinking to myself, what's an O instead of a zero?

Like what's moron? And he was right. And so ever since that point, like I took to heart, like it's my job to protect against stupid. And like clients are stupid.

No, it's really just ignorance, right? Like my job is to protect against ignorance, both on the legal side and on the software side. So yeah. Anyways, I forgot how we got in that point.

You're talking about building for humans. Human and humans. Yeah. Humans are what matter always.

100%. No, I like that. I like revisiting like old stories. And speaking of revisiting, if you could go back and visit your younger self, two questions.

Would you? And if you, would you have any advice for your younger self? I would slap the crap out of myself. Someone for self-compassion?

Oh yeah. Not for myself. I'm a dumbass. Okay.

I've said before, or I've been asked this question before in like smaller circles. And one thing I've always said is listen more. Like when you're young, like you're always like, you're always gung ho. You always think of the right answer, all that stuff.

And I like to think that I picked up on listening more earlier than most. If I'm going to give myself some other advice, it'd be something that I constantly, I still work on, which is like compassion and not having more empathy and compassion around like other people's perspectives. But not everybody thinks the way that you do. And I think for me growing up as a kid and also as a professional, like I constantly thought that people wanted to operate the same way I did.

Where did you grow up? Where did you grow up? I grew up in Garden Grove in Orange County, California. So in SoCal here, and then family moved out into the Inland Empire in Rona.

And then from there, honestly, like I would say home base for me feels like and has been play. Cause I went to UCLA for undergrad, which is in Westwood, part of LA. And then I went to USC for law school, which plenty of people give me crap about, but why do they give you crap? You know, are you not familiar with the, I don't know.

My stereotypes are not very good. They're a whole thing. They never give them. There's yeah.

Yeah. That's the third. Okay. Great.

That's one of the stereotypes. UCLA, USC are like crosstown rivals, like in a fun way, in a fun way. But yeah, back when both football programs were excellent. Yeah.

There's, there's a lot of rivalry between the two. So we were called turncoats, right? There's a name for us. Like anyone that converted from UCLA to USC.

So. I see. Kind of what happens between Minnesota and Wisconsin. And as far as Minnesota's are concerned, anyone that lives in Wisconsin or identifies as Wisconsinite.

Is it chief? So. I'm not good. We say that with all of the love in the world.

So. I'm sure turncoats are labeled turncoats with all of the love in the world. I'm sure. I'm sure.

Yeah. Yeah, exactly. So we've had a lot of entrepreneurs actually that listen to this show. And this is a little bit of a leading question, but I was super curious to hear.

And I'm sure some other people might be. If there is one pain point that you just wish someone would step forward and solve and knock it out of the park and maybe build a company around. Is there any pain points that you have that you see over and over again that you would definitely pay money to have just disappear? First off.

The lawyer said was why I went to law school. The full. Yeah. You are very engaged in solving things.

Yeah. I think we are solving for one of them. I would say just because we just passed a tax, the tax deadline. Man, I think accounting systems are still broken.

It's. Oh, I hate that. I tried to use like all of the standard solutions. I don't even want to say their names and nothing integrated with anything else.

And I had to do it all manually again. And then I heard the IRS is now farting around with some trial to allow taxpayers to submit simple taxes directly in, you know, digitally, directly to the IRS instead of going through TurboTax or some third party like service or something. It's so broken. The fact, it's definitely a broken system.

We know the rules. We got to play it. The thing that bugs me is that we wait until the end of we wait for this like climax point where all this stuff has to lead into filing the taxes. Like I was literally thinking about this the other day.

I'm like, this is just monthly hygiene thing. Right. Like, why can't I just update something every month? And then April is just another month.

Like, why does everyone wait for me to collect information? And our stuff is more, obviously a little bit more complicated than a simple filing. But I think a lot of founders feel that way because like they've got their own investments. They're taking they have to worry about their taxes for their company.

It's a complicated affair. And like also have another business to run on the upside. So I think a lot of founders can relate to accounting systems being like crap. And that whole if you ask me like, oh, once you solve the legal one, where did you go into next?

It might be accounting math. It might be the fact that Jesus, this should be way more binary in terms of decision making than legal. Like, why is it so difficult? Yes.

Yes, please. Yes, please. I'll second that one, actually. Tony, this has been an incredible conversation.

Thank you so much for your time. Great discussion. I'm your host, John McLaughlin. And thank you to all of our listeners as well for tuning into another episode of the Security Podcast of Silicon Valley, a YSecurity production.

And please stay tuned for another episode. Tony, it's been amazing. Thank you, BlackWise, brother. Thanks for having me.

Thanks for joining. Thanks for joining. And thanks to all of our listeners again. Oh, and just a quick plug.

Like, if folks are curious what we do and are interested in learning more, they can check us out at hyperdraft. ai or any of our socials under hyperdraft. Hyperdraft. You've heard it here first.

Thanks, Tony. All right. Thank you. Thanks.