Man in building Tritium[1] I have always used the analogy that developers would never program in a web-based IDE. Thus, lawyers would never live in a web-based legal IDE either. In exchange for that we’ve paid the onboarding price of trying to get desktop software installed to even run a demo. This is super timely to push us back towards a reality that web may be viable.
Hi Drew, I remember your "Show HN" from a while back and have been secretly rooting for you ever since! (I'm not a lawyer but for some reason I have many friends that are, and now I happen to do work for a firm in the legal publishing sector, so I often hear about how terrible "word processing" can be and think there've got to be better tools!)
May I ask, how are things going? Also, will your IDE always be focusing on transactional law or have you considered expanding to other legal areas and/or markets?
Hi! It's a super interesting time to be in legal tech. Thank you for asking.
When this project got started, "VS code for transactional lawyers" was the target. We pretty well have that on offer at this point, but it sits in a weird spot making it harder to sell than it would be in, say, 2024. Right now, "AI forward" lawyers are spinning out of law firms in droves to start "AI native" firms backed for example by YC. They're so comfortable with Claude that they for the large part bypass a need for Tritium (or at least they think they do ;). OTOH, large law firms are inundated with legal tech products right now and have a hard time even understanding how an IDE benefits their lawyers. We're also trying to stay away from VC funding (other than from a certain awesome one ;), so we're missing a key signal for enterprise buyers. As I mentioned above, it's super hard to even set up a hands on demo because we have to get the desktop app installed on their infrastructure. But I'm shocked to learn that Googlers are happy to work in a browser, and distributing Tritium via browser is trivial, so we're going to 180 on that right here and now.
That all said, we eliminated the "free tier" as advised back in the Show HN thread, and we've managed to find a very small market in individual users. We're also finding some opportunities with the AI natives using an "unreal engine for legal tech" model that makes Tritium source available and handles the boring editor-related parts of their innovation.
I should probably do a post on this, but there's actually a topic we're working on that perhaps the HN audience will find even more interesting... coming soon!
[edit: I realized that I haven't responded to your question re: other markets, but accidentally did with the hint. We have some ideas.]
Wow, thanks so much for taking the time to answer my questions in detail!
> As I mentioned above, it's super hard to even set up a hands on demo because we have to get the desktop app installed on their infrastructure. But I'm shocked to learn that Googlers are happy to work in a browser, and distributing Tritium via browser is trivial, so we're going to 180 on that right here and now.
"Trivial" in the sense you can just compile everything to WASM? I'd be curious to know what such an IDE would feel like in the browser. I think the only WASM-based GUI apps I've tried in the browser were Flutter apps and those were… weird.
> I should probably do a post on this, but there's actually a topic we're working on that perhaps the HN audience will find even more interesting... coming soon!
I'll keep an eye out for the next Show HN! :-)
> "Trivial" in the sense you can just compile everything to WASM? I'd be curious to know what such an IDE would feel like in the browser. I think the only WASM-based GUI apps I've tried in the browser were Flutter apps and those were… weird.
Yes, that's about it. We rely on threads a lot in the desktop version which doesn't map as easily to WASM so there is still some work to do. But if you remember back to the original Show HN post, it was running in the browser there. So we have experience with it.
There is a bit of uncanny valley that comes with using WASM with <canvas> in the browser like we do rather than the DOM. There aren't reflow events in the same way, and frankly it's just a lot snappier than you expect. But it comes with a lot of trade-offs and you're forced to reinvent the wheel if you totally abandon web primitives.
The main thing holding most people back from web-based IDEs is restricted filesystem and tools integrations, but cloud office suites are extremely popular. Google has excellent infrastructure for distributed build and test cycles built into Cider to go along with the entirely remote version control system.
Best of luck on your web-based demos! Dropping people into a working dummy environment with a few tutorial prompts should really help conversions.
> developers would never program in a web-based IDE
That's why 80% of developers use a web based VS Code/Cursor
Is that right? They use the version running in a browser?
I think they just meant that an Electron app is still at least (half) browser-based, just you're shipping the user a particular browser alongside the app code.
I too have been following your talk on Tritium, so that for the past few years as I have been hand-crafting a new open document engine for the web I have had your use cases in mind as ones that I might be able to solve if things went very well. That engine is shipping today and I think things have gone quite well, so I would absolutely love to talk to you about how we could reshape the landscape if we put our heads together. I feel certain that what I've built could be made into a groundbreaking product in the law world, if only I knew anything about law (not from TV)!
Electron is literally the browser Chromium (the open source part of Chrome).
Yes, except Electron apps have the ability to break out of the sandbox because they control it. I take the point that the web stack is used in Electron apps, but it's the other issues, esp. as compounded by cross-browser compatibility that are hard to solve in what most people think of when you say "a browser" context.