408: Shipyard with Benjie De Groot

Chad talks to Benjie De Groot, co-founder, and CEO of Shipyard. Shipyard manages, creates, builds, and deploys ephemeral environments.

Benjie talks about how Shipyard became a funded company, discovering who their ideal customers are, and building out the core team so Shipyard can accelerate and figure out their next steps in how to bring it to the masses.

• Ephemeral Environments
• Shipyard
• Follow Benjie on LinkedIn.
• Follow Shipyard on Twitter, LinkedIn, or GitHub.
• Follow thoughtbot on Twitter, or LinkedIn.

Become a Sponsor of Giant Robots!

Transcript:

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Benjie De Groot, co-founder, and CEO of Shipyard. Benjie, thanks for joining me.

BENJIE: Thanks for having me.

CHAD: Why don't we start by if you don't mind sharing a little bit about what Shipyard is and does?

BENJIE: Sure. At the core of what Shipyard is working on is ephemeral environments; not everybody knows what that means. That is changing a bit. But essentially, what we're focused on is on every pull request or commit for a feature; Shipyard manages, and creates, and builds, and deploys ephemeral environments. So that's a disposable one-off on-demand environment that any stakeholder in your internal company can use. And we focus on the tooling around that, on build pipeline, and then security around that. And then all kinds of other cool features that are necessary that pop up.

CHAD: Cool. So as a developer, I'm familiar with the concept of developing locally, putting up my pull requests. And also, we deploy a lot of stuff to Heroku. So I'm familiar with some of the infrastructure that Heroku might give. How did you arrive at saying like, this is a thing that I want to work on and believe should exist?

BENJIE: That's a great question. I actually am also a developer; that’s my background. And throughout the course of my career, I've always been on the technical side of the company. And what that's translated to, because of passion, to be honest, is always taking on a DevOps type role, so throughout the course of my career, a lot of responsibility.

I mean, I started off writing Bash scripts, went to Puppet, did Chef for a while, did Ansible. Somehow I went back to Bash scripts for a lot of this stuff. Then this company called DoCloud popped up, which obviously became Docker, and I kind of got obsessed with that. And then I had a bunch of friends at Google, and they were telling me about this creepy thing called Borg, and that became Kubernetes. And so, my career has kind of happened throughout that entire process. And throughout, DevOps has kind of been my passion.

Along with my co-founder, Peter, I was a high-priced Kubernetes consultant in the New York ecosystem just a few years ago. And a lot of companies were trying to make the transition to Kubernetes. And Peter and myself came in and helped people that were struggling to find DevOps resources. And what that always kind of looked like was there was some bespoke version of a deployment system that was perfect for the person that wrote it. But obviously, it wasn't good enough for me and Peter, for Peter and myself.

CHAD: [laughs]

BENJIE: And so we would rewrite it, and it would be great. But then, eventually, we'd move on, and someone else would rewrite it. And there were a few instances where we ended up going back to companies and just reimplementing what we had already done. And throughout that process of being this consultant, we kept running into this ephemeral environment thing and building the same tooling over and over and over again.

So Peter and I, on a weekend, kind of got, "Oh, let's make a tool for ourselves." So we did that. And we made this exoskeleton to help our consulting business. And as things progressed, we kept just adding features, and it was really fun, and it was great. And then some of our customers or clients saw that. And they were like, "Hey, can we click that button?" And we were like, "I guess."

And so slowly, it turned into a product that was very duct tape-y and glued together, but it worked great. And to be frank, I had been through the VC process on the technical side in the past and didn't want to go through that again, the hamster wheel of need to raise more and more money and so very, very averse. And was very set on a really nice lifestyle consulting business, and hell was going to have to freeze over for us to take any VC dollars.

And then I don't know if you heard, but in March of 2020, hell froze over, and [laughter] there was a little pandemic. And at the same time, we got some pre-emptive term sheets, yadda, yadda, yadda. Next thing you know, we're a funded company building out a really cool product. So that's the origin story of where Shipyard came from.

