Ben:
Hey, everyone. Welcome to PodRocket. Today I'm here with Matan Mishan the co-founder of Livecycle. How you doing Matan?

Matan:
How are you, Ben?

Ben:
I am great. Really excited to learn about what you're building. So could you give us a brief introduction to what is Livecycle and how does it help developers build great applications?

Matan:
For sure. Our main mission is actually to make developers happier and just eliminate a lot of the friction and the feedback loop they have with other stakeholders in the organization. So Livecycle is a real time collaboration platform between coders and other stakeholders.

Ben:
Got it. So real time collaboration, coders, other stakeholders. What kind of other stakeholders like product managers, designers, folks like that?

Matan:
So what we do is we actually, we automatically build and share in an ephemeral environment, per commit, and we add on top of it no code orientation layer. So utilizing our no code orientation layer on top of this environment, it's relevant for a use case of a product review by a product manager or a design review by a designer or a QA person. Also, we are having customers that are using it for copy editing and stuff like that.

Ben:
Okay. That makes sense. So basically, I make a change to my site, let's say, push that commit. You integrate with GitHub and then grab that commit, build it, host a preview and then allow other people on the team to write notes on it, or can you take visual notes on the screen, when you're looking at this new build... Can I circle things and stuff like that?

Matan:
You can circle things. You can also take a video capture. We'll also record the session behind the curtains. There's a tool called LogRocket that are doing it the same way. And also I'm going to add on top of it that we're adding more invasive ability that is actually allowing you to change the copy in line or to change some asset structure in line. So instead of me, let's say you're a developer and I'm a designer. Instead of me telling you, "Hey, can you shift this right? Can you shift this left? Or can you change this copy?" I'm doing it on my own. And then I can create a discussion inside Livecycle with other peers. "Hey, what do you think about this new copy? Is it good? It's bad?" And all of this is happening without developers involved. So we're not interfering with them, no context switches, no meetings and stuff like that. And we all know engineers love to be working on stuff and building and not interference.

Ben:
So if I go in and I change the copy, let's say, can I then make a commit with that change and propose the change? Or does it have to... It's more like a suggestion then an engineer would take and make the actual code change and push a new build.

Matan:
That's a good one because our users... We were early stage so we were speaking with our users, "what do you prefer?" And they said that if you, we would create a commit on our behalf and actually push it to production, it's going to be too intrusive for them. So what we're doing is actually we're, mimicking a comment mechanism or a code adjusting mechanism on GitHub or GitLab. And the coder is just, he's able, or she's able to make sure that he has all the context and make amends with the change.

Ben:
How about for a design change where it's one thing to maybe change the text in an <h1>. It's another thing to say, "let's move this box or switch the order of your elements on the page." It's a lot harder to know like what code would need to be changed there. So how do you figure out how to go from a suggested change to the actual suggestions in the code comments?

Matan:
That's a good point. We're not covering all of the use cases in all of the edge cases. We're starting from similar common use cases. And as we go and as we grow, we're going to do some more deeper integrations in this sense. There are some cases when all you need is a developer or is an engineer just to understand the context. So we're giving them the full context and they're able to just change easily.

Ben:
And is there any element here of gathering feedback from users? Like if you have beta testers or folks using your products, do you see your users using Livecycle to show them previews and have them provide feedback?

Matan:
So one of the best things that I see, and I'm biased for sure, on Livecycle is that we're not enforcing the structure, right? We're actually allowing you this ability to have this time travel machine of all of these versions. You can share them, you can share them as a salesperson to do a pitch as a demo, and you can use it on a specific group of beta users for them to share their feedback on top of it and think back their feedback. That's up to you as a user.

Ben:
I'm curious to learn more about... You mentioned this session capture, obviously session capture very near and dear to my heart here at LogRocket, so curious to learn a bit more about what you do there.

Matan:
We try to be novel, but also we're not tackling the same problem as LogRocket because the amount of users that are live on the same environment are several or tens of people, tops. So what we do is we use some techniques that we've developed internally, and also we're considering to use several open source repos, whatever gets us to the best user engagement and the best user metrics. That's the most important part. The reason we're doing it is that sometimes you can't deduce what happened wrong or what went wrong, and you have to see the session and with the session, we're going to add the context of the logs and the network calls and stuff like that.

Ben:
Yep. That makes complete sense. So basically, you send out your app for your teammates to try to provide feedback and if they run into a problem, then you have the session replay, the capture to capture, to see exactly what went wrong...

Matan:
Exactly.

Ben:
...Or how to reproduce. Certainly a use case that we hear here at LogRocket as well.

Matan:
Yeah. I'm positive

Ben:
I'm curious... this is maybe really getting into the weeds, but when you... Let's say I send out a preview of my application and a couple of my teammates leave a bunch of feedback on the visual of that. Is there a way to preserve that feedback if I then push a new version of my application with some minor changes or is the feedback tied to a specific commit of my application?

