Pull Request Environments with Eric Silverman

The modern release workflow involves multiple stakeholders, engineers, management, designers, and product managers. It's a collaborative process that's often held together with brittle workflows. A developer deploys a new build to an ad hoc staging environment, and pastes that link to the environment into Slack. Other stakeholders click on that link and then send messages to each other in Slack, where they make comments on the pull request in GitHub.

This workflow is far from ideal. Collaborating around pull requests can be made easier with a dedicated set of tools for sharing and discussing those pull requests. And that's the goal of Feature Peak, which is a system for spinning up dedicated pull request environments, creating screenshots and comments, and reimagining the lifecycle of the release workflow. Eric Silverman is a co-founder of Feature Peak, and he joins the show to discuss release management, the interactions between different stakeholders, and the development of his company.

Much like the previous show about Postman, in which we explored how API management has become a ripe space for collaboration, the same is true of pull requests. It's also a ripe space for collaboration. Before we get started, I want to mention that we are looking for writers. If you are interested in writing for Software Engineering Daily, send me an email, jeff.sauferengineeringdaily.com.

And also, I am personally looking for companies to invest in. If you are building something for engineers or something that requires heavy engineering, send me an email. Jeff at softwareengineeringdaily.com. I'd love to look at what you're building.

Eric, welcome to the show. Thank you for having me. You work on Feature Peak, and in order to explain what Feature Peak is, we need to talk about the modern release process, and how the modern release process involves not just developers, but designers and product managers describe the modern release process to me. So the modern release process at this point has become a lot more complicated than you would really think.

There are a lot more hands in the pot. There are a lot more people touching every step of the way in terms of getting code that was written on your desktop. Or your laptop onto the server deployed out to your customers. The most basic way that this is kind of evolved is it goes from your local Dev environment, you push some things to staging, you push some things to prod, QA happens, probably under staging environment.

What's happened more is that there are a lot of different stakeholders who are really involved in, or should be more involved in every step of this process, because either front-end engineers are working way closer with design, which is something that we've really seen, and that a lot of people need to sign off on changes that can affect lots of different parts of the company. And so, as engineers are moving to incorporating more DevOps technologies, there's a lot more opportunity to really optimize some of the release flow, where it's not as linear as Dev staging prod, which is what I'd say a lot of people just by default end up adding to their workflow as they're building up a product, as they're starting a company, as they're adding some formal release process to their team, pushing to Dev, QA running on staging, and it going to production is pretty well-worn territory at this point. Or they have maybe an AB canary set up, something like that. What we're trying to do is really use the idea of deployment previews, some people call them feature environments, some people call them on-demand staging environments, to not only disrupt that flow a little bit and bring some of the validation and verification of new features and new work earlier in the release cycle, but really make sure that all stakeholders are involved in the release process as they need to be way before any sort of critical release point.

This CI process has really become a place for collaboration as you're alluding to. So, these one-off feature environments that can be collaborated around. What is the ideal collaborative workflow? Well, I think the ideal collaborative workflow is, number one, making features available to verify tests and run as soon as possible, and two, providing the right kind of tooling on top to actually keep non-technical members of your team, or distributing members of your team, able to put tools in front of them that can allow them to give really actionable and quality feedback.

So, that means things like screenshots, bug templates, browser metadata, all the stuff that as an engineer makes me go crazy when you receive a bunch of bug reports, and you have to then follow up and say, was this on Safari or Chrome, was this on mobile, what's your setup, all the kind of stuff that really drives engineers crazy, it's really being able to abstract that way, make sure that happens for free, and incentivize people to participate in this process. I think, gone are the days of throwing designs over the fence or saying, all right, well, I handed it off to engineering. We really think the whole developer handoff idea is pretty antiquated. It made a lot more sense when you had more of a linear deployment model, it made more sense when teams had kind of bigger boundaries between them, but what we've seen is that teams, a lot of people work on everything, designers work really closely with front-end engineers, everyone's working together, there's a lot more stakeholders, and so you need some of that ownership.

All the stakeholders need some ownership in the process. I think one analogy I could draw, and this is maybe a generous analogy, but the way that Figma has opened up the design process to a lot of stakeholders, I see you as trying to do something similar with the release process and try to allow other stakeholders to collaborate in this place that was in the past, sort of like, I spin up a feature environment and then I send you an instant message with the feature environment, you go look at it, then you respond back to me and it's really formalizing that process. Yeah, and I think Figma is an amazing product, and we've obviously taken a lot of inspiration from them. And if you even go back before Figma, it's something that envisioned it really well, right?