CHAD: Really cool. I definitely want to come back to what building the product for you has been like, and the funding, and where you go from here. But let's come back to the product itself. As a developer, my normal workflow is I'm working locally. I'm able to run the application that I'm working on locally here on my computer. I put up a pull request on GitHub. I ask my team to review it.

Once it gets reviewed from a code perspective or a design perspective and gets a thumbs up, I merge it back into the main branch. And I deploy it to a staging server, at which point I would ask my stakeholder, my client, whatever, "Hey, this thing you're expecting it's on the staging server for you to check out." And everyone else on the team is doing the same thing. So where does Shipyard come in, and why is it better than that?

BENJIE: So where Shipyard comes in, it's after the local development but before you get to staging or really before you get to production because, in practicality, a lot of people turn Shipyard into their staging servers. But what happens is through webhooks, we hook into your GitHub. And we see that there's a new commit that comes in. And we automatically build and deploy a fully ephemeral environment for that feature. And what that gets you is a few things.

One paradigm that we're seeing a lot of is when you make that PR, a lot of end-to-end test suites are being run automatically using Shipyard ephemeral environments. And what that gives you is, in some instances, before you even have a code review, you're passing the suite of tests. And what that gives you is you save a lot of time. If there's just a dumb migration error or some typo or something like that, you're not wasting human capital or human energy on those environments.

And the other instance there that gets really interesting is by bringing up these environments earlier on, product stakeholders and QA stakeholders can do their jobs earlier on in the process. And so you can avoid a lot of merge conflicts. So like, you merge something, and maybe there's an edge case that you hadn't tested for, and the code review didn't pick up. Well, all of a sudden, staging is broken. And some other team member that's using the same process you were now they're blocked. Or the client can't see that environment, and there's some other type of problem.

But really, we didn't invent this paradigm. This is what FAANG does. There's a reason why I can't remember the last time that Gmail itself a button broke, or there was bad CSS, or bad HTML, same thing with Facebook, same thing with Netflix. Obviously, we all know about –-

CHAD: There's the obvious DNS outages.

BENJIE: [laughs] Right. I was going to say we all know about AWS, especially in December of 2021. That was a tough month. But yeah, from a UI/UX and controllable release perspective, this greatly increases your internal stakeholders’ ability to get their hands on features earlier, find problems, and then get those back to developers.

And the other thing, and maybe this is a question for you. But have you ever been in a situation where you built something, and it doesn't actually get reviewed for a few weeks? And then there is a bug, and you have to go back, and context switch off of what you're working on and go back and put a whole other mental model in place to go back and remember why did I use a switch statement here? That's a bad example but something to that effect.

CHAD: [laughs] Yeah. Well, I really try to avoid that scenario by having tight feedback loops, but sometimes it's unavoidable. It might be you finish something right before a holiday or going away or something like that; that can happen. So it's happened to me before, yeah.

BENJIE: Right. And how do you get your product people or your UAT teams...when do they get to touch the feature that you're working on?

CHAD: It's usually not until after a code review when it's been merged into main and deployed to staging.

BENJIE: So that's kind of how we make that feedback loop tighter. And what we've seen in practice actually is a lot faster, more reliable releases. And there's a significant increase in the cadence of releases that can happen and a higher quality of those releases.

CHAD: You mentioned that some customers end up even getting rid of staging. And so that's really exciting and interesting to me. When they do that, what does the overall picture look like? Is the code merge manual? Or do you have customers that are doing continuous deployment off of a thumbs up from the person reviewing it in the ephemeral environment and getting that automatically merged, and then maybe canary deploy or something to production?

BENJIE: Yeah, that's a great question. The thing to keep in mind here is that the majority of our customers are larger, and they have bigger teams because obviously, this is a collaboration platform ultimately. And so there's more value for the more complex teams and more stakeholders. So we don't have anybody at this moment that I know of; there could be, doing LGTM is good enough. So there's always a manual component.

But what it looks like from a staging perspective is that your main branch is actually ostensibly your staging environment, and so all the ephemeral environments are sort of dev environments that are shareable. And then when you merge because a code review passes, and QA checks, and UAT, then it gets automatically built into the main branch and the main environment. And then some people do QA. They'll final pass a QA or a final end-to-end test there. And then there's also a manual promotion to production as well. That's the typical pattern we've seen.

