How SigNoz grew to 12k GitHub stars with Pranay Prateek

Pranay Prateek 0:00
I see lots of founders reach out to me that, hey, I am building this. And should I open source? And you still need to think about? Why am I open sourcing it is does this serve a developer audience? Like it doesn't solve all your problems is just one angle to try to see if there is interest in the community or whatever.

Jack Bridger 0:21
Hi, everyone, you're listening to scaling dev tools, the show that investigates dev tools go from zero to one. I am joined today by Pranay, who is the co founder of signals and signals is an open source observability platform. You could think of it like an open source version of data dog. And they're doing really, really well growing really fast. So I'm really excited to have penny on the show today. Thanks so much for joining Pranay,

Pranay Prateek 0:45
thanks for having me, Jack.

Jack Bridger 0:48
Pranay, could you tell us a bit about signals and about yourself?

Pranay Prateek 0:52
Yes, sure. So I'm proud to be one of the co founders or signals have been a dev developer myself in the past, worked in MNCs, like Microsoft, and then started signals because of a problem we saw in a company which I was working for. Signals is an open source objective platform. We help developers monitor applications and troubleshoot problems. We launched around two years back, we are at 10,000, GitHub stars 2000 Plus members in Slack community. And 100 Plus customers from across the globe.

Jack Bridger 1:34
Yeah. Yeah, that's really awesome. And what was the problem that you experienced in your company in the previous company?

Pranay Prateek 1:42
Yeah, so. So before, so I was leading product, and the whole enduring team was sort of under me. And what we're seeing was that we're not having good quality tools in our team. So we're using some version of Prometheus, and we're using elastic, but like elastic would frequently fail down. And whenever a problem occurred, or wherever the customer issue occurred, we would have lots of trouble in figuring out like, Hey, where's the problem? Right. And each minute, you sort of are in a state where your systems are not working? Well. It leads to loss of revenue, it leads to bad customer experience, right? So it's a mission critical sort of problem when that happens. And we used to get together in a war room mode, have all the relevant devs who look into individual areas and trying to sort of heal you look into this, you look into this and trying to figure out like, where is the problem, right. And that's tricky, because especially in today's world, when people are using microservices, there are just no single code, which you can look into and see the logs, but different services talk to each other, and try to communicate with each other. If a problem occurs in one part one service, the issue is reflected in some other service and figuring out what is the root cause is really the core problem, right? And that's essentially the problem, which already solves that. It gives you the ability to ask questions from your software system, that, hey, if this API is taking longer time, why are they taking a longer time? And what could be the possible 123 reasons because of it. So rather than you, like each member of the team, as I explained, looking into a particular signal, and trying to understand what is wrong, you can ask questions to a tool like signals and then be able to say that, okay, these two might probably be the reasons and go deeper into that, rather than trying to explore 10 reasons for that. That's sort of a nutshell of like, what is observed? You do?

Jack Bridger 3:58
Yeah, that's really cool. I saw on the demo that you gave us, like, you can kind of click on like, an API request and see like, okay, which part of this was taking the most time and stuff? And then, yeah, it's like really cool.

Pranay Prateek 4:10
You can go to a very detailed breakdown of like, request which entered your infrastructure? Where is it is spending time on which service is taking more time? Which service? is like throwing errors? Are these DBS? Are these some AWS cues, which are taking time? So get into all those details very quickly?

Jack Bridger 4:31
Yeah, it's like, is this kind of winning when you're making it that kind of easy to use? Does it also like crossover into like, almost like a product manager could like open up and take a look as well?