Being able to mark up a prototype, annotate, leave comments there, and then Figma obviously pushed it a level further, really being able to design there. And so what we see is the other side of that. We see that there's a lot of really great tools for designers that are made for designers to work better with their teams. We see Future Peak as one of the first real engineering led tools to change that process collaborating back with design, back with product, instead of just tools for the other side of the handoff from design to engineering.

As we get closer to kind of explaining what you're doing, we'd like to get your perspective on the Jamstack and how this modern release process is reflected in the Jamstack or how the Jamstack has changed these releases and just a modern collaborative workflow. Sure, I think the Jamstack works really well to move really quickly. And I think that what it's done is given front-end developers and a lot of power to move really quickly to build really powerful single-page applications to kind of abstract away some of the content pieces of this. And I think it's allowed for a lot of velocity and a lot of ownership in this space.

And so I think what the Jamstack has encapsulated, and this is part of the reason we think Future Peak really works really well and we can get into that. But I think if anything, there's so much more velocity because of people adopting Jamstack, Jamstack applications. I mean, we use Gatsby at Future Peak, our marketing site is Gatsby application. And we think that if anything, that's made it easier to collaborate.

I think it's really opened up. I mean, I know Gatsby's got that great review feature specifically for this is people are very much building tools to easily collaborate. And I think Jamstack, I think Jamstack applications has really opened up that potential a lot more. In a typical review when I've deployed my software and its in review, what kinds of issues are going to be discovered by the various stakeholders who are taking their Gander at my release?

Oh, sure. So lots of different issues ranging from, this doesn't work in my browser. This has some prod. You know, maybe we're looking at this against production data and this component breaks.

We have some overflow issues. We've had some of our users even just tell us, oh, man, I had a local font installed and looked at the Future Peak environment. And we didn't have the right font. And so it's really trying to solve the works on my machine problem.

And so being able to actually have it up there mimicking what we were running out there in the wild, you can catch a lot of different issues. So it could be anything small from the shadow doesn't work in my browser all the way to this component is totally broken. This doesn't even work for me. So let's say just like that.

And the design issues that occur, are these pretty innocent or do the minor design issues that might crop up to significantly diminish product quality? Because I think one thing I see in Future Peak is there's a way to highlight and uncover and zoom in on very particular minor design issues. And I just let's hear perspective on how really minor design issues might affect the quality of product. Well, I think it's more about the handoff process right now is the designers work very hard on handing something over that they feel confident about.

And the engineers are going to give it their best shot. They're going to try to match this back. Maybe not all states were designed for. There's always going to be some gap in communication there.

And so what kind of those could be either functionality issues or they could be, I had to take some liberties with a hover state or something doesn't necessarily flow on the page the way the design intended. So it could be something as simple as the shadow or this corner doesn't look right and it can be nitpicky stuff. But what we're trying to really do is move all that feedback earlier. So even if it isn't it can be screened appropriately or it can say, oh, that's not as important.

That's not a blocker. Or while I'm already working on this, I can tune up those bugs. The problem that we're trying to really solve is getting all that influx of issues be it small issues or major functionality issues. The very last minute is really going to that will block the release.

That will impact the quality of the release. Having all that feedback earlier, you at least get to decide and get to treat those issues the right way. The minor issues often take the form of things that are like pixel width or the distance between different elements. These things are pretty important in design.

They're kind of hard to report back to the developer. Maybe you have some particular one thing I think here is the developer doesn't necessarily speak the design language like a developer doesn't necessarily know. Hey, you know, this needs to be a more gradient. I don't even speak the design.

And so there's a role for screenshots and screen recordings and just kind of taking a visual perspective on what is going wrong in a design. And a typical release process I can see I think about the Apple screenshot taking tool or the quick time screen recording tool as being pretty pivotal if you don't have some better way of gathering feedback. So in terms of gathering visual feedback, what's the state of the art in reporting that back to the developer that's managing the release? Right.

So what we would expect, and this is something that I've had in my projects in various different roles, is a lot of people add a bug template. A lot of people say, okay, here's how we at our team like to have good bugs. We need browser metadata, include screenshots, include steps to reproduce. And that's different from team to team depending on how they screen how they screen bugs or take in tasks and issues.