CHAD: Cool. One of the things that when I've used...sometimes a problem even with staging. But when I've used or been on projects with some ephemeral environments, getting good data in those environments can sometimes be a challenge. Is that something that Shipyard helps with? Or what's your recommended approach to that problem?

BENJIE: So that was one of the biggest problems we had early on. We put a lot of work into that. We apply the same git branch model to data. So the way that we do that is basically if you...oh, by the way, I forgot to mention something. We use Docker Compose as our application definition. So we extrapolate from Docker Compose and transpile into best practice Kubernetes YAMLs. So there is a little bit of inferring and magic we do in certain places. And one of the places we do that is if you have a named volume...sorry, am I getting too technical, or is this --?

CHAD: Not for me. And in fact, I have follow-up questions about [laughs] why you have that approach of converting.

BENJIE: We will dive into that in a second. And I have a whole bunch of redhead friends that make fun of me about Compose all the time, but I stick to my guns on that one. But I'm happy to talk about that. At high level, if you indicate to Shipyard this is a persistent volume that we want to make sure that child environments get, then we will do an instant snapshot. And we will actually provide that to the generated child ephemeral environment. And ostensibly, what that does is it allows you to test data migrations as well on these ephemeral environments.

Now, to go back to your initial question, we encourage...and we're working on some partnerships actually with some interesting companies. But we encourage people to specifically have their main data set on main be ostensibly a copy of whatever the good data set is. But obviously, you're responsible for pulling out your own PII and all the confidential stuff there. But the key thing here is you're maintaining one environment with the right data on it. And then all of the subsequent generated ephemeral environments inherit that and can then change that.

CHAD: Yeah, that's cool. That solves a real pain point that I've had in the past when trying to work this way.

BENJIE: One company that I think is really interesting around this space is Tonic.ai. And we're actually working on some stuff with them, I think. But we share an investor, so that's why I know them, for disclaimer purposes. But they're great. And they have some really cool tooling around mapping your database to PII and automatic detection of certain types of information that you don't want pushed into your staging servers and to your developers' hands. So that's one to check out, too, if you're looking for data help.

CHAD: Cool. So do you want to get back to this Docker question? Why that approach of converting the Docker Compose into YAML for Kubernetes?

BENJIE: So this is quite a controversial topic.

CHAD: [laughs]

BENJIE: But I will tell you where it came from. Hearkening back to our origin story, what we saw was we saw a pattern of a lot of companies going a little bit too all-in in Kubernetes; let’s just put it that way, where every single one of the developers is running minikube or even K3s or K3d or whatever. And all of a sudden, the DevOps people and the SRE people in the organization are spending most of their time supporting developers in local development environments.

So early on in that consulting game, we realized we don't want to do that. So if you want to work with us, we think you can use Docker Compose for most things. Now, that's obviously not always the case. There are some companies and applications that have hundreds of microservices. So obviously, Docker Compose is not a very realistic fit for those people. But the majority of people can pretty much encapsulate their application in Docker Compose. So that's one thing.

The other thing is I mentioned to you that I'm a DevOps engineer for years. I'm sick of new YAML formats or specifications. So I have a saying, "Not another YAML, I say nay." My co-founder, Peter, hates when I say that, but whatever, I like it.

CHAD: [laughs]

BENJIE: So that's another piece of this. And then the biggest thing here is that we look at Docker Compose as rabbit ears on a television set. So you know, like a 98-year-old grandmother can somehow stand on one foot and hold the antenna the right way, and it's static. The picture is perfect, and they can watch...I don't know why I'm saying Jay Leno. I don't think it's on the air anymore.

CHAD: [laughs]

BENJIE: Sticking with the grandma reference, humans are really good at figuring out stuff like that. [laughs] And that's kind of what Docker compose is. It's kind of like if you can make it work locally, Shipyard is going to take care of the rest and clean up a bunch of stuff for you. So that's how we look at it.