Matan:
So the way we see it currently is that the version itself, is decoupled from the feedback mechanism. So whenever you do a new commit in the same PR, even in the context of a PR, you do a new commit, the version will be updated. And also you'll be able to see the state of this feedback item. Let's say this feedback item is stale, or it's resolved. You'll be able to understand the context because you don't want to give the same feedback over and over again. So we preserve the state of the feedback items until, for example, the PR is closed and merged, and then you can... we have other environments that you can hop into.

Ben:
Do you know the state of... do you have a way of knowing if someone pushes a change that fixes a piece of feedback? Can you tie the feedback to a part of the UI or like a dom element, a react component or something like that and know automatically, or it's up to the developer to mark what is fixed...

Matan:
Currently it's up to... it's manual by developer, but we're thinking of novel ideas of to make it more and more automatically.

Ben:
And I guess in similar question, let's say people leave feedback at certain visual parts of the page and then a commit adds some new element that pushes the content down on the page. Do you tie pieces of feedback to dom elements or is it like just an offset from the top of the page? How does that coupling work?

Matan:
So there are different types of feedback items. Some of them are not related to an element. So there is no sense in terms of tagging them or pointing them as something out there. And for sure the app is going to be different as we go. But for very specific elements, let's say copy, or margins on elements or selectors and stuff like that, so, you can hook them inside this element and map out this change. Hope it makes sense.

Ben:
Yeah, it does. I'm curious, I know a lot of tools out there like Netlify or Vercel do you have the functionality of when you push a commit, they build and host that version at a specific URL. Is there a way to use Livecycle in the case where you already have workflows built out around those tools?

Matan:
That's actually something we're going to tackle really soon. We see ourselves as something that in cases that you don't have any solution internally in your team, we're buying the whole pain point from you as a team, but in cases you have something which it creates for your similar environment for your stack. Then for sure we can be on top of it as a solution that adds the feedback mechanism.

Ben:
In that case, would you have a JavaScript library of Livecycle that you add to the development build of your site or something like that?

Matan:
That's one of the alternatives we're currently considering, but I do want to emphasize that we're building a more complicated [inaudible 00:10:15] a stack than indicates a jam stack. So that's where we shine. And when we want to bring value developers, when you have a really a containerized app or mostly containerized app, then you want to bring everything that speeds up this environment. And this is what we support is the most common use case of ephemeral environment for a more heavy stack.

Ben:
So tell me a bit about your progress. I believe you're in beta now. Do you have users? How are you acquiring users, curious a bit more kind of on the growth and the business side and where you are there?

Matan:
Sure, sure. So we're currently in beta and I'm pretty excited because we're going to be offering our solution as a self-serve solution really soon. It means that anyone can just jump on board and try it out. And what we do currently is we really appreciate working closely with beta customers, for them to share their feedback and the use cases and learn from them. And I'm sure you're familiar with the process. And from the moment we're going to be on a self-serve solution, it will open us to friction with the market. So in terms of go-to-market, we're going to do a bunch of exciting stuff. We're also big believers of community and blogs and content generation and the open source community to contribute over there. So we're planning a lot of really interesting stuff here.

Ben:
And I believe you recently raised some money. Is that... Anything to share there? Is it still... kind of the exact details are under wraps?

Matan:
We did a sit round at somewhere in April with VCs, from both the valley and Israel and some angels or private investor that were super humbled to have on board. They're constantly helping us out. So we're feeling like we're back as we should. And I got a question today that from an interview I got like, "so are you going for the round egg?" So we're currently heads down on the product. We're heads down on moving forward with the value of the generation. And that's the main premise we want to achieve.

Ben:
That makes sense. It's always... Everyone's raising tons of rounds nowadays, but always focusing on building a great product is always a good strategy. So...

Matan:
I agree.

Ben:
I'm curious, who do you see as competition here? Because I think I have seen some other tools that are kind of in the general space of marking up a website or a preview. And as I mentioned before, like I know Netlify or Vercel do some of the building specific previews of commits, but then I'm curious, like there's collaboration tools like the GitHub issues or JIRA, like are all of those kind of competition or who else is competition, who might be competition long-term?

Matan:
So the way we see the landscape is that actually what we're doing, we have this DevOps and info side, right? Of an ephemeral environment. And we also have this, collaboration aspect. So we're seeing where there are up and coming new startups in the ecosystem doing one or the other, but not both of them combined. And the reason it's a differentiation for us is that we really believe in working closely with a workflow that really generates value for both ends. Because if I'm only creating you in a ephemeral environment at service, with no collaboration aspect, then you have to use another solution or another tool just to collaborate. And on the other way, if you're just doing collaboration on a live product, it's agnostic to code changes and versioning and stuff like that. So it has limited value to the developers. So we're starting from the PR workflow, which is super trivial to start from because you're ready for a review. You're getting the review from a call review from designer, from a PM, and then everything works together and generates a higher velocity [inaudible 00:14:10]

Ben:
What are you most excited about on your roadmap in the next year? If you can share.