We've built that in specifically because we know that if it's right in front of you and it's very easy for you to take a screenshot record a video, you'll do it. I think the problem is, and yes, like it's great. The Apple shortcuts to take screenshots are great. The problem is in the moment you don't always do it.

I mean, how many bugs have you seen? And I've seen hundreds where you just got one. Oh, this doesn't work. Yeah.

Oh, this is broken. It's like, okay, I need context, right? Engineers really need that kind of context. And just in the same way that engineers don't speak the design language, design product, other non-technical stakeholders don't necessarily speak the engineering language.

So what can we do with tooling to really kind of bridge that gap and make them not have to speak the language and still file really great issues and communicate great feedback? All right. Well, we've kind of laid the foundation for what you're building. Explain how Future Peak works.

Sure. So Future Peak spins up a dedicated deployment preview for every pull request. So as your code is in code review, getting reviewed by other engineers, there'll be a comment right in the pull request that'll link you to a running site with your code. On top of that, we have what we call our drawer, this little drawer over life.

And so on top of that, right late on top of your page is a little button. You can easily take screenshots. You can record video. You can connect your issue trackers that we integrate with, GitHub issues, Clubhouse, Trello, we're rolling out new ones every couple of weeks.

You can file tickets right from the page. You can see who on your team has actually viewed these changes. So you can actually, if you want, you can leave a comment and even block a PR just on having a member of your team actually look at your changes. And what we're really trying to do is add that visual part of code review and make it interactive and get all stakeholders on the same page before these issues hit your dev environment or your staging environment.

Really being able to review features in an encapsulated environment in isolation, find those issues before they're merged in and really try to bridge the gap between engineering, design, and product and really fill in the missing piece of the review cycle. So there's already a lot of tools in the development life cycle. You've got Trello, you've got Slack, you've got GitHub, you've got all these different things that you're interacting with. Make the case for inserting another tool into that development process.

Sure. So we were talking earlier about developer handoff. Right now, after designers hand over to developers and developers are in their sprints. Right now, there's no place for the rest of the stakeholders to actually give feedback, do their own testing, do their own verification of work that they're highly invested in until it hits their staging environment.

And usually by the time that happens, those engineering teams are already on to the next sprint. They've already moved on. So there's no place, there's not an actionable place in that workflow to give feedback when it matters. And engineers have that, engineers have code review, engineers specifically have a time carved out in their development cycle to get feedback from the rest of their team.

And that doesn't really exist for other stakeholders. So I'm actually latching onto a point in the cycle where there's already a pause where we're already saying, hey, I want to take in feedback. I want this feedback now because this is top of mind. I'm already working on it.

What is the best way to get all the actionable feedback on that work? And to do that, you need people to run it. And even for engineers, I mean, I'll code review something and then I'll end up having to stop my local development off to check out someone's branch. I'll end up starting a dev server on my local development to try it.

I want to be able to visually test someone's work in the same way that I want to read the code. And so we're using time that's already set out to get feedback, to bring more stakeholders in and give really actionable feedback and keep the team on the same page. Could you give a little bit more of a description for the workflow for how a release is turned into something to look at with Future Peak? So I've got my updated C file or I've got a new build and it's ready to be released and observed in a pull request environment.

How does that work? Sure. So for Future Peak, we have a one line step in your CI file. And we're listening to Webhooks via GitHub.

So when you pull up a pull request, we listen to the Webhooks, we know you've created a pull request and we wait for CI to run. So we get pinged via your CI. And once that happens, we'll pull down your build either if it's a static site, which I know is not always a great term for what it is, but a static bundle or a Docker image. So we support both.

So we'll pull down either your Docker image or your static bundle. We'll set that up and launch that. When it's up and ready and healthy, we will put a comment in your pull request. It takes a few seconds to do.

Put a comment in your pull request. We can also ping your team in Slack. If you have that set up, some people have a Slack channel for their pull request. And you can also say, hey, here's a feature environment right here.

You click it, it opens up this environment where you can just see it running. We'll have your pull request comments and notes right on the sidebar. So you can see all the activity going. And you can just leave comments right from there.

You can create screenshots and videos right from there. It's really as seamless as possible. And we specifically built it to be infrastructure agnostic. You don't need to.