Admittedly, we do have some Helm stuff we're working on and some Kustomize (with a K) stuff. And there are a whole lot of other interesting things out there. But frankly, we haven't run into problems with our current approach. And when we have tried to ingest raw manifests and stuff like that, other issues tend to arise. So we use Compose as a funnel to be very opinionated about our Kubernetes deployments.

CHAD: Well, I'm a big believer in, especially in early days having opinions about things. And it sounds like, with this particular opinion, you not only can help people at different stages and say that "This is good enough," but you're also casting a wide net for what people can do. You're not cutting people off because they already use Kustomize or something like that.

BENJIE: Yeah. And a lot of it is about accessibility. And so it's proven to be a pretty interesting thing. We didn't think that we were going to go this far with it. [laughs] We really thought that we were going to get in trouble soon. But it's pretty cool how it's going.

And also, I will do a shout-out to the Docker Compose community. They're picking up some steam here. I think a lot of people are realizing that it's a pretty good spec for most use cases. So I know that Docker released somewhat recently you don't have to do Docker-Compose anymore. It's just Docker Compose. And there are all kinds of Compose specifications stuff that I think is worth checking out.

Mid-roll Ad

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

CHAD: So to get a little bit meta for a minute, how do you use Shipyard on Shipyard?

BENJIE: The ultimate dog food. That is one of the biggest selling points to our own engineering team when recruiting. We've got a pretty spectacular team that comes from some pretty awesome companies. And people sometimes ask me, "Hey, how did you get these engineers?" And honestly, I think the answer is dogfooding. Because what we're building is what every DevOps engineer sets out to build every time they start their job, in my opinion.

You always want this ephemeral type of elastic environments are only on when you need them to be on. I didn't discuss this, but we also have functionality that we call SLV or Since Last Visit. So we know the last time someone went to one of these environments, and we'll turn it off for you. And then, obviously, it's very quick to turn it back on when needed. So there are cost savings. There are all kinds of stuff there.

But ultimately, we're building the ultimate DevOps tool. And so we use Shipyard to run Shipyard. We use it in our QA process. We use it in our end-to-end testing process. And we also use it in our production process as well. We have some of our...we do have a production offering, and we use that ourselves for our stuff. So it's a very recursive conversation around that.

And sometimes, when I'm actually doing a demo for various people, the only way to show or the only good demo I have of certain functionality is to actually show the Shipyard organization itself in Shipyard. And I get very recursively tied up, and people get confused. And it's always a bad idea.

CHAD: [laughs] Yeah, you have to queue the Inception music.

BENJIE: Yeah, exactly. We're at the third level. We're at the ice palace or whatever, ice hideout at this point. That's from the movie Inception for those that don't know what we're talking about.

CHAD: [laughs] Yeah, that's really cool. I imagine that...sometimes when I'm working on a project, and you get down to the instrumentation level, to those levels, it can be difficult to run the system on the system. Have there been particular challenges? It's not just a normal web app; I guess is the way of saying that. What Shipyard is isn't just a normal web app.

BENJIE: Yeah, one of the things that we do is that we have a pretty robust security posture, so every single one of our customers gets their own cluster. And so our security model is using the hypervisor basically, which, by the way, for anyone looking at Kubernetes, forget Shipyard for a second. Please understand that if you're in a shared namespace anything, our back is great, but don't do it. There's a CVE around on the corner, I promise you. Don't do it. Anyway.

CHAD: [laughs] That's a good PSA for people.

BENJIE: Yeah, right? [laughs] Yeah. So some of the cool challenges we've had is we early on, we definitely had some stuff where if we did a bad release, we would break our own ability to fix our own releases. So that was that way early on. We figured that one out very early. I think that was even before we were a product even. That was just a few sleepless nights of Peter and myself being like, oh God; we got to fix this so that we don't screw up this client's website. So that's been interesting. I mean, that was really it.

And my co-founder, Peter, is listening to this, and he's like, there are 4,000 different things I've fixed over the last few years that were a problem around this, and I can't bring them up. But there's a lot, and I don't know what they are. And Peter is very good at fixing them. So that speaks to my co-founder and the rest of the team.