Pranay Prateek 4:43
Yeah, that's an interesting question. So though, like the main user of our product, is our DevOps engineer and developers who actually managed services, but it couldn't be are you that a product manager can See and try to understand that okay, if something is going wrong, what could be possible reason? So, as I said, right, I was already leading product teams. And whenever my certain KPI would go down, I would ask my engineering lead that hey, like, is it because of some thing in the software or the product which has gone wrong, or any API is getting slow? And sometimes those are the reasons right. So this is something which people have not explored yet. I think as much as it could be. But this is something which we have in plan for signals roadmap on ik, can we tie this product metrics to the engineering metrics, as of now, these sort of work separate like this, product managers generally don't look into an infra metrics, but if we can make that system much, like easy to understand and simpler to look, when product managers should be able to understand that, okay, this is my service, which my funnel uses. And if this is showing higher number of letters, there is a high likelihood that the conversion conversion rate for this funnel would be lower.

Jack Bridger 6:11
Yeah, that's actually really, really cool. It's like opening it up to everyone that can just like, take a look at the dev performance and see, yeah, link it back to real kind of metrics. Yeah, yeah.

Pranay Prateek 6:23
I think today, like developer, like, people don't want to mess with Dev, because it's like, sort of considered at a higher pedestal. Can you sort of democratise that access to everybody in the team? Like, of course, like, it's very specialised skill. So it's, like, difficult to understand what's really going on. But some teams have product managers, which are technical enough to sort of make sense of what could be willing.

Jack Bridger 6:49
Yeah, that's interesting. It's like kind of, I don't know, figma. Like the way that, you know, figure out over dark, like doing some mock ups to the whole team. You know, and still, the designers are the ones that, you know, really understand this, and making good but yeah, it's like, you could ask them all

Pranay Prateek 7:07
day, like, just for me, I'm not a designer, but I can make some basic designs and be happy about it, that I can make some of the things.

Jack Bridger 7:17
Yeah, that's really cool. So it sounds like it's like really amazing, you've come at it from a big problem that you experienced, and you've gone off to solving that. And now within a pretty short space of time, you're at like 12k, GitHub stars. And you're getting a lot of traction, it seems like what, how did how did you go from identifying a problem to getting that kind of that really promising traction?

Pranay Prateek 7:47
Yeah, I think, what we first sort of understood that this is a very important problem. And this is going to be more and more critical as more part of our economic outcomes digital, right? If you think of any company, that real IP in that company, sort of the software company, even if it's, for example, a food delivery company, the real IP or the real value is in the software research is sort of a science, where is the? What is the ideal distribution pattern? How can you make the deliveries faster, right? So the fundamental thesis is that software is becoming more and more important. software infrastructure is becoming more and more complex, with things coming like Kubernetes, microservices, understanding and making sense of it is becoming more and more difficult. So you will need tools, which can help people get a sense of how the software system is performing. Right. So so that that was sort of the core hypothesis. And we started with open source because we we think that because this far, it was fundamentally used by developers, apart from like product, major use case, which we're just talking about, if we do that feature, but fundamentally, the core users are the developers, right? And as developers, ourselves, we, we love the approach. And the ease of use of open source product, you can just go to a community, get started, start tinkering with it. And if you have any questions, there's a community around it. Compared to for example, you sign up for a product. And then if you have any problem, you have to go to support talk to account manager. So it's just a much more natural way to play around with software. And I think fundamentally, all developers are tinkerers first. So that's why we decided to attack this problem in an open source way. And when we saw the market we didn't see like there was products like Grafana, which does like individual things. You can do metrics with Prometheus, or you can do elastic logs with elastic But you can't, you didn't get all the three signals in one place like metrics, traces and logs in one place, for example, which tools like data dog too. So that was the whole approach that hey, like, can we build something, an experience like data dog in open source. And fortunately, we got into YC, Y Combinator, which is an accelerator based out of us. And that was very helpful for us in in terms of even understanding and getting visibility in the market on like what people use. And we were part of winter 21, batch, lots of feedback in from the fellow co founders yourself in the batch. So that helps, it helped us a lot. And yeah, we, once we build a product to launch to the community, we did a launch in Hacker News that went decently well, we had around 200 Plus votes. And yeah, at least what that sort of gave us confidence that it is resonating with the developer community that there's a need for to like this. And started building from there being producing more content launching in different forums. Like basically the idea that anywhere developers are there, can we reach out to them and sort of get feedback on the product, see, understand, like what they have to say about it, and invite them to our community or our GitHub. And because there's an open source project, you can start playing around with it commented, things like that. So that has been the sole approach. Reach out to developers, try to create content on what we are doing, and then share with the community and get more and more feedback from them. And yeah, I think till now, it has been decentralised. We'll see how it goes. But yeah, I think there is some resonance in the market on like what we're doing. And we're trying to get deeper into it.