We don't care if you're on AWS, if you're on Google Cloud. We're really intentionally designed to not be dependent on any of your own infrastructure because we know teams change their infrastructure. Teams change their deployment patterns. This is something that you set up once and forget about it.

And then it's just always running. You'll get pinged when you put up a pull request and your team can just jump in and start checking out your changes. How does the release cycle change with the addition of this pull request environment? Well, I would say the release cycle changes because environments actually get to be used for their intended purposes.

So if you have, let's say you have a dev staging and production model, in my experience, the development environment is where everything gets merged directly into. So after pull requests, everything lands on dev dev should be where you are fighting through integration issues. It should be kind of an integration hell, integration war zone, if you want to say. It should be where all these different changes have landed.

And now you're not actually troubleshooting the individual features or changes that you made. You're really troubleshooting issues that come up because the interoperability between them. So that's where you would have crashes because maybe someone removed the dependency or this is broken. It's really about a place to resolve integration issues.

Staging then becomes purely for either automated QA or release QA or kind of like an external QA. It's specifically just about to go to prod. We're just doing smoke tests there. We've already validated these features.

We've worked out integration issues. It actually allows the staging environment to be almost prod, which is what it's intended to be. It allows you to move into a much more nimble release process where stable supposed to be production and dev is actually used to work out developer issues between issues. And then you can review all of your features as are being developed in deployment previews.

So I'd say it moves some of the process up a step, but ultimately it allows a much more functional process across each stage. All right. Well, the idea of working with the Spore Request environments probably makes sense at this point. Let's talk a little bit about the engineering stack.

So what are you doing under the hood to facilitate the creation of these Spore Quest environments? Sure. So on our back end, our main back end is anything that interacts in the user space is Ruby on Rails application, is a Ruby on Rails application. And then anything that deals with the environment specifically in terms of dispatching management, we're leveraging Kubernetes.

And we have some custom code we've written to easily bring up environments and ingresses really quickly just to bring up these environments. Everything's namespaceed, everything set up differently by is encapsulated by team. But we were running Kubernetes in the back end and then we managed that through our system. If you're a static asset, let's say you're not a Docker application, we will on the fly, dockerize your static bundle and deploy it.

That's pretty useful. So I guess it's worth taking a moment in time here. How do you think this would have worked pre-Kubernetes? So it's interesting because there were some tools out there that kind of tried to do this pre-Kubernetes.

And they were using Docker Compose. And I think pre-Kubernetes post-docker or pre-both. Let's say pre-both. So I think pre-both and it's funny because when I was at Apple, we did some kind of hot swapping of environments sometimes in our internal tools.

I hate to say it, but I think pre-docker we probably just would have been swizzling sim-links on some drive somewhere if we had to. I think we probably would have had a really long engine X config that we wrote too dynamically and it probably wouldn't be very stable. And we would probably be doing a lot of directory hopping and organizing flat files on a drive to encapsulate it that way. And we'd have to probably use a lot more monitoring and tooling to manage those.

And especially from a security perspective would be a lot more challenging. I think part of the reason we're doing this now is because DevOps technology has gotten really, really good and really manageable to be able to affect other parts of teams in their workflows. I think the first phase of Docker adoption in Kubernetes was look at how much effort we can save in the DevOps perspective or look at some of the things we gained from a release perspective. Now I think that tooling has gotten so good that we can really start affecting teams that aren't just engineering by leveraging some of this technology.

Do you use any infrastructure tools or platform service products that have surprised you and how useful they are? I've used Google Cloud for Kubernetes for a while now. This is not my first project on that. So we were pretty set on that.

We've actually moved a lot of stuff into Google's ecosystem specifically. We don't use that many direct platforms of service stuff internally. I'm trying to think what I've been really impressed by in terms of tooling tools that we've just used internally. We use Auth0, which we're really happy with.

We use Skylight for performance monitoring that I've been very impressed with. But we do a lot of our specific environment management. We've written a bunch of that. There are some really great products for Kubernetes out there.

We're not necessarily leveraging them right now. Have you always been a Google Cloud person? Or were you on AWS? Did you use AWS before that in the past?

The last startup I was at with my co-founder, Jason, we were on AWS for a bit and then we wanted to move to Kubernetes. And Google's Kubernetes support was a little further along. I think actually we asked to be in the AWS beta and they never got back to us. And we got impatient.