CHAD: So you mentioned that March of 2020 happened, hell froze over. And you found yourself thinking you're going to take a different path and fundraise and become a funded company. How difficult did you find fundraising in that environment, or was it easy?

BENJIE: It was real tough at the beginning there. For one, I have no idea what I'm doing. [laughter] That's just the truth. Maybe I should say that in the past tense. I had no idea what I was doing. I still feel like I have no idea what I'm doing.

But like I said, I come from a technical side, and I'm a bit of an engineer. So if a VC asked me a question and the answer is yes, but I have to qualify it with some weird edge case that I came up with. That's not a great look for these types of pitch meetings. So I would suggest people not overengineer answers to questions, yes or no works very often. So it was challenging.

But also, at the time, I'll say that there was definitely some predatory term sheets going around because this was really early, and we had no idea. And I was a fool...I wasn't a fool, but I had no idea. We're running this consulting company, and I'm like, oh my God, all my customers are funded. They're all going to go away. We had some pretty large customers. It was very irrational looking back. But it was a crazy time. Also, I should mention that we're in New York. So things were heightened a lot more also in March of 2020. It was very intense, and so I had to learn a lot.

And basically, the realization like, oh, if the world becomes remote, software is just going to go crazy had not seeped into my brain quite yet in March or April. So did a lot of learning that way. We were very fortunate to have some really helpful people along that path and eventually figured it out.

I will say, funny story, I literally didn't have a pitch for three months. I would just do a demo and talk about stuff. And then a friend of mine was like, "Oh, what's your pitch?" And I was like, "I do a demo, and I talk about it." So he's like, "Dude, you got to have a pitch." So that helped a lot once I figured out [laughs] that I needed a pitch.

CHAD: It did help. So you recommend people have a pitch.

BENJIE: I would say that that is a positive, yes. Having a pitch is helpful. I know that that's a ridiculous statement here, but I literally didn't have...I just didn't think about what's my pitch?

CHAD: Well, I think it's simultaneously a ridiculous thing but also there exist in the world things that people do just because that's the way that they're done. And so it's valid, I think to say, "Do we really need that? Can we get by without it?" And if the lesson learned there is actually there's a reason why people do it and it is valuable, that's a valuable lesson. It's too bad you had to go through it to discover it.

BENJIE: Well, yeah. I look back fondly at that. And I wouldn't say I was being contrarian. I was just kind of being a jackass, frankly. But I learned a lot. And honestly, in the end, I couldn't be happier. I'm pretty anti-VC. Everyone knows that about me. I like to make fun of them and all these things. But I couldn't be happier with our investors, and they've been unbelievably supportive. And so that's been a super positive.

The one thing I would say to anyone listening to this podcast that has to go out and raise money is you got to get really good at letting things roll off your shoulder. As an engineer, it's really hard for me to deal with any level of rejection because I'm like, oh, it works, or it doesn't work. Oh, you found this edge case that I didn't think about? Oh, you got me, but I'll fix it now, and now it's fine. That's not the way that fundraising works.

You have certain conversations, and you feel super positive. And then, all of a sudden, you don't hear back from this person for weeks at a time. You have other conversations where you think that it was the worst thing that you've ever done. And the next day, you get a term sheet.

I had one pitch...this is when I knew how to do a pitch. This was a few months in. I had this one pitch, and it was all virtual, and it was very early days in our remote world. And there were four partners on this call and a few associates or whatever. And I do the pitch, but everyone is muted on Zoom for 45 minutes. Now, it's pretty clear from our conversation that I talk a lot. So it's not the end of the world. But I had no idea what was going on. And I just thought that I had bombed it. It was horrible, all these things.

And the next day, I got an email, and it was three introductions to amazing opportunities. And two of them actually panned out. We didn't end up going with that fund. But I just thought it was hilarious that I was convinced that I shouldn't be doing this, and it was the opposite. So you never know. That's the other thing I learned is you literally can never know what's going to come of any particular meeting in the VC fundraising world.

CHAD: So how long did it take you from the point that you decided you were going to do this and you were going to start trying to fundraise to actually getting the investment in the bank?