Jack Bridger 12:03
Yeah, that makes sense. And so when you one of the things you said there is that you're like, looking for feedback, you're asking developers for feedback, you're going where they are asking for feedback and getting them asking them to join the community or just tinker around with the project? What do you kind of like measure as like, success in that sense? Is it like the number of people like opening pull requests? Or like, how do you think about like, what the goal is for you?

Pranay Prateek 12:34
Yeah, I think one of the goals for us is to measure how deeply people are engaging with a product. And one way to measure that as what type of questions are they asking the community? Is it just that, hey, how do I get this services data to this? Or, Hey, I am using this in production. And I am getting this scale and because of that this issue is coming. Right? So there's this sort of gradual scaling, because when you started earlier, it was mostly like a, like, I'm trying to instal here and then I'm not able to instal it, right. So we learn from that we started building more docs around it. And like meeting making it more and more clear, and, and that's like one of the learnings, how can we make Doc's much better, because developers don't go to a landing page, they go to your Doc's. They don't care about what you've written on your like main page, they put your docs, and then they see, can they make sense of it? Right? And they will give you like, 20 minutes, 30 minutes, if they can get something up and running. Cool. If not, they will just leave you because there are other things to do. Right? So like, early in our days, lots of feedback was around, hey, I have a Java hardware instrumented? Or like, how do I get data from this to signals? And slowly as we improve the docs, the type of questions become much deeper that hey, I am instrumenting, this Java app, I'm seeing this traces. And I'm also seeing the logs. How do I tie traces with the locks? Which is a more interesting question. I like souls that hey, like you're using more deeply. And then then we started seeing that as people started using the product more and more. They saw that, hey, this is not working, or this is not working in this way. Maybe it's there's a better way to do this. And then we asked them, like, can you open a pull request for that? And yeah, interestingly, people are, if they're using a product and then they think they can improve it, they are happy and willing to contribute back, which has been very interesting for us. And or maybe it's just that I am turning it in this version of Linux. And as of now your instructions are like the default talker instructions, which doesn't include that. I will add that. What that helps us do is add more people who can ease now Try signals much more easily who are using that Linux version or that sort of instal instructions? Right? So yeah, so a question we try to understand like, Are people using it more deeply? One of the one of the ways RPP, the opening pull request, are people answered, asking people questions in the community, are people contributing back? So we are seeing even contribution nerd talks? that, hey, like this, I tried to step something was not missing here or this hack. It works slightly in a different way. And hence, are we good to add here, and then we say, hey, our dogs are also open source. So you can just create a pull request. So that's something which we are deeply.

Jack Bridger 15:43
Yeah, that's really cool. And then one of the questions that we had from Powell, who I should also say, Thanks, shout out to a pal from digger for recommending that we invite planning onto the onto the show. Powers wondering like how you're going to kind of what the path to monetization will be from kind of the success of the open source project.

