Steve Krouse, founder of Val Town, appears on 'The Next Next' to discuss his platform designed to make coding more accessible and collaborative. Val Town focuses on simplifying code portability and integrating AI tools while fostering an interoperable and open ecosystem for both seasoned developers and beginners. Steve highlights the need for programming tools to be web-based for better collaboration and outlines the challenge of traditional code collaboration. He also shares ValTown's growth strategy, the future of AI in coding, and how Val Town aims to democratize programming through features like cloud-based deployment and AI integration. The episode explores the vision for Val Town, its development history, and the broader implications for the tech community.
Democratizing Programming: The Vision of Val Town with Steve Krouse In this episode of 'The Next Next,' host Jason Jacobs interviews Steve Krouse, founder of Val Town, a platform designed to make programming more accessible and collaborative through web-based tools. Steve talks about the challenges of traditional code collaboration, the integration of AI tools into Val Town, and their growth strategy focused on interoperability. He emphasizes the potential long-term impact of Val Town on democratizing programming for both professional developers and newcomers. The conversation also explores the evolution of AI in coding, the importance of accessible programming, and fostering better collaboration within the tech community. Additionally, Steve shares insights into the medium- to long-term vision of Val Town, the importance of creating web-native programmable interfaces, and the company's approach to leveraging AI without directly competing in AI code generation. The episode offers a deep dive into the future of collaborative programming and how Val Town aims to shape it.
00:00 Introduction to Steve Krouse and Val Town
01:02 Host Introduction and Show's Purpose
01:52 Steve's Journey and Initial Interaction with Val Town
03:35 Steve's Background and Climate Interest
07:06 Genesis of Val Town
15:13 Challenges in Code Collaboration
21:34 Val Town's Vision and Future
36:46 Google Docs for Production Code
37:42 Enhancing GitHub Collaboration
39:38 AI's Role in Val Town
41:18 Shifting AI Strategy
44:43 Integration and Openness
49:09 Growth and User Engagement
58:17 The Future of Programming and AI
01:04:57 Community and Collaboration
01:09:01 Val Town's Vision and Goals
01:10:08 Conclusion and Contact Information
Jason Jacobs: Today's guest on The Next Next is Steve Krouse, founder of Val Town. Val Town is a platform aimed at making programming more accessible and collaborative, particularly through web based tools. Steve discusses the genesis of Val Town, the challenges of traditional code collaboration, and how Val Town aims to make code more portable and easier to run in different environments.
He also delves into the integration of AI tools into Val Town and shares insights on their growth strategy, which focuses on interoperability and openness rather than directly competing with existing AI code generation tools. Steve emphasizes the potential long term impact of Val Town and how it aims to democratize programming, allowing both professional developers and newcomers to build and share code seamlessly.
The discussion also touches on the broader implications of AI in coding, the importance of democratizing access to programming, and fostering better collaboration within the tech community. This is a great one, and I hope you enjoy it. But before we get started.
I'm Jason Jacobs, and this is The Next Next, it's not really a show. It's more of a learning journey to explore how founders can build ambitious companies while being present for family and not compromising flexibility and control, and also how emerging AI tools can assist with that. Each week, we bring on guests who are at the tip of the spear on redefining how ambitious companies get built.
And selfishly, the goal is for this to help me better understand how to do that myself. While bringing all of you along for the ride. Not sure where this is going to go, but it's going to be fun.
Okay, Steve Krouse. Welcome to the show.
Steve Krouse: Thanks so much for having me.
Jason Jacobs: I'm psyched for this one. We, let's see. We met because I was tweeting about the frustrations that I was having as I was attempting to break the ice and hack with some AI coding using Replit. it and for anyone that hasn't listened to me before, I am the opposite of an engineer. And you slid in my DMs and said one I've been following you for a while, back to MCJ and two, I happen to be founder of this company that might be able to help you and we spent a little bit of time exploring that and ultimately no knock on Val Town or it's offering more of a timing thing.
I was like, okay. This is too much brain damage right now, and I just set and forget with Squarespace. I was just trying to get a basic website set up, and it was like, it wasn't strategic for me, I just needed it. Done and so I just went with the far most cookie cutter version But that doesn't mean I'm done with coding with AI.
It just means at that moment in time, but at any rate There's a lot of ground that I'm looking forward to covering with you On that and a lot of other things and I'm super grateful that you're making the time to be here
Steve Krouse: Yeah. Yeah. Thanks for inviting me. I, yeah, I guess obliquely I was following you before MCJ because I have been a run keeper user for so long and I still use it. And then I, yeah, I found MCJ and thought it was awesome. And I listened to it like all the episodes, like at the time when you only had 10 or 20,
Jason Jacobs: I was gonna say because all the episodes is like many hundreds. So that would really be a lot of episodes
Steve Krouse: I tapped out at 10 or 10 or 20 or 30 episodes. It's amazing you kept it going for so long, but yeah, it's such an honor to be invited on your new podcast. Thank you.
Jason Jacobs: And if I remember right, Steve, you were kicking around at doing something in climate at the time, which is why you were tuning into MCJ, and so you didn't just tap out of MCJ, but you ended up tapping out of working in climate, right?
Steve Krouse: Yeah. Yeah. My interest in working climate never became all that serious. I. I forget. I thought like you, I found myself in between projects and was like wondering what to do next with my life. And climate was on top of the mind as like having a good impact on the world. And I remember telling my partner at the time, I vaguely want to be helpful in climate.
I don't know what I should, like how I could even be helpful. I don't know anything about it, but if I interviewed the experts in the space and made a podcast about it, I know that would educate me about the space and make me an expert. And she was like, that's a dumb idea. And some, for some reason I was like, you know what?
I bet this already exists and immediately I found your podcast and you had come up with that exact same idea and we're pursuing it. And so you saved me a lot of time. I didn't have to go and. Get the people and talk to them. I could just listen to your conversations So it gave me that education on the space of climate much faster than I wanted and then to your point of Me not like leaving climate I left with a sense of optimism that like so many smart people were doing really amazing things in climate and that I Didn't need to do climate like I could get back to this sort of stuff that more naturally Excites me
Jason Jacobs: And the reality is whether it's climate or anything else nothing worthwhile comes easy or happens quickly. And therefore, if you want to do something worthwhile, it needs to be a really good fit with your zone of excellence and delight. Otherwise, you're not going to have the staying power to to see it through.
And and so just having passion for the problem space. I would say, whether it's climate or anything else, it's not enough.
Steve Krouse: So anyways, yeah, that's how I found MCJ. And I guess to give some more context, I had done that something similar to MCJ for my, for the area that I was, and still am super passionate about, which is programming. So I started a podcast called the future of coding, where I did what you did with MCJ.
Basically, I went around interviewing experts about stuff and orienting myself in the field. And it has this wonderful. Knock on effective, like it all of a sudden makes you an expert in the field or at least like people know your name now all of a sudden, which is very cool. It opens a lot of doors.
Jason Jacobs: why are you giving away my secrets, Steve? And you're also, I, I was doing a little homework out ahead of this discussion and I don't know what to make of you because it's are you a DevTools guy? Are you a social network guy, are you an AI guy? And I think you're going to say I'm some combination of the three, but but before I lead the horse what, how do you think of yourself?
Steve Krouse: That's a good question. I feel like fundamentally I really identify with being a programmer. And then these days I really identify with being like a startup founder and CEO, I guess CEO is maybe a little too grandiose, but like the guy who's running the ship of a small startup. That's like my main identity.
There
Jason Jacobs: brother works at a big bank and and that's, yeah, he makes fun of us startup people all the time because he's Oh, CEO, you can literally just incorporate something using like LegalZoom or something, and then order business cards from Vistaprint that say CEO, and you're a CEO!
Congrats! With no qualifications, so
Steve Krouse: There go.
Jason Jacobs: yeah,
riverside_steve_krouse_raw-synced-video-cfr_jason_jacobs's stud_0079: That's me.
Jason Jacobs: so I mean tell me how you found yourself in this seat as Founder and CEO, and I guess I'm, I could ask that generally, but I'm also asking specifically About how Val Town came about.
riverside_steve_krouse_raw-synced-video-cfr_jason_jacobs's stud_0079: Okay. Yeah. So I, there's a, I feel like there's a long road that led to Val Town, but the
Jason Jacobs: And take us back as far you choose how far back we start.
Steve Krouse: okay. I think for now I'll start two and a half years ago where I I guess maybe I'll start like four years ago, three or four years ago, I decided that I wanted to start a DevTools company. It's like long been a dream of mine to start a company. I'm passionate about the DevTools space. I'm passionate about like the way that companies can make an impact on the world.
Like for positive, like in positive ways. And so I guess what's it? Oh, and I like saw some dev tool companies doing it like Vercel or Retool or GitHub. I thought those companies were really changing the world for the better. And I wanted to start a company like them. And so I was like rooting around for startup ideas.
And like I was prototyping in public and blogging about different startup ideas and trying some out. And one of those experiments. And I was like talking to friends and advisors and investors about what I should do next. And I struck up a friendship with one investor, Dan Levine at Excel. And he, and I cooked up the idea for Val for what has become Val Town and yeah, Val Town's about two and a half years old now.
Jason Jacobs: And what did you talk about?
Steve Krouse: What did Dan and I talk about?
Jason Jacobs: Yeah, like you say, he cooked up the idea. I'd love to just, I hate to use all these cliches, but I'd love to double click on that. Yeah.
riverside_steve_krouse_raw-synced-video-cfr_jason_jacobs's stud_0079: Yeah. Yeah. Sure. Yeah. I feel like that conversation, I have such a good memory of it. It was me and my co founder of the last experiment at the time and Dan Levine sitting in South Park in San Francisco, like on one of those little benches where like all the VC firms are around.
And I, we were, I was like, Dan do you have any startup ideas? I was like, I'm think I'm thinking about joining a startup. Do you have any ideas? He's oh, no you should start something, and sure, I have ideas. And he just started listing his ideas and my my co my former co-founder, my co-founder at the time, jp, he was like not interested in these ideas in particular, the idea that became Valentine that I liked, he was like not at all into it.
And so Dan and I were like trying to like. Concoct a company and JP was like, no, that wouldn't work. Or no, I don't like that part. So that's what, that was the actual tenor of the conversation. But yeah Dan had this idea like in his back pocket and he'd spent like I don't know, seven years trying to convince someone, some idiot, to to start a company around this idea, and and, he finally found me to take him up on it.
That's one way to pitch it. And the way he, I guess I can get, maybe this is what you're asking, The way
Jason Jacobs: what's the idea?
Steve Krouse: he, the way he pitched it initially was isn't it sad that there's code on the web that doesn't run that you like code and documentation is just like dead code. Code and repos is just dead.
If you want code to run, you have to do a bunch of stuff to get it to run. There's yeah, there's this big disconnect. There's no, it's like. There was Microsoft Word, but there was no you needed Twitter to actually get people to put their thoughts out on the internet.
There's no web native running code primitive. That's the thing that, that was Dan Levine's seed of the idea.
Jason Jacobs: To use an analogy and caveat this entire discussion with the fact that I'm not a coder. But but is it almost like social networks are for getting your self and your ideas out there? And Val Town is about getting yourself and your code out there.
Steve Krouse: Yeah, that's not so far off. I think a lot about interfaces and like APIs. An API is like a kind of interface. And. Twitter is a kind of interface, and like email is a kind of interface, and Facebook is a kind of interface, like you can have friends, you can have likes, you can have posts, and when you like have a presence on one of these social networks, all of a sudden you've exposed a kind of interface to you as a person, and like people can DM you like you, just by being on Twitter and having your DMs open allowed me to DM you, and start a conversation and that, that's amazing and super empowering.
But an average everyday person can't expose more programmatic interfaces. And that's maybe where Valton would come in. You can make yourself a website like you did on Squarespace, and you can have an email address so people can email you. Those are interfaces, those are like ways into you.
But if you truly wanted a programmatic interface for you, that, That could that that's harder that and that's maybe more where Valton would come in I
Jason Jacobs: How do you define a programmatic interface?
Steve Krouse: Yeah it's one of those slippery distinctions From a Like I think this question might be easier to answer from a vibes perspective typically a human interface would be one that has a UI. And so if it's on the web, that'd be HTML if it's on an app, it would be like a mobile app. That would be a human interface.
And then typically an API, a programmatic interface, would be like something that looks like JSON. It looks like data. Like a CSV could be more of a machine interface. And then I feel like an obvious question, maybe you're thinking, maybe not, is why would a human want one of these interfaces?
Jason Jacobs: I'm also just thinking about what is the JSON or data or CSV, But Before we talk I do want to know why a human would want one of these interfaces, But first I want to ask a precursor question, Which is, what does an interface like that look like for humans? And then I want to know why they want it.
Steve Krouse: What does an interface like that look like for humans? Do you want me to show an example of one of those interfaces or just describe it?
Because it's going to be more of
Jason Jacobs: could show it, but the only thing is that this is gonna be, like, some people might be audio only so they won't be able to see. But, we are gonna publish the video, too.
Steve Krouse: Yeah. Yeah. I like the classic example of an API just to give it a make a concrete would be like the weather.
And so you could have a normal human interface to a weather and that's a weather app or like weather. com. That'll be a normal human interface. But I think weather. com, for example, also has an API version, which is like the other side of the coin. So you would go like api. weather. com slash V one slash Weather and whatever, you and you type in the path or the Latin longitude and then it will return the same weather results that you'd get as a human, but they're like they're formatted, not pretty.
There's no visuals. It's just text. It's a formatted like a machine, for more for machine.
Jason Jacobs: Huh. And and how might one utilize that and in, in what cases is that a better path than utilizing the weather application?
Steve Krouse: Yeah. So if you're. Using your human eyes, you want a normal UI. That's what UIs are for. If you're writing code to interact with an external system, it doesn't have human eyes. And so how is it supposed to parse out, that it's 72 degrees now and next, in an hour, it's going to be 73 degrees.
How is it supposed to parse out that information? And a naive implementation would be like, Okay, like, why don't we load up the website, take a picture of it, and then have the computer do what a human would do and look around on the screen for that information. That's like one.
But in reality, what you want is you want that information structured in a way that's like very easy for you, the programmer in code to navigate the information without having to think about, color contrast and where on the page it is. You want to structure the information at the bare essentials so that, yeah, you can navigate it in code.
Does that make sense?
Jason Jacobs: It, it does. Now bring that back to where we started, which was that when Dan pitched the idea, he talked about how there's code on the web that doesn't run that, could be in documentation or in, Repositories I guess tie those two together since it, it sounds like they do go together, right?
Steve Krouse: Yes, yeah, they do. They do go together. APIs are like, basically, there's this like underbelly of Yeah. All the services we use that are only accessible to programmers. There's like extra level of customization that only programmers can use. Like the normal human gets, like they're called apps 'cause they're like appliances that are on your kitchen counter.
And like when you have an espresso machine, you're like put in the pod and you close it and you press a button and that's all the custom customization. You can't, you get, you can't grind the beans to a different level. You can't specify anything else. And so what Val Town is about is bringing that extra level of customizability to, to more people, like democratizing programming is like the core mission of the company. So in terms of APIs, this one's a little bit subtle of like why an average everyday person would want an API. Here's a strangely popular one, people really love sharing with the world what they're listening to. I don't. I don't entirely get why, but people just love letting people know that this is the song they're listening to on Spotify right now.
Or here's the song that they most listened to last week. People just like love sharing their music preferences in an ambient way. Like they just listen to music and then they have some system that shares their music history. And a lot of people use VowelTown to get that data from Spotify or wherever they listen to music, wherever that data is stored and then transform it in the ways it might need to be transformed and then display it somewhere.
Interesting for people. So we've had people display that information on blue sky. Like they have a blue sky account where they'll just tweet out there, like in an automated way, post that information or they'll have a little section, a little widget on the top of their website that just shows what song they're listening to.
We even had one guy in Boston, he made a great YouTube video of building a digital bumper sticker that shows on the back of his bumper sticker, what he's listening to right as he's driving, like right then and there. It's awesome. Yeah.
Jason Jacobs: So when Dan pitched the idea that isn't it sad that code on the web doesn't run, right? What was sad about it to Dan? And what did Dan envision, or you and Dan, as you were chatting, what did you envision that would make you happier?
Steve Krouse: Yeah. I guess to bring it back to APIs a little bit, so Dan used to work at Dropbox, on their API team. And Dan was building The, like the way in which other developers should integrate with Dropbox and, if you ever use any third party app and Dropbox that worked through the Dropbox API and one challenge that Dan had is that some APIs like parts of the Dropbox API were very complicated and nuanced and tricky to get right and so he would write some code to help his customers use His a this API and he would send them in an email or whatever Here's the code.
Just go and run it and that's Just go and run it is surprisingly difficult Basically, the thing that made him sad and it makes me sad is that when you have code working somewhere, it's surprisingly Unportable, it's surprisingly hard to get that same piece of code Running on a different machine or by a different person.
That, that's the thing that makes us sad. It's the absence of collaboration, or like how hard collaboration is because code doesn't run, doesn't just run.
Jason Jacobs: And what is it that makes that collaboration hard? Why is it so hard to port it?
Steve Krouse: So if you have code running somewhere, and you want to get it running somewhere else, First, like the first question is, okay, like what operating system are we talking about? What programming language are we talking about? So you'll have to install the programming language in the right way for the operating system.
And then you have to install the right dependencies, like all the packages and libraries that piece of code uses. Then there's environment variables that like might be used, like your open API key or other like authentication primitives. And then,
Jason Jacobs: You realize you're giving me PTSD to when I was banging my head against the wall with a flat plate, but And other tools! I've tried a few, but but anyways, keep going.
Steve Krouse: Yeah,
Jason Jacobs: get there, I'll get there, Steve.
Steve Krouse: Yeah. And oftentimes you have to set up Git and GitHub. And these things are a pain for professional developers. And then for non professional, people who don't know how to code or are just learning like you, they're like total showstoppers. The thing that really gets me is that GitHub repos don't run.
Like you have all your source code on GitHub. And presumably it runs on like The machine of whoever built it. And now I, as a pro as a programmer, want to make a contribution. I got, let's pick an example that I feel like could be motivating. So I feel like a lot of apps on GitHub aren't even built in this way because like nobody, even if you could contribute it, like people wouldn't.
But anyways, let's say you're using an app, like you're using twitter or any app you want and you want to make a small change. You want the button to be a little bit different. You want to fix a bug that exists. I think where most people get stuck is you can't even run the code in order to like.
Get it working to then make a fix to then see what your fix looks like. Like you're stopped before you even get started. Like this ability to run someone else's code is such a fundamental thing. Like even like at my startup, the code base I started it's a non trivial task to get our app running on your, on a computer.
So it's really hard to contribute if you can't even get something running.
Jason Jacobs: Doing something here. Was it more that you had clearly identified the problem or had you also uncovered a potential way to address it that was compelling?
Steve Krouse: Val Town is more about a vision of how things could be. And less about people having a problem or a particular solution. I think the core North Star for Valtent is that we just believe that programming should be simpler and easier and more collaborative. One part of our vision that I think is very fraught and nuanced is that we believe programming belongs on the web.
From my perspective, the web is One of the best things that ever happened to the world, and I love how all sorts of pro tools that you never thought could exist on the web, like Figma brought kind of Photoshop kind of stuff to the web, and now there's all sorts of video editing tools that are being brought to the web, like you and I are chatting right now on a live streaming tool that's in the web.
To me, it's so wonderful that all these tools are being brought to the web and coding still hasn't been brought to the web. And there are a lot of people who are trying, like Repl. it. But nobody's succeeded. And that was part of what Dan helped me see. That just because people have tried and failed doesn't mean that it's impossible or will never succeed.
Like before Facebook, there was MySpace and Friendster. Before Slack, there was a lot of other chat apps. Just because people are trying and failing actually, it actually means that there's a huge opportunity here that's very hard to get right. Okay.
Jason Jacobs: And did you have a point of view at the time? I'm sure you've learned a lot in the last two and a half years, but when you were just, when you were just having those, that initial discussion, did you two have a point of view about why the ones that had tried We're not succeeding and what you would do different that would bring about a different result potentially
Steve Krouse: Yeah. My, my criticism of Repl. it has been that they're like a jack of all trades, master of none. And whenever I've tried to use Repl. it Repl. it's so amazing for teachers, and Repl. it's so amazing because they support every programming language. And so whenever I'd want to do something and I want to try out Elixir or Haskell or some random programming language, I'd go to Repl.
it. And it would be able to run some stuff, but it wouldn't be able to run any packages of that. Language, they wouldn't have any of the bells and whistles you need to actually be productive. So I think that kind of speaks to them like having spread their focus. So going in I was and still am deeply committed to only supporting one ecosystem, the JavaScript TypeScript ecosystem and doing it to the best of my ability.
Even just supporting one ecosystem is incredibly hard and I guess like the relevant thing to bring up is that what people really want, what my users have been begging for since day one is they want to be able to edit, they want to be able to use our cloud offerings, but not use the web. They want to be able to use their local desktop editors, which, breaks my heart because the whole point is we're trying to bring these things to the web.
Like why do you want to use your desktop tools? But, I get it. Those desktop tools are really powerful. They've had so many hundreds of years of programming effort put into making them amazing.
Jason Jacobs: And what are what? Are some of the desktop tools that you're thinking of when you describe them
Steve Krouse: So the obvious one right now that everyone wants to use is Cursor. But before that it was VS Code and after Cursor is now this new one, Windsurf. And then there are a lot of AI agentic tools like Klein and Ader. And then Anthropic just released Clod Code, which is a local tool. And then you have old school folks who still want to use Vim Sublime Text.
So one of the wonderful things about programming is that It's just text, and so you can bring your own editor and still collaborate with everybody. Programming is like email in that way. Everyone on the team can have a different text editor and all collaborate. That's the good part. The bad news is that nobody wants to leave their favorite tool and go to a new web based one. But sorry. I guess just, I feel like then the question is if nobody, if everyone likes their local tool and nobody wants to go to a web based one then why are you trying to make them? And to me, I just put out there that part of why the web is so important is for casual users and for new users.
Like someone like you would be like an example of it. Like the web is for I think part of why Figma is so exciting is that a designer can do a whole bunch of stuff in Figma and then send a link and then boom, I'm in it. I can make comments. I can make little changes, even though I'm not a designer, but if I'd download a whole app to be able to collaborate with someone who uses Figma, it changes the whole story.
Jason Jacobs: And so Did you start out only enabling web
Steve Krouse: Yes, we started out only enabling web and to today we only enable web, but literally tomorrow we're going to have an alpha version that enables local desktop editing with your preferred editor, including cursor.
Jason Jacobs: and you say that the web is better for? Beginners, but it seems like a lot AI to quote unquote code with natural language are using the local tools
Steve Krouse: Yes, that's a good point. That's a very good point. Yeah. In some sense, the people who most want to use cursor are the most beginners to programming.
Jason Jacobs: Huh but your point of view is that is that is misguided thinking on their part?
Steve Krouse: No, not necessarily. I guess I have a lot of takes on that on learning to code with cursor. I feel like we could put a pin in that for a second. I think there's an audience of people who don't even want to download an app. And that's more who I'm talking about. Which I guess, maybe what I'm getting at is the distinction that we're elucidating now is the difference between casual use and beginner use.
So like a beginner could download Cursor and want to use Cursor without knowing the code. But a casual user who's just not sure if they want to code but might want to make a little change, fix a typo. I think for them, the web is important because by definition, casual user doesn't want to download like a gigabyte app and set it up before they can do anything like a casual user.
It needs to be in the web. No download. Yeah,
Jason Jacobs: sounds like one big difference between you and some of the others that you were describing is that you support a more narrow set of tools, but then you support them presumably With a better experience than would be possible if you supported a wide range of tools. What In what ways is it limiting to support a more narrow set?
Steve Krouse: Every day people ask us to add python support or there are python tools that we can support. And we just have to say no. I think that's not actually a problem. It like seems like a problem, but. The world is big and you can't serve everyone all at once. It's like nice to have natural limitations to like people you can and can't serve.
But yeah it's I wouldn't have it any other way. I think being able to just support one ecosystem well is key.
Jason Jacobs: So the ecosystem that you've chosen who is that meant for? Either the kind of person, or the kinds of things that these people are building. Or however, I guess you segment the customer universe that you are building for.
Steve Krouse: Yeah. Great. And I think I should probably also like me at some point, I guess could be now like, just talk about what Valton is. We've talked about like how I've like how it got started, but maybe I should give like a clear definition clear description. Yeah. Valton is a web based programming platform that lets you ship apps, TypeScript apps, and it has a lot of collaboration features built in.
Our target user is a professional programmer who is familiar with JavaScript or TypeScript and has side project energy. And I mean that at work or. In their personal lives I find that it's like this. It's the same person who's building the Spotify bumper sticker. Who's like also building the internal tool at their company that like helps automate some random process or gives extra visibility into something.
So that's we're building this like. New way to code and it's really hard to get people to bet their whole companies on us. I think that would just be a bad, that'd be a bad decision because we're trying to rethink things pretty fundamentally and we're still too early to bet your company on us. But so because of that, we're targeting apps that you don't care about that much.
We're targeting apps, we take, uptime and security extremely seriously. But It's still not a big deal if these apps go down or something like that. That's like the use case we're targeting. So that would be like a personal app, like an app for your family, an app for your community, an app for your school.
Teachers can make apps for their students, little quiz apps, or like internal to a company. You can have internal tools, like the sort of things you would make with Retool, like an internal tools dashboard. A scheduling app, a personal CRM, that's one of my favorite uses. I had a friend who started a company and she built herself a personal CRM that does exactly what she wants with all the keyboard shortcuts she needs.
And she built the whole thing on Val Town, the front end, the back end, and the database all hosted on Val Town. Yeah.
Jason Jacobs: Now, it sounds like I heard you say reimagining programming and not ready to bet the company, what is the desired future state that you're working towards when companies, when you are ready for primetime and bet the company, what does that look like? And then how do you get from where you're starting to there to the extent that you can At least think about high level phases, if you will, since obviously the future is unknown.
Steve Krouse: Yes. The medium term vision, medium long term vision.
Jason Jacobs: lost the sound.
Steve Krouse: Hello. Hello?
Jason Jacobs: That's weird.
Steve Krouse: You can't hear me now?
Jason Jacobs: Oh try it now.
Steve Krouse: How about now?
Jason Jacobs: Yeah. It might've been my headphones. Okay. So I asked you the question and you were about to answer,
Steve Krouse: Great. Alright, so my medium to long term vision is that people will build the back ends, particularly of their apps on Val Town. They'll build their API server on Val Town. They'll, so like in, in this dream world that we're building for, people would build their front ends on a platform like Vercel or Netlify, or like a more like front end optimized platform.
And then they'd build their API server backend on Val Town. And companies like. And then there are some companies that don't even have front ends, like their API first companies, like those companies would really fundamentally be Val Town driven companies. And so I guess to make it a little concrete, I don't know if this helps, like the dream for us in a year or two would be like a significant portion of the incoming YC class would be built, or Y Combinator class would be building.
On Val Town as its choice of back end technology, like in the same way that there was a period of time when YC founders would build on Firebase for their database, or they'd build on Superbase for their database, we want people to be choosing Val or Heroku used to be like the classic place that YC companies would build their back ends or Stripe is a classic place that YC companies built for payments.
We, we want back into the future to be built on Val Town.
Jason Jacobs: What is the. Assuming you were ready for primetime what is the built on Val Town pitch or let me ask this a different way what is the built on Val Town experience relative to the the current way of building out the backends?
Steve Krouse: Yeah. So today, when you want to build a backend and the way that we had built and build our backend, cause we unfortunately have to do it the old fashioned way. We can't do it on ourselves. The way you build backend is you use. Git and github and docker and you get your back and running on everybody's computer who works in your team.
And so when a new engineer starts at a company, like for the first day or for the first couple of hours, maybe first couple of days of employment, it's like getting the back end application running on their computer. And then learning how to deploy it from their computer to. wherever it is deployed, like managing that deployment is like a huge thing and keeping it online and tuning the scaling of it.
Should we have one instance of it alive? Should we have two? Should we auto scale it? These sorts of questions. And then when you're a developer and you're trying to make a change you make a change on your local computer and you test it out and then you push it to GitHub and then people have to review it. By like pulling the changes to their local computer and then reviewing them on their local computer. There's, there is this notion of preview deploys, which I'll get to in a second. But anyways, that's like the current way, the state of the art. What Valtan is talking about, the vision that we have is that and this exists for within a company or just without a company like this could be in the public.
You have a service that's running and on Val, you go to it on Val Town, and that is the source of the code and also the running application. And so anyone who wants to make a change, an employee, or just a random drive by person if they have access to the code, can click the remix button. And instantly they get a running copy of that application in their own Val Town account.
And it runs as soon as they press the button. Some apps might need additional like configuration or authorization or whatever to run. But we'll like, we will walk you through that. That's like a part of our onboarding. So then once you have this running copy, you make a change and you hit save. And when you hit save, We don't just save the code, we deploy the saved version of that code to our cloud for your version.
So then you keep developing in a cloud deployment. There's no deploying on your local computer and then getting it somewhere else. It's already deployed. And then when you're done and you're ready to contribute your changes, like, all right I want to suggest these changes upstream, send a pull request.
You hit a button, you open a pull request. And the person gets notified and then they can explore your app. your live app, you don't have to pull the changes and get your changes working on their local machine. It's already working in this like preview deployed environment.
Jason Jacobs: I'm going to try an analogy here and keep in mind, I don't know what I'm talking about so that's like my, again, my caveat for, The whole discussion. But just based on what I'm hearing, it sounds almost like it's Google Docs for production code.
Steve Krouse: Yes that's great, that's great. That's a very simple way to do of describing it. Yes. That it's, and I like, I can flesh it out a tiny bit for you. Like the way that I today communicate with my lawyers is I tell them what I need. They send me a word document. I send that back. I send that word document to who I'm negotiating with.
They send changes back to me. I forward those changes onto my lawyers. The lawyer sends me back another doc. It's just, it's insane. And it's like, why can't we all just get in a Google doc and just collaborate in line. And that's what Valtan is for programming like programming in today's day and age is still a little bit point to point.
And we want to get centralized on one platform. So the reason the place where that analogy doesn't fit is that programmers already have a Google Docs for programming, and that's what GitHub is. And a big part of what we're doing is improving on the collaboration that GitHub provides. Because we're bringing runability to it. Yeah.
Jason Jacobs: Can I double click on that? What collaboration does GitHub provide? And then what specifically are you guys providing that is new and different?
Steve Krouse: Yeah. GitHub. is amazing, we use it. GitHub lets you have all sorts of branches of code. So everyone can have different copies, people can GitHub is a lot like Google Docs for code. But it's like much more structured. And the reason it needs to be more structured is because in a Google Doc if I make it, if you and I are editing simultaneously The worst thing that can happen is that one of us has a typo or something like that, but in programming, if two people are doing simultaneously and someone like, and we like stomp on each other's feet, the whole application could break like programming is a lot less forgiving a Google Doc is forgiving because the consumer of a Google Doc is a human who can just see what's happening and interpret the results, but imagine if, when you were writing a Google doc, if there was any typo at any point in time, like the whole thing was unreadable, that's more what programming is about.
Anyways, so GitHub is like Google Docs for programming, but it's a lot more structured. And really people can, people like make branches and make their changes and they can make, they can send them back upstream. So that's what GitHub provides.
Jason Jacobs: Now, one interesting observation that I'm having is that we're 42 minutes into talking about Val Town,
Steve Krouse: Yeah.
Jason Jacobs: we haven't once talked about AI natural language for code We're talking about version control and and and runability Where does AI fit into all of this, if at all? And I guess I know it does, but but yeah how and why?
And does it need to?
Steve Krouse: Yes. Great question.
AI was like never part of the vision of Val Town, but it's such a wonderful piece of technology that You know, I feel like everyone should be asking themselves all the time how, like what former constraints are no longer constraints. How can we use this magical thing? And with coding it's very obvious because it's being used in so many ways already.
And like my users are asking me for AI coding features and they've been asking for AI coding features since day one. And I guess The structure of my answer to your question is to give you in my mind to give you a tour of the blog posts that we as a company have written over the course of the company about AI.
Because like we, we've started adding AI features since two years ago, and we just, I've kept going. And my most recent blog post about AI was about how the history of Valton and AI is just fast following or copying what other people are doing. And it's, it comes from a place of we're building a platform for programming.
Our users are also programming other places and they want features like AI features from those places in our tool. And so we just. We build them and then we get feedback on them. Some of them work and we keep them. Some of them don't work and we don't keep them. And that's been working pretty well for us.
But just now I, we are like just in the last month or two, we've shifted our strategy quite drastically. And I'm writing, I'm in the middle of writing that blog post right now. So I can tell you about it, but I was trying to pause first to make sure that you don't want me to, yeah, I can go in a couple of different directions.
Jason Jacobs: Now I feel like we have to know what the strategy shift is.
Steve Krouse: Yeah. Okay. So yeah, the old strategy was to copy AI features into our product. And I'll just give a couple examples of that. And then I'll talk about the strategy shift. So the first thing we copied into our product was GitHub Copilot Completions. As you're typing, it'll suggest things to type after your cursor and you can just hit tab to accept them.
So we built that into our product. That's been very successful as it remains today. The other main successful thing we've built is What you used when I got you to try Val Town. It's called Townie. It's our AI agent And it's analogous to replits agent if you if your listeners know about cursor or bolt or sorry not cursor if your users know about bolt or lovable Townie is a like Those or if your users know about Claude artifacts that's what townie was really based off of Claude artifacts.
So on the left, you have a chat with an LLM on the right. You have the outputted. Code and preview of the code. And so we built this interface into Val Town that you tell it what kind of website you want, what kind of API you want, what kind of database you want, and it will write the code for you. And importantly, we've taught it a lot about our system.
And so it like knows how to write code for our system and knows how to detect errors in our system and automatically solve those errors. It's a very cool tool. But we've decided that this, that like the strategy of fast following is expensive and we're always going to be like a click behind.
And the industry is like moving too fast. And when you think about like. How fast things are moving I can just give a couple reference points that a friend gave me He said that it seems like the cost of inference is dropping a hundred X every year for the same level of intelligence And if you just look at one level of intelligence, if you look at GPT 4 level intelligence, which launched like a year and a half, two years ago, in 18 months, that level of intelligence went from being frontier and very expensive to, to now it dropped a thousand X in 18 months, it dropped a thousand X, the price for that level of intelligence.
And for contrast, Moore's Law is a 2x increase in chips on a transistor in 18 months. And Moore's Law has been this like tidal wave of benefits that our whole industry is based off of. Like all of Silicon Valley and all the growth is from Moore's Law. And like the current growth of LLMs, not only their improvements in reasoning, but like the cost reduction.
For my team of six people and a startup, we can't build the core of our time platform and then also keep up with AI, particularly in AI code generation, because I don't know if you've noticed, but AI code generation seems to be like the single hottest. Like market for startups and venture capitalists, I don't know if you see cursor, keep raising money at crazy valuations, but, their competitors are also doing the same.
We decided to bow out of that race and instead folk, like focused on staying in our lane and focus on interoperability and openness. There's a blog post that was very influential to me by Matias, the founder of Netlify, his blog post is called. I think it's called AX, agentic experience.
And the thesis of that blog post is that people who made developer tools used to focus on DX, or developer experience, which was a radical idea at the time. But now that we have agents, and agents are customers of developer tools, we need to focus on the experience that we're designing for agents themselves and building a really good agentic experience.
And that's more what the direction we're going in. And I, here, I'll pause there, but I can keep going if you want.
Jason Jacobs: I guess my question is, so does that mean that instead of picking off features to fast follow, you will just try to integrate with the leaders?
Steve Krouse: directionally. Yes. Right now we're not focused on integrating with them. We're focused on building the interfaces, the APIs for them to integrate with us. Or just we're focused on building interfaces for our system to just be integratable with anybody. We're just like opening ourselves up to integration. Yeah, does that, so I can give an example that's been very successful for Netlify, for example. So there's a company called Bolt, which is basically a clone of Townie. So like we built Townie in July, August, and then Bolt launched a couple months later, and it does a lot of the same things. But they don't do deployment. They don't that's our main thing is deployment. Their main thing is helping you build apps with AI. And so when you're ready to deploy, you hit a deploy button, and then they say, Great, we're going to go deploy your code that you made with us to Netlify. So Netlify didn't build that partnership.
Netlify just has this API that allows people to send code to and have it be deployed. And what's important about this API is that it's an unauthenticated API. So anyone can go to Netlify and say hey, go deploy this code for me. But I'm not going to tell you who owns this code. Just deploy it secretly.
Give me a URL to that deployment. And then I'm going to give that URL to my user. And my user can then go and see the deployed code. And then optionally claim it. And when they hit the claim button, it'll walk them through setting up a Netlify account. And then adding that project to their Netlify account.
And so that infrastructure of Doing unauthenticated deploys that users can then later claim. That's really cool. Like it allows Netlify to focus on being a great deployment platform. And it lets Bolt focus on being a great coding building platform. And then they can integrate there. So that's more the approach that we're taking.
Jason Jacobs: Got it. So the actual back end and API development, will that take place within the walls of Val Town, or will that take place in these other tools?
Steve Krouse: Yeah, the short answer is both. We still really believe in our web editor and we think there's a lot of users who want that in a lot of contexts. And then we also now support you to use to like push to Valentine from cursor. And we as a team are actually excited to play with this tomorrow.
We're having a user space Friday where we like tomorrow, none of us are allowed to like work on the product. We have to and we're all, and the plan is for us to use our new open tools to develop with Cursor and Windsurf locally and then push to Valtan.
Jason Jacobs: Nice. Inna, how big is your team?
Steve Krouse: There's six of us here in New York.
Jason Jacobs: Okay. And in, in these early phases, since it sounds like what you're trying to do is so different and that like you said it's different enough that, no one's gonna walk you in and give you the keys to the kingdom. You're picking off stuff on the periphery to prove yourselves and then it's land and expand.
What then becomes important in this phase in terms of the milestones that you and that the team are driving towards?
Steve Krouse: For better or for worse, we hold ourselves accountable to like weekly growth metrics, which
Jason Jacobs: Growth of what?
Steve Krouse: growth of active users we count an active user as a user who had code that ran in a given week. Even if you didn't log into Val Town, but your code is running and we were presumed that it's doing like some benefit for you, your website's running, your agents are running in the background.
So yeah, so that, that's the main, and then we're all, we also keep our eye on. Revenue we have a free tier and we have a paid tier and the paid tier gives you custom domains and other, bells and whistles that we can't give everyone in the free tier. So we do hold ourselves accountable to like weekly growth rates and we're targeting like the classic.
YC growth rates of five to 7%, which many weeks we hit, many weeks we don't hit . So even though we're like still figuring things out and iterating so much we think a lot about growth every day. And like how is what we're gonna do now gonna lead to growth in the short term?
Jason Jacobs: And is this, are you more focused in the short term on individuals or on companies? I heard you talk about the examples of companies picking off their non critical applications. But then it also sounded like it's a lot of newcomers who might find the most value who might even be doing this as side projects like the personal CRM.
So what does it matter who, when you think about growth?
Steve Krouse: yeah, good question. The personal CRM was actually in a company context for, but for that one in particular. But if I could pick in the abstract, I would pick, the biggest companies possible, using the biggest internal tools possible, if all else was equal. So yeah, if I have two users asking for help and one is working on a little side project and one is working on a critical company thing, I'm going to help the person with the company thing first.
That's because, they can pay us, they have no problem paying us and they can like, they have no problem paying us more if their usage scales up over time. And the interest of sustainability, I feel obligated to serve the business user first. But and that's in the short term and in the longer term and just in reality, it's so much more muddy than that.
A lot of our best business users come from having been a side project users. Like I think a lot of the best programmers do both. They like do side projects on the side and then they do side projects at work. And so there's not as sharp a distinction. Between business use cases and work use cases, I'm trying to think if I can come up with a good example of this, but oh, yeah there's a guy.
I don't know if I should give his name, but he was using us for all sorts of. Passion tools. And then he got gets hired by a company who don't know anything about servers. And he's great, I'm going to, you guys don't know about servers, but I do, I'm going to make it on Valtan. And he got to choose that technology decision.
And he had like already vetted us. Cause he'd made like dozens of personal sites on us. So that's the sub growth we're thinking about.
Jason Jacobs: How are you growing? Do you have a sales force or what is the strategy in terms of how people learn about Val Town
Steve Krouse: Yeah, we definitely don't have a sales force or if we do, it's me and I'm not very good at it. We, yeah, Valentine is very much like a bottoms up. motion people find out about us on Twitter or other social networks from me or from like people sharing stuff that they've made. That's like the primary way.
And a lot of referrals, like a lot of people when they sign up said that they just heard about us from their friend, their cousin, their work colleague. We're soon at, we don't even have, we're all about collaboration. We don't even have the ability to add a collaborator to a project. Like right now, if you want to collaborate with me, you can remix my project and then send your changes upstream, which is just, a couple of button clicks, but like three button clicks, but Oh, very, like people really want collaborator, like proper collaborators.
This is a trusted person and they can make a change. Directly like they don't need my approval and that's what a team is about. And once we have that, so not only is it going to let teams use us, but I think it will really drive people to invite their work colleagues to a project, invite their friends to a side project.
And I'm excited about that driving growth too.
Jason Jacobs: Uhhuh? And don't answer anything that you don't want to answer, but I think I read that you raised a couple rounds of funding and so you raised a smaller round and then more recently, call it in the last 12 months or so, you raised a meaningfully. larger round. First, did I get that right?
And second what was the story in that larger round that gave you and investors confidence that it was time to resource up and and presumably start to deploy that bigger war chest of capital as well?
Steve Krouse: I would categorize it actually quite differently than that. Raised our funding in two rounds pre-seed and a seed, but they were both led by the investor I mentioned at the beginning of this conversation, Dan Levine at Accel.
He invested all that capital, six and a half million dollars, and then we raised 500 K from angels. And the plan has been from the beginning to Get like the minimum viable team of five to ten people and not grow the team just but just grind out to product market fit and we think of like notion or maybe Instagram as like role models in that sense of small team under 10 people with an outsized impact with an outsized user base.
And the key is to just extend runway and keep complexity small by having a small team so that we just give ourselves the time and space to figure out what it is we're building and who we're building it for. So we're not trying to scale up or doing it or deploy capital in a big way.
Jason Jacobs: Huh. So it wasn't a product market fit story. It was a it was a, we're still excited about the long term vision here, and we also think that this initial experimentation is fruitful, and while we don't have all the answers yet, all we want to do is keep grinding, and we want to have a long time to grind without worrying about Running out of cash, so it's not to go and grow, it's to give ourselves the time that takes our head out of a vice so that we can experiment, learn, and tune until we get it right.
Steve Krouse: Yeah, exactly.
Jason Jacobs: I think that's smart. Yeah, and it's nice that you have an investor partner who who's aligned with that. And alignment is so key because otherwise you get the money and it's I don't get it, why did you even raise from us? Because now that you have it, you're not using it. If you weren't ready to use it, why'd you raise it?
And it's that's the last thing that you guys need if you're in the mode that you're, sounds like you're in.
Steve Krouse: totally. Yeah, exactly.
Jason Jacobs: Nice, and what does the future look like? Tune until you've tuned enough and you don't know when you'll know when you know but you don't know.
When it's coming, but I guess what's the strategy between now and then once you do feel like you've got a recipe, then what happens?
Steve Krouse: Yeah we're growing pretty well now. Like our weekly growth rate is still one, two, five, last month we had a couple of weeks where it was like 15%, 18 percent growth in a week. So like our growth rate is, it's still good, even though we haven't figured it. Even though we're changing and iterating so much, like we're like, I was giving, I was onboarding.
a friend to Val Town by hand, which I do to get feedback. And he was like, this is crazy. Like your onboarding is terrible. Like how do you, how is this company growing at all? And the reason onboarding is terrible is because the product's changing so much that we can't build onboarding because like the product changes so much from week to week.
But anyways, hopefully at some point we'll get it all dialed in and we'll be able to grow in a more predictable way because we'll have a more predictable sense of what the thing is. The thing that I'm most excited about in the short term is, and I'm sure you'll see this on Twitter in the next week or two, is is me being on Val Town.
And their local favorite AI tool. If you're programming cursor, here's how to use cursor in Val Town. I think that's going to be a really fun demo. Like I'll be able to build some really complicated things in five minutes.
Jason Jacobs: So I'd love to switch gears. There's a couple of other topics I want to make sure that we hit on if it's okay.
Steve Krouse: Yeah. Yeah.
Jason Jacobs: Val Town is for programmers. You self identify as a programming guy. I gave you a few different choices and programming is, that was like your North star of your zone of excellence and delight.
There's a lot of tools coming on the market that. Have the stated promise that will be writing code on the behalf of programmers and non programmers. And that increasingly the barrier is lowering for who can become a programmer. Where do you think that, that future lies? And I'll ask the same question in the short term, medium, and the long term.
Should, should anyone that wants to build technical products still Learn to code or do you think that these tools will democratize it enough that becomes less important over time?
Steve Krouse: It's a great question. I was thinking a lot about this question right before our interview, because I knew you'd ask it. Just before this interview, my dad called, and he was like, someone just told me that in six months AI will write 90 percent of the code.
Jason Jacobs: Yeah No That's what the I think the Anthropic CEO said that this week and it was making all the headlines and someone actually took that Tweet and took a screenshot of Anthropic's job openings and it had 50 engineering roles. And it was like, Oh, so these are like, three to six month roles.
Yeah,
Steve Krouse: That is a really good point. That's a really good point. Yeah, I think that where I'll start is that I think the future of programming, of fully an autonomous Programming done by AI is like the future of driving cars. And for as long as I've been alive, like we knew that like cars would one day drive themselves.
We just didn't know when. And oh, I if I can just describe this. My co founder Tom has this wonderful visualization he made that he calls like the self driving rainbow. And it shows when people boldly predicted. Self driving cars would be accomplished by and when the prediction was made. And so it's like in 2015, Elon Musk said that by 2020, all like all Teslas would drive themselves.
And so like it has this like rainbow effect of like people making predictions and the predictions failing to come true. And people just keep making these predictions and they keep failing to come true.
Jason Jacobs: That that are listening to this. I'm sure there's some, and they're all going to say, that sounds like fusion.
Steve Krouse: Yeah, exactly. And in a lot of ways, like these things maybe all boil down to AGI and like when will machines like finally cross this hard to define threshold that like they're as smart as humans. Because what seems like has happened with self driving cars is that you can get really freaking close, but then there's this like tiny little bit of like human judgment left.
Like the AI just can't figure out the context of I don't know if you've seen recently when the AI, when it's two Waymos like stuck in a traffic jam and like they can't get around each other. And it's oh clearly this is not a human a human would be like, oh, okay that's another Waymo like me we need to communicate somehow let me just inch to this, a human would be able to solve
Jason Jacobs: know how Boston drivers would do it. It probably wouldn't be in a very nice way. But they do have a way of communicating.
Steve Krouse: Yes like The long tail getting a self driving car to work is getting it to work in all these contexts where ultimately you have to be a human with human judgment to understand a bunch of stuff. It's not just staying between these lines. That's easy. Like, where the hard part is, like, all the human complexity.
And I think the same necessarily has to be true for programming. The AI can get only so good until they have to make a decision or understand A long GitHub issues thread and Oh, like when that programmer said this, like he's actually like being sarcastic, there's just like complicated human factors and it will only fully automate AI once like AI, like truly is as smart as a person and like whether that's this year or 30 years from now, literally nobody knows.
So anyway that's my. Non answer to your question. Like we just don't know when humans, like when AI will reach that threshold.
Jason Jacobs: So if I want real tools to be built internally that can automate mundane Parts of my job, as well as gain insights from this aggregate body of content and and have that be living and breathing content,
Steve Krouse: Yeah.
Jason Jacobs: on and so forth. Do I either need to learn to code or find a technical
Steve Krouse: Yes. Yes. Yes. Yes. Okay. So I think in the short term, it's such an interesting question of like, how do you become dangerous with these tools? How do you become useful with these tools? And what do you learn? What is it that you should learn and why? And what's the half life of your learning?
Because there are certain things that I feel like aren't useful to learn, like how to program HTML like most of that AI is like pretty great at it. Like you shouldn't learn it anymore. Like you just described to the AI how you want things to be changed mostly, but it can like still get stuck sometimes.
So I'm teaching my brother to code, and he uses AI, and he gets a lot of stuff done. But then the AI gets stuck, and he can't get the AI unstuck. And he and I are really grappling with are the ways that AI gets stuck today? Fundamental things that he should learn, or if we just wait two months for the next AI release, will AI just not get stuck on those things anymore?
And then like, why did he spend two months learning them?
Jason Jacobs: How do I sign up for this course?
Steve Krouse: Yeah, it's a it's not a course. It's just he and I meet once a week and I give him feedback on what he's building. And we talk about how he got stuck and how he's, how I get him unstuck for next week and he goes off and does it
Jason Jacobs: That's what I want! Someone should build like a, it's like pair programming for for non technical people. Trying to learn like a lot of these courses like it's like people tell me like oh just sit down with chat GPT and that will be your pair programmer, and it's like I'm more high maintenance than that like I need a human to pat me on the back and tell me it'll be okay I think that's the primary role of the human I'm not sure that I need them for more than that, but I seem to need that person.
Steve Krouse: If you recall I offered it, I offered exactly this to you.
Jason Jacobs: I might be back, I might be back, I'm still thinking about it, it's just, am I spending any time on it? No, why? Because I'm in my zone of excellence and delight, which is having discussions like this all day long, and I'm learning a ton, and having a blast. But yeah it's on my to do list as well I don't I don't, I'm a one man show, and it's like chicken and egg I, I'm too busy doing mundane tasks to make the time to learn, but until I make the time to learn, then I can't automate any of the mundane tasks, right?
Man. And I know a lot of people feel that, a lot of companies feel that, a lot of founders feel that. It's I have my core business to run, I'm sure it could run more efficiently, I'm terrified of getting left behind by a newcomer that doesn't have the baggage of a core business that exists, like I do, but at the same time, my team's already overwhelmed, I can't pull them off just to go play with AI tools. Yeah.
Steve Krouse: Get it. I get it for sure. I feel the same way. It's even, I feel like I can't keep up with all the changes. Like I was saying, a hundred X improvement in cost alone every year. It feels like my fiance likes to joke that literally every day I say, it's just me at my phone being like, Oh, a new model just dropped.
Like she, like I do that. And she just laughed. She's it's every day.
Jason Jacobs: I have one more for you, and you said something earlier in this conversation that that got me interested, which was that by putting it on the web, it could be a more social and collaborative pursuit and removing the barriers to that being if you recall, with MCJ in the early days, we had people that were binging on the pod, and They were sitting in interesting spots and really diverse backgrounds and longing for a peer group to unsort the new, the Untangle the nuanced topics that we were covering on the show.
And so our tool of choice to foster that collaboration was the slack room Now I'm meeting with a bunch of interesting founders day in and day out. Many of those discussions are getting recorded on the show And then many of those guests then Go on to be listeners, or in your case, I know you've listened to a few episodes before you became a guest, right?
And, so there's a lot of overlap and, pretty much everybody that I've met with so far, maybe you'll be the first to be like, Not me, but The vast majority of the people I've been meeting with so far, they say it's moving so fast, I'm having a hard time keeping up. I also have a day job and all these things that need to get done, so I have a day job doing the work, and I have a night job staying on top of all the changes.
And anyone on my team who is going to be an impactful player needs to have that split personality where they're spending part of their time doing and part of their time keeping up with how quickly The landscape is changing. They all say they would benefit from a peer group and collaboration as well as maybe even level blocks, clumps of code, or, right?
And and of course everyone's worried about competition because I also have people say gosh, I can't really talk about this one thing on the show because I don't know how much of a mode it'll be in the long term, but it's a mode for now, and I don't want my competitors to know about it, and there's a lot of them, right?
So there's some kind of guard up about sharing, but at the same time, that same person would be really eager to benefit from the learnings from anyone else's companies, the same way that their competitors would be eager to learn from them. And so I guess my question is, I feel like I've got a lane where, as my relationships grow, I could potentially provide some layer of collaboration, and that could be part human collaboration and part more open source style like sharing of the clumps of code and slack and discord.
I don't know your thought, but just setting up a slack or discord feels one. It just feels a little tired. It's I don't know. The last thing I want now is like another slack channel, but then two for this type of problem where it's so hands on. It just feels like maybe that convening could look different, and I don't even know if it is community.
It's just somehow fostering knowledge sharing and resource sharing, potentially, across this growing tribe of people. I wanted to put all that out there for you, and just see how you react to it, and what ideas you might have. One, is it even would it be interesting? And two What would you do?
Where would you start? What should I build?
Steve Krouse: Yeah. Great questions. I feel similar to you. And like we've discussed, we're similar in that we interview people publicly when we're confused. So like the first thing that comes to mind for me is that I have a couple of friends who are like real AI experts on the cutting edge. And whenever I do live streams with them or watch them use their AI tools, I learned so much.
And and my instinct to solve this problem is to do exactly what you're doing, but do it on my live stream or my podcast. And I've been doing that, so I think you're doing the right thing.
Jason Jacobs: No, I am for me, but what about all these people that are booked and that don't have all day every day to sort through it like I am, but who still are longing for more of that connect that they're on very heads down lonely pursuits, right? And they want it to be more collaborative, but a lot of the, the historical definitions of community sound good in theory, but then in practice it's like they try it for a few weeks and then either it's a ghost town or it's too noisy and they need to go because they can't get anything done in focus.
Steve Krouse: Yeah, it's a hard problem. I don't know, I don't know how to solve that one.
Jason Jacobs: Okay, I'll come back to you if I come up with anything to get feedback. Let's see. Over the next 12 18 months, what's what are the key goals with Val Town and what does success look like?
Steve Krouse: Yeah the key goals Is to grow 5 percent per week. So if I, if you do that for a year, that's about 10X growth. I, if you talk to me in a year or so, and I have 100 times users, that then I'll be a pretty happy guy. Because, to me, what that means is that we're like really democratizing programming.
We're really enabling the collaboration in a new way. So that'd be quite exciting. In terms of outcome and in terms of things we're building, man, we're building so many cool things. , yeah, the current thing is this openness piece of letting people push to us from other places.
And so like a true success there would be other tools are integrating with us. So like other tools that I didn't build or letting people build AI experiences and then deploy those to Val Town, that would be pretty, pretty wild. And then we have a whole bunch of improvements to our infrastructure, but those are exciting to me, but I think they're probably boring to you and your listeners.
Jason Jacobs: For any listeners that want to get in touch, what's the best way to reach you, and what kinds of people might you want to hear from? If any.
Steve Krouse: Yeah. I love hearing from people. I'm Steve at Val. Town for email Steve, S T E V E at Val, V A L. Town, T O W N, and Val. Town is the website that I am making. So if any of these ideas intrigued you and you want to get started, feel Writing and deploying code in a collaborative environment, I'd recommend heading over to VowelTown.
I mentioned a bunch of blog posts, those are on blog. vowel. town. My personal website is stevekraus. com. Who do I want to hear from? I mostly want to hear from people making cool stuff, even if it's not on VowelTown. I really love side projecty people. People who are building all sorts of fun hacks in their companies and in their personal lives.
like building software. There's this new phrase personal software. It's actually a very old phrase, personal software, personal computing, but it's become new again. And whether you're using AI to do it or Valentine to do it, I love people building those sorts of things. And yeah I love reaching, I love nice emails, so please reach out.
Jason Jacobs: Anything I didn't ask that you wish I did, or any parting words for listeners?
Steve Krouse: Let's see. I have a note here. Let me take a look. See anything. No. You asked all the things I wanted to talk about. Thank you.
Jason Jacobs: Great this was a blast, Steve. Thanks a lot for coming on. I feel like I learned a lot. I just got private tutored on DevTools for an hour. A little over an hour, but yeah, wishing you guys best of luck, and as I gear up to get my hands dirty again, which I will you will again. And yeah, looking forward to keep an ongoing dialogue and to watching you achieve your vision
Steve Krouse: Yes. You too. I will be your tutor when you're ready. Your AI coding tutor.
Jason Jacobs: on camera. We have proof. Thanks, Steve.
Steve Krouse: Thanks.
Jason Jacobs: Thank you for tuning into The Next Next, if you enjoyed it, you can subscribe from your favorite podcast player. In addition to the podcast, which typically publishes weekly, there's also a weekly newsletter on sub stack at the next next dot sub stack. com. That's essentially for weekly accountability of the ground.
I'm covering areas I'm tackling next and where I could use some help as well. And it's a great area to foster discussion and dialogue around the topics that we cover on the show. Thanks for tuning in. See you next week!