Matan:
For sure, I'd love to share it. That's, that's one of the best question. So firstly, okay, we're going to support more, the complicated stacks, like, you know, kubernetes and multi repo and stuff like that. But one of the things we're cooking and we're really excited about, and we hope to make a good solution for it is I supporting native apps, mobile, native apps as well because we're seeing a lot of friction over there. And you know, the release cycles for mobile is totally different than when you do web that you can just release whenever you want on a single second. Over there, you have other barriers. So the friction between teams delivering mobile solutions is pretty high. It has some, technology issues and we need to tackle it and become very novel because you want to imitate and allow the product people or the designers to actually get the notion of what the experience going to be when it's shipped and the emulator nowadays, it's not that good to allow you this experience.

Ben:
So what does your team look like today?

Matan:
So currently we're a team of eight, mostly founding engineers, product marketing manager, and a head of design. And we're targeting to be 10 by end of year.

Ben:
And are you fully remote or mostly... I think you mentioned Israel and some in US, or where is the team located?

Matan:
So currently the team resides in Israel, but we are actively recruiting and globally. So we have no barriers in this front. We are flexible in terms of, we don't love to come with "everybody works remotely" or "everybody has to come to the office." We are creating a product that we're developing ourself to collaborate better remotely. So it's trivial for us to just develop Livecycle and use it for our day to day development. So you can... Some of the people are coming two days a week, some three days a week and it's super flexible.

Ben:
And correct me if I'm wrong, but Livecycle's not open source today, right?

Matan:
It's not open source today. We're going to start some efforts in terms of, firstly it's going to be for free for any public repo. And the other part is going to be us contributing our own tools and the mechanisms because we see some of the novel stuff that we're doing internally that we can expose them and let other people use them for free.

Ben:
Have you considered open sourcing the majority of Livecycle and doing kind of like an open core model where you have the core open source and then maybe some monetize add-ons, or do you feel like it makes sense to stay... Keep the majority closed source with some open source kind of add-ons or tools along the side?

Matan:
Well, I can disclose it's a dilemma, right? Because once you go open core, it's harder to go back because you have to monetize it and you also have to push the community. We do have some ideas of how can we share and contribute to the world in terms of specific repositories or specific projects that we are using internally. So actually by opening it to the world in the community, they can contribute more and more stuff. So our solution will be even better for our users and customers. For example, I can share that our collaboration tools, it's like plugins on top of the live environment. So, we're playing with the idea of opening it like a platform for other people to just share something very specific to their use case. So maybe something very relevant to React or very something relevant to Svelte, or even doing it with feature flags integration. So why to just get it as feedback, let's allow the world to use us as an open platform on that front and adding the tool they think that could cater their needs.

Ben:
I'm actually curious on the subject of React or other frameworks. Is there anything on your roadmap or anything you could potentially do in the future if you cater specifically to folks building in React, let's say, or the modern kind of component based frameworks. Is there more you can do for folks who use those frameworks and if you try to blanket support any web app?

Matan:
There is. And for sure we can, as you focus on something, you can create some great solutions to it. I can share that. One of the things that we're thinking of is actually not a code framework, but let's say storybook or chromatic. So for sure it could be helpful to integrate with this. It's like you have the design system integrated with a live environment. So that's for sure something that we are considering to do, because it could be very compelling for both developers and designers. You can see like an overlay of the changes and you will be able to deduce you have an issue here, but then you can go and select something from the library and, and so on and so on.

Ben:
And would that let you also... if I publish a change, try design system, I can then solicit feedback on, in the same visual way on the changes to any of my components, basically in storybook.

Matan:
Yeah. That's the way to go, but we're not there yet. Right. It's like something that we're currently playing with and trying to validate, the importance the need in the market.

Ben:
And what do your hiring plans look like? And if folks who listening to this or interested in what you're working on, are you hiring? What kind of roles?

Matan:
So we're currently actively looking for a devrel to help us out with all these efforts that I was speaking of before, the community management and the content creation and to be the quarterback of the team because each and every one of us is creating content. That's one of our culture pillars. So we want someone to raise the bar and help us doing it better and also to be the advocate and to constantly help the community and share their... and get their feedback with us. Another position where we're currently looking for is a founding engineer. We're a big believers on people that are excited about the zero to one phase and they are empowered by ownership. So for sure, that's something that we're actively looking for.

Ben:
I'm curious when you mentioned that everyone writing content is a pillar. What kind of content? How do you think about that content strategy?

Matan:
So actually we have a term that we're trying to coin, and we're building on top of it some other flavors of content pieces, but also we're constantly going to Tech talks and conferences just to share our enthusiasm about technology in front end or in backend or Kubernetes and DevOps and stuff like that. And that's exciting because the canvas here to create content is huge because you can actually target a lot of communities and resonate with them. We can speak about, [inaudible 00:21:28] GraphQL and we can speak of Kubernetes and Dino and stuff like that, but it's limitless. And this is why we are... we think it's empowering the employees because each one of our team members, they can speak of what excites him or her and not like you have a limited niche of things that you want to speak of, or you are allowed to speak of.

Ben:
Matan, thanks so much for joining us today. It's been awesome to learn about Livecycle. For anyone out there who wants to check it out, just Livecycle, like L I V E C Y C L E, livecycle.io. So definitely go check it out.

Brian:
Thanks for listening to PodRocket. Find us at PodRocketpod on Twitter, or you could always email me, even though that's not a popular option. It's brian@logrocket