Pranay Prateek 16:07
Yeah, so the way we think about it is, that took two sort of main angles, we are following an open core business model where the core of the software is free and open source. But if you're a big company, you're deriving value from the product, a certain set of features, which you would not want, which like smaller teams would not want and that you should be able to pay for. So things like security, more advanced compliance features, more detailed, or back controls, things like that. So those are in the enterprise version, they are not in the Community Edition. So that's one model. But we also see requests from users who want to know, like, like signals, but one don't want to host it, because some teams are, don't have enough DevOps resource or bandwidth to like, host their own other infrastructure. So we'll all we can also offer a SaaS offering there where we will host signals for them. And they, they can just send us their telemetry data. And then we take care of the monitor, like hosting part scaling part and things like that. So yeah, so one option is the Enterprise Edition, which people can run in their cloud, but want certain features, generally, for bigger companies. And, like, if you don't want the like to run signals in your infrastructure, you can just use the hosted version and go with it.

Jack Bridger 17:36
Yeah, yeah, that makes sense. And then how do you think about like, kind of the funnel of like, I guess there's people that come in, they like, check out their source project. And then some stuff happens in the middle. And then on the other side, some percent of those end up bringing you into their company, or opening a subscription? Like, how do you think about like, what happens in between?

Pranay Prateek 18:03
Yeah, I think what we are seeing generally is art is generally seeing developer who is trying to solve a problem, or he has got mandate from a team that hey, like, we need to replace or observe the system and then exploring things in the market, he starts trying it in out in his laptop, and see if it works or not. And then as he gets more confidence, he or she instruments, more and more services more, start sending more and more data. And then it goes to a adoption in a team, maybe as a team, which is handling that service, right, or handling that application that starts adopting the product. And if that works, well, they would go to sort of evangelise on there like this, essentially, this guy is or the lady essentially becomes the champion individualises the product in his or her org that hey, this is the Can we adopt this in more more systems? And then somebody starts and comes at Hey, like, what what do we need to do to make it more production ready and what you're seeing is generally companies when they want to deploy something in like much bigger or wide scale, they want to talk to somebody on somebody who can support them or they know that they are people around that right. So so that has been interesting. That is generally the generally the path we have seen that people start trying out small. Get more and more people in the team get adopted, and then if they see it fits the need, and it is the problem solving the problem they're trying to solve, then somebody higher up in the org gets involved and then reaches out. Yeah, so that has been involved. We don't have like too much data as of now. It's still very early, you know? connotation of art on like, to sort of understand more deeply on the sweater, but this is the main route we are sort of trying to encourage and follow.

Jack Bridger 20:12
Yeah, yeah, that's really interesting. And is there like anything that you do currently that like you think accelerates? Like, the likelihood that someone starts to try it out in a team? Or then starts to try and think about getting it production ready?

Pranay Prateek 20:32
Yeah, I think one of the most important learnings for us has been to make it very easy to set up in a single dev box, so that there's no friction in trying out the product. For example, earlier, we're based on truth as a data store. And that needed though is like as good as click house, which is our current data store, you need certain higher number of infrastructure resources to start running it, right. But what sort of that inhibits or introduces friction is that the developer would need to have access to bigger clusters or more infrastructure even before trying signals, right. So we've really focused a lot on making this very easy for single developer to use it even though ultimately, our product is used by a team, it's not a generally a single developer, use product. So that has been very interesting for us, and how that can be enabled much deeply. The next step is that if you start seeing the data are able to see in the product very quickly. So that is sort of the aha moment. That if that, if they are able to see something which they are sending in the product, they get more confidence that okay, let's play more with it, try to understand what this is this can give and get more insights from there. Right? So so these are the two key steps, which we have no focus on, mostly on like getting to the aha moment very quickly, can instal very easily in a single dev environment? And can you quickly get to see start seeing it. And some of this could be like very easy Helm charts, which are like if Kubernetes provide Helm charts, which can get started very quickly. pre built Docker compose images prevailed? In flat charts, things like that.

Jack Bridger 22:37
Yeah, that's really interesting, the aha moment, just making that as easy as possible. Yeah. Yeah. And one final question. One of the things I've seen that you've got quite prominently on your website is your technical writer programme. So I wonder if you could just tell us a little bit about that.