BENJIE: Probably four to six months. We obviously had some opportunities, but as we went through this process, realizing that having the right partner for the next 7 to 10 years was really important. And we ended up with our lead. I can't believe I'm talking positively about a VC on a podcast but whatever.

CHAD: [laughs]

BENJIE: Our lead, Owen Davis from Contour Venture...Contour is like this New York fund that they do everything, but no one knows their name. Oh, he's going to love that I said that but whatever.

CHAD: [laughs]

BENJIE: They're great. He's great. And he's the dream investor for us to lead. And then we have other...and I'll mention Shruti over at Array and the folks at Heavybit and Work-Bench as well. They're all in this round, and it all came together. And I was a little picky. So we kind of took our time. And I suggest that if you have that luxury, which we did because we already had a successful consulting business, make sure you know who you're getting into business with for sure. And we got very lucky with that.

CHAD: So how much time while you were fundraising did you personally work on that as opposed to other things for the product or the business?

BENJIE: I should have probably put a little bit more time to the fundraising. To be honest with you, I would say I probably put 50% to 60% of my energy into the fundraise, and then the 40% was all building product. As an engineer, you have a really frustrating call, or you think you're doing well, and then you're not, or vice versa. So for me, I would retreat into building. And so I probably retreated into building a little more than I should have to be frank, [laughs] but it worked out in the end.

CHAD: While you were doing that, you supported yourselves from the consulting revenue.

BENJIE: Yeah, for the most part. We still had active clients. So we converted most of those...actually all of those into Shipyard customers. And they were very supportive in that process, by the way, doing due diligence calls for us. They were all very helpful.

CHAD: And how did you decide how much money you should be seeking to raise?

BENJIE: Ultimately, that was something I struggle with just because I really want to know what I'm going to do and what the plan is. And one of the lessons that I've learned as a CEO now is your job is basically to make unbelievably important, critical decisions with little to no data and just hope you're making the right one and then adjust quickly if you're not. So understanding when you've made the wrong decision.

But ultimately, to answer your question, I built out a spreadsheet. I had a wish list of engineers that I knew or positions that we needed to fill, probably underestimated some of the product marketing needs that we would need to do. But built out a model and then figured, hey, how can we get there in 18 to 24 months to get to the next round?

Because you really do have to be making sure that you can...I mentioned the hamster wheel early on; maybe that's too negative of an analogy there. But you have to be thinking about your next round. And so you have to get to what metrics you want to hit. And you just work backwards from there.

CHAD: At what point along the way...you mentioned earlier that your customers tend to be larger companies. At what point along the way did you discover who your ideal customers were?

BENJIE: I think we're still discovering that. We're still figuring that out. But for me, this tool Shipyard, and I've seen it, if you start using a tool like Shipyard from day one, the gains and the benefits are just insane. We had one company that started off from scratch with us. And within two months, they had extremely robust software development lifecycle, production deploys, all kinds of stuff. And they've been going now for years...not years but a year a half or so with us and super successful.

So I always wanted to be like, oh, startup X with two engineers you should use us. And the more we talk to them, the more conversations we had. We're just like, this is not a DevOps priority. DevOps is not the priority.

CHAD: Especially in those early days, I feel like there's such a tendency, especially from engineers, to say, "Oh, that's not that complicated. I can do that," or "We don't really need that. Let's piece together this."

BENJIE: Yeah, that's exactly right. So then, as we started to talk more and more and understand what people were doing, we just fell into this ICP or Initial Customer Profile of more complex teams that are really facing these problems. I mean, specifically, when you get to a certain size, a bad release costs you a lot of money, customer success, customers that are leaving you, frustrated sales execs, frustrated product people, frustrated QA people. So it's when you get to these more complex levels is when you need this type of tooling.

Now, one thing Shipyard released actually very, very quietly, but you know, it's released. We released a 30-day free trial. It's kind of like our light tier, so people can start doing it. And we're starting to see some people at the earlier stage companies starting to do this, which is exciting to us. But our goal as a company is absolutely to figure out how to get this to the masses because ephemeral environments is the paradigm of the future. I mean, it's the paradigm of the present with the big tech companies. And it's now coming down to the rest of us.

And so instead of having to hire five DevOps people to build the system out for you for six months, you hire one DevOps person, and that DevOps person shifts into an SRE role, not entirely, but their concerns are more about reliability of the actual site rather than reliability for developer environments or QA environments or staging environments. So we think that's really powerful.

One thing that I probably should have mentioned way sooner is we have a community site that we've donated, and we're more than happy to have some pull requests come in. We've had a few. ephemeralenvironments.io, yeah, I don't know how to spell ephemeral either, but you can Google it. It will come up.

CHAD: [laughs]

BENJIE: ephemeralenvironments.io, and it goes through the different use cases of ephemeral environments and where there's value there. So that's kind of the goal with all this.

CHAD: So what are you working on now? And what is the next stage for the company, I guess also from a product perspective? But also, you mentioned that hamster wheel. [laughter] You're coming up on 18 months of being on that wheel, right?

BENJIE: We are. One thing is we've had some success, so our revenue is pretty solid, but no rest for the weary. But we're probably going to go out and bring in some more capital pretty soon. And the reason for that, because that's always the important thing to me, is that we have some pretty spectacular design partners, some pretty big logos, all these things.

The product is there. The product is killing it. I couldn't be more proud of the product and the team. We've also started to build out the core team and couldn't be more proud of that. And so now we need to accelerate and figure out our next steps and how to bring this to the masses.

And ultimately, the vision of Shipyard is to make all this stuff move a lot faster, bring velocity to teams, and all that stuff. And we believe that ephemeral environments are a huge component of that. So we're probably in the next few months going to probably go out and look at our financing options. I will say that the market has been a little insane. So I feel like all the education that I got in 2022 is probably out the window because some of these valuations and other stuff seems like it's a frothy market, as they say, but we'll be doing that.

And we're really going to probably double down on figuring out what the community needs and where the value is for the community, so both with ephemeralenvironments.io. But also, there are some really cool internal tools that we've built that solve some of the issues within the Kubernetes ecosystem. Okay, that's a strong word. They help a lot. I'm never going to say I've solved anything in Kubernetes.

CHAD: [laughs]

BENJIE: But they help a lot with understanding why the state of your application is maybe not where you want it to be. And so, we'd like to probably contribute a bit more back to CNCF, in particular, but open source in general. So continue to build the team to work on that. And then, obviously, pushing forward with product and some pretty cool stuff we have on the roadmap that we're really excited about.

CHAD: Awesome. Well, I wish you all the best with that. If folks want to find out more about Shipyard, follow along with you, get in touch; where are the best places for them to do that?

BENJIE: Really, shipyard.build is our website. And that is probably the best place to try it and also to contact us. Our Twitter is @shipyardbuild twitter.com/shipyardbuild. Personally, I'm not a fan of Twitter. So I personally don't use Twitter, but we do as a company. And I think that our Twitter and our website are probably the best things to reach out to, and obviously, sales@shipyard.build you can send an email there. But I think you'll probably find the information you're looking for on the website. And if not, please let us know what's missing.

CHAD: And you mentioned the free trial. So I feel like that's a great thing for people who want to get more into the product; they can give it a try, right?

BENJIE: Yeah. And one thing to note about the free trial the reason that it's kind of cool is it's your own cluster. You get your own cluster. It's completely single tenant. It's pretty dope. It's pretty cool. And you can really take it for a spin. I would suggest, I mean, we've had a lot of success with companies that are using Docker Compose already to just dive in there and get their application running.

But I would say that we have some pretty cool starter apps as well. They're linked in our docs and our GitHub. Just seeing the power of this through our starter applications has also been a great experience for a lot of people. So I'd suggest taking a look at that.

Oh, and I should plug a podcast that I'm a co-host of, Kubelist. I do that with Marc Campbell from Replicated, where we interview CNCF open-source projects all the time. That's why I got to be careful pretending like I'm solving anything. There are a lot of options in the Kubernetes landscape.

CHAD: Wonderful. You can subscribe to the show and find notes and a full transcript of this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Benjie De Groot.

Support Giant Robots Smashing Into Other Giant Robots