And so we switched. What's the hardest engineering problem that you've encountered while building Future Peak? There are a few. I think when we started, there were a lot of different ways to manage the environments and leverage Kubernetes.

And we really honed in on the right level of touch to interact with this. I went, don't fight the system, but write your own management stuff. And so I'd say that was one. I think we definitely have spent a lot of time really trying to add some features that try to leverage some of the technology to create features that we don't think other people necessarily would or could.

So for example, if you're using OAuth, you can stay logged in between feature environments on Future Peak. So that was something that a customer asked. Like, well, every time I open up a Future Peak environment, I have to log in again with OAuth. And we've worked in actually being able to persist that across environments, things like that.

I'd say also just being able to create our overlay and adding features to that has been one where we made some decisions, had to tweak a few things and then kind of build out from there. But at this point, it's really about, from a deployment standpoint, we feel pretty good about kind of getting there. But I think really figuring out the right level of touch in how we interact with Kubernetes was probably the hardest thing to get right. That overlay that you mentioned, I think is just a key to describe in more detail.

Can you explain what you mean by the overlay? Sure. So when you're looking at your page in a Future Peak environment, there's actually a little button floating in the bottom left corner, just kind of hovering over the page. If you hover over it, you'll get a little button for a screenshot or a video.

If you click it fully, it'll actually slide out like a drawer will slide out from the side and you'll see a list of a timeline, basically, of what's happening with your environment. So let's say Bill reviewed this and looked at the page and he looked at the page three times in Chrome and then made this comment. You see a timeline just like you would in GitHub of comments, but you'll see it with activity. Oh, someone viewed my page and all these different browsers and someone left a comment and said, you know, this is a really bad issue and they blocked the PR based on it.

You can really get a full timeline of who's looking at your work, who's reviewing it, and from there, inline screenshots, you can add comments, you can file new issues to your bug trackers, you can add comments directly to the pull request. It's really this interactive pane overlaid on top of your page, literally hovering on top of your page that adds all these really powerful features. And that's where we really think the differentiator is between other deployment previews or other feature environment tooling, is that we really think that a feature environment is useful, but if it's just a page that you're not going to file a good bug on top of or just, you know, a link isn't enough. You need to be able to do something really powerful on a page.

In building that overlay on the page, can you tell me how that's implemented? So, you know, you just got this, is it just you put the entire page in an iframe and then, you know, put the tray outside of that iframe? Yeah, it's kind of a mix of a iframe. We serve all that content to the iframe and then because we're running it on the same domain and every team gets their own unique domain so that because we're on the same domain, we can send messages in and out of the frame or sorry, down into the frame.

And so we're communicating directly with the frame, the frames communicating downwards and then that overlays it to the middle. And what has been the product development process? So when you are interacting with users, how do you understand better what to add to the product? So we've been really fortunate to have very vocal users and a lot of them will just shoot us a message and crisp and say, Hey, can I do a lot of this?

Hey, can I do this? You know, or this kind of bugs me and they've been really, really, so for example, this persistent login across environments. That was one that it was kind of just a complaint like this bugs me that I, you know, every time I have to log in, that's kind of a barrier to me being able to test something efficiently and quickly and really, yeah, how, how the hell are we going to fit in a song? And so we went back and thought about it and workshop that for a while.

I think a lot of the stuff that we're working on now is really trying to put better feedback tools in front of people, really trying to connect more with people's existing services. So we rolled out Trello integration and Cloud integration. We're going to roll out, you know, Asana and Jira and really just meet people with the tools that they currently have and try to integrate with those. But a lot of it has been, you know, how are people using this?

You know, what do people like about this and really just try and ask them and go back and brainstorm it. I mean, originally, at least for the first couple months, especially before we had users, I mean, Jason and I were kind of just building this for ourselves. We were at a startup before this and we're looking for something that really did this. We were beyond frustrated that, you know, design and product would wait until, I think we shipped on Thursday's.

And, you know, Wednesday nights, I knew not to make any plans, not because the release wasn't done by what I thought the release was done, but I knew that we were just at 430, we were going to get an influx of lots of little nitpicky bugs and people finally looking at staging. And I knew we were going to just have to call the team back and either fix everything or maybe ship it.1 the next couple days and it was just frustrating. So we looked for a solution for this. So for the first couple months, Jason and I were really just building what we wanted for ourselves.

And then fortunately, when people started using it, you know, they had a lot of really great feedback and a lot of great ideas on what to build next. I think it's a great and useful product. I wonder what the next thing you can add to it. I mean, you got kind of the basics of what a user would want out of a pull request environment, out of a feedback giving tool.

What else could you build on top of it? I think there's a lot. I think not only kind of integrating with other tools, but I want to be able to get closer to, you know, something like a Figma experience. I'd like to experiment more with how people really like collaborating.

I mean, I think especially now we're learning so much because we knew that this would be valuable for teams that were remote or distributed, but we also know that it's very valuable for teams that are just in the same office, right? But what we're really interested now is how are teams working together as their remote? How is that process changing? How are people collaborating with stakeholders as they're now moving to a remote situation?

And so I think there's a lot there that we're still really interested in learning from. And I think there's still a long way to go in terms of kind of how can you do a more over the shoulder is this what you meant, kind of review. We're getting closer to that in terms of here, use this and give feedback. But there's still a long way to go in terms of like really trying to make up for that distance gap that we're really interested in.

Any particular pain points you can identify? You know, I think we work really well right now specifically around, you know, asynchronous, right? If you're a developer working with a remote team, if you're in a different time zone, you can just get a bird's eye view of everything your team's working on and kind of just jump into each of those different environments and try them and see what's going on. I think that's really valuable.

I do think there's also some value in more synchronous communication. I think there's more value in getting closer to being able to integrate, you know, Figma designs and the running page more. I think there's a lot of different ways that we are interested in kind of expanding to. But right now, I think it's more about us just kind of learning from our users.

I think we're still very, I mean, we're not very new, but I think we're still, I still think every time we have users really active on feature peak and really passionate about it, they end up telling us something that we didn't know before. And so that's it's still very exciting and I'd love to let them lead. Are there any other changes to web development that you think are coming soon or have recently occurred that might affect your work on feature peak? I think the baseline of development in terms of, and I don't mean, I don't want to say the bare minimum and I'm not, and I don't mean this to say that, you know, some of the Jamstack frameworks or anything like that are simplifying the process.

But I do know that the one thing I've noticed is that there are a lot of, it's definitely shifting roles a little bit to have front end engineers work very, very closely with design or even moonlight as design or vice versa where the expectation of a designer is to use Webflow and just do it all there and you don't have to care about it. And while I think that's very attractive to say and it probably, you know, probably sounds good in an article about how development is changing, I can't see that really happening. I think people have complex enough applications. I think people are going to need to, you know, maintain their complex web applications, not to mention legacy applications to, you know, be able to reduce everything into a template, to reduce everything into a wizzy wake.

I think people have tried before and I just, I don't think it's necessarily going to happen. But I do think that certain tasks get simpler, right? Gaspias made certain things incredibly easy to do. I don't think that would necessarily change our product other than it's about us being able to support more diverse types of products, including simple applications to more complex applications.

On the front of Gatsby versus other front end frameworks like Next.js, do you have any perspective there? How you differentiate them and how the prototypical jam stack unfolds in the future? You know, when we talk about Next.js, I think that is way bigger than I would say. I consider Next.js be pretty different just in terms of the level of complexity that people are building on top of Next is massive.

We have a next component to our app. I mean, people are doing some very serious heavy lifting there. And so if anything, I think that, and I think I heard you, or I heard someone say this in one of the episodes I was listening to, I'm trying to remember which one, but I think if anything, front end engineers are just doing way more engineering because of some of the power of some of the tooling now, especially around Next. I think that it's not that I necessarily differentiate.

I think the whole idea of those are let's add some really powerful frameworks to build out the base case. And so if the base case gets simpler, that's great. I think that the one thing that changes is if you have widespread adoption of certain patterns or certain frameworks, tooling will be made specifically for that. And so I think that's maybe a danger of just, you know, if everyone is using one thing and that's widely adopted, again, I don't, while I think, you know, Jamstack is very, very useful and it allows people to be very powerful by creating websites very quickly.

The web application is very quickly. You're always going to have more complicated use cases. So again, the simple cases get simpler. The common cases get templatized and that's great.

But at the end of the day, there's still going to be heavy lifting that needs more dedicated resources. What have you found in the Kubernetes ecosystem that's particularly lacking or have you seen any pain points in the current Kubernetes ecosystem as of mid late 2020? I think first of all, just in the few years that I've been using it, things have gotten considerably better. And I do think some of the tools around it, I mean, you have entire companies now just built on helping people get into Kubernetes.

And so I think because of that, it's kind of like what we were talking about before. The base cases are going to get a lot easier and the more complicated stuff maybe has some fuzz around the edges. I think for us specifically, you know, ingress design and routing and more specialized routing is really lacking. I think people really assume very basic ingress path routing.

I think sometimes there's not as much support elsewhere for more complicated ingresses. But in general, the one thing I'm still seeing, the thing I've never seen anyone do, and there's actually an application now that's the closest I've seen. I'm on their mailing list. I use them not fully, not I haven't completely switched over to this being my kind of window into our clusters, but it's called Infra.

And it's done the best I've seen about trying to really interact with your cluster and view what's going to monitor your cluster, individual workloads and deployments. I'm pretty impressed by that just in terms of the usability standpoint. But I actually think some of the introspection tools aren't that great. I mean, most people I know and I do too just end up using Q-Control.

And there's some, you know, you make some bash aliases and you're on your way. But I think applications specifically around using monitoring and interacting with your cluster and your deployments, your workloads, that I've never been to impress by. This one's close. It's the closest one so far.

And what's the division of labor among your team? How big is your team? So we're four right now, teams four. And fortunately Jason and I are both technical co-founders.

And then we brought on a backend infrastructure engineer in October. And then we have a former segment enterprise sales person who's helping us out a little bit as well on the sales front. So yes, four, three engineering, one sales. What is the sales model for a product like this?

I imagine it'd be pretty good because we have a really big organization. Everybody has to have access to it. Yeah, I mean, the way I see us kind of approaching sales, yes, it works really well. It's the most powerful when your whole team is involved.

I mean, what we've kind of seen is the first month will have maybe an engineer will set it up. And so we'll see an engineer come in, set it up, maybe invite one other person or just use it themselves. And then because once it's set up, it just runs, everyone starts to kind of trickle in a few weeks in. Like, oh, I've seen these links and then you join the team and start using it.

So usually we see it kind of grow naturally as it's just already set up. So for us, the most important thing for us is get set up and try it and then invite your team. And also we've specifically designed our free tiers to really make it easy to jump in. There's two different free tiers.

One is called Future Peak Indie. And it was basically our experiment cutting out all of the steps to get set up. Like, what is the absolute fastest way that you can create a feature environment or deployment preview? And so that's just a command line tool that as you're developing, let's say you're running a gaspsite, let's see, you've built your static bundle locally, you just type peak and it'll spit you back a link.

You can share that link. And that's all free for public projects. And then our teams free tier is for specifically for the open source community, but any public project on GitHub, if it's public, it's free. So it's really only paid for private projects.

That indie peak feature? So what does that do exactly? Does it work? So we set up the indie feature specifically.

It doesn't listen to pull requests. So the team's product, the main product listens to pull requests. It's a GitHub app that you install and you have to end, you put our little call or one line or in your CI pipeline. The command line tool is for really just kind of indie developers as you're developing.

It's a command line tool you install with Homebrew and you just type peak as you're developing. Like you build it locally, like you run, you know, yarn build or whatever. Whatever your build command is. And then you just run peak and it'll upload those assets to us, spit you back a link and you can copy that link and share it and invite people to your team that way.

It's creating an environment based on a commit instead of a pull request. We're really excited about that. We think that was really an experiment for us to cut out some of these steps, but we really want, we really think and we were talking about the sales process being interesting for us in terms of spreading across a team, but we also think the most important thing is just having people use it. So we've specifically designed it to, you know, we want people working on open source projects to try it.

We want people developing their own personal projects to try out people who are in engineering boot camps, who are learning, learning jobs, making their own web applications to just be able to try it for free. So there's a lot of options to just jump in and try it. That's great. Is there anything else you want to add about feature peak and what you built?

You know, I think we really want teams to collaborate better and review better. We think that the review process, especially for teams now more than ever, as teams are moving remote, as teams are distributed, as you have your designer in Austin, and you have some engineers in San Francisco or maybe abroad, we really think that there's so many ways to improve that feedback and review process. And so, yeah, we're really excited about it. We're having a great time building it.

And it's always fun to build something that you originally wanted for yourself. You don't get a lot of opportunities to do that. And so it's been really fun. Eric Silverman, thanks for coming on the show.

It's been great talking. Thanks for having me.