Pranay Prateek 23:01
Yeah. So the way we came across, it was that our product is very technical, and to educate users about our domain, in need, right? Lot of content, right. And because it's very technical, like a single person, like a person in house in the team can't write everything. Because if you're writing something about Java, you can't write generally, you a single developer doesn't know all languages as well, right? So if somebody knows Java, he doesn't know Python. And we can't have too many people just for writing. So a natural extension was that can we outsource this to community? Also? That because there are different people who have very specific good knowledge on specific stocks? And can they write, for example, tutorials on how to use signals? Or how signals might be relevant or how to do a particular thing on Java? Or how to do a particular thing on Python. And it's very difficult to find a single person who knows all these things in detail, because you need to get very detailed, right. So it has been sort of motivated from also from the technical aspect of our product, because if you are a ecommerce product, generally everybody can write about all aspects of E commerce, right. Or if you're just a company or product, which just works with JavaScript stack, if somebody is good in JavaScript, you can write everything. But we are sort of a more horizontal product because you can have different types of applications which start sending data to us. And, and hence we sort of thought that hey, like, what's the scalable way to do this? And one of the solutions were that hey, can we ask members in the community who have an understanding of specific things, especially with stacks and ask them if they can write tutorials, or blogs or not? And I think you that has that has been a good experiment. We have, we have been able to produce good amount of blocks on that. And yeah, I think this is one of our scalable way to produce content, especially if a product is very wide. And it's lots of technical depth.

Jack Bridger 25:20
Yeah, I really like the way you talk about the horizontal, if your products horizontal, then the knowledge is just not really possible to keep like in house,

Pranay Prateek 25:28
it's very difficult to find somebody who knows JavaScript in depth, Java in depth, go in depth, elixir in depth. And if you go to our docs, we have like 11 languages, which, which you can instrument and send data to seminars.

Jack Bridger 25:44
Yeah. Yeah, I know. You mean. That's, that's very difficult. Okay, Pranay, that's amazing. So I think that's all we've got time for. But one of the things we ask everyone now is the TLDR, or TL DL, what is what would be your key takeaway for someone listening? who's building a dev tool?

Pranay Prateek 26:09
Yeah, I think I would say mostly for open source product, because I see lots of founders reach out to me that, hey, I am building this, and should I open source it? Right. And, and one of my questions would be that, hey, like, why do you want to open source is the final user persona developer. And even if you open source it, it doesn't take away that need to make a great product. Right, so So open source is just one one thing like it's, it's that you have open source the code. But you still need to build, like talk to users still need to build great product, though open source, like accelerates a lot of this like, because getting feedback from the community is much faster. Getting feedback on like, how the product update is much faster. So all this the good things about open source, but you still need to think about why am I open sourcing it is does this serve a developer audience? And you still need to build a good product and talk to you this, right? So not to take open source as a snake solve. Like it doesn't solve all your problems is just one angle to try to see if there is interest in the community or whatever.

Jack Bridger 27:36
Yeah, 100% makes sense. Great, great comment. Rene, thanks so much for joining ship. Where can people learn more about yourself and about signals? Yeah, sure. So

Pranay Prateek 27:50
we are a pretty active Slack community. We are open source. So just go to github.com/signals/signals. And I think you'll find lots of content on how to follow and we have a pretty active Slack community. You can just if you have any questions that aren't signals, you can just join in and ask. And you should be able to find it. signals.io/slack.

Jack Bridger 28:17
Amazing. Well, thank you so much for joining. And thank you everyone for listening.

Pranay Prateek 28:22
Good. Thanks a lot. Thanks, Jack, for having us. And thanks for inviting dev tool founders. But I think there's lots of understanding and knowledge to be shared in this community. And I think podcasts like this could help more and more people to learn on how to build such companies and products.

Jack Bridger 28:40
Yeah, thank you very much. Thank you. Thanks so Paul as well.