Building a developer social network with Steve Krouse from Val Town
Steve Krouse wants you to create a Val Town account at 14 and start paying for it at 27 — a 13-year payback period he's completely at peace with, because that's exactly how long it took him to start paying GitHub. Every Thursday, his team is banned from touching the product and has to try to make something go viral instead.
Steve Krouse is the founder of Val Town, a social website for writing and running JavaScript and TypeScript, described on its homepage as 'GitHub Gists if they ran, and AWS Lambda if it were fun.'
We get into why Val Town is deliberately hard to explain in one sentence, why GitHub repos became a 'web primitive' that Val Town is trying to replicate for small scripts, the weekly day the whole team spends only trying to make something go viral, and Steve's side project cataloguing public 'date me' docs.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
Beyond the poem on your homepage, what is Val Town?
I love metaphors and analogies, so there are a few: it's like GitHub Gists if they ran, it's AWS Lambda but much more fun, it's Twitter meets npm in that it's social but about sharing code. One tagline I like is that Val Town makes importing someone's code, or your own, as easy as tagging someone on Twitter — you write @steve.foo and the value of foo is now just available in your code. I also think of it as a spreadsheet for JavaScript, or a Jupyter notebook for JavaScript, or CodePen for the backend. In plain English: it's a social website where you write and run JavaScript or TypeScript, we run it on our servers, and your code is instantly deployed and hit via an API endpoint. You can schedule it to run on intervals with one click, there's logging and tracing, and one of our favorite features, console.email, lets you email yourself as easily as you'd log to the console.
What kind of friction is Val Town actually trying to remove?
We want to knock down as many friction points as possible between having an idea and actually running it. One analogy I forgot to mention earlier is Zapier for developers — which is a tagline a few other people building similar things have also reached for. There's clearly something real there: programmers want to write code, but they also want some of the niceties and guardrails that something like Zapier provides, and there are a number of us competing for that space.
Val Town is a genuinely horizontal platform — it can be used for almost anything. How do you actually explain what it's for?
That's one of the biggest challenges of a horizontal platform like this — it's like trying to explain a spreadsheet to someone for the first time; you end up saying 'anytime you need numbers in a grid,' which doesn't really land, even though that flexibility is exactly where the power is if you can pull it off. We made a page cataloguing our favorite use cases to try to make that concrete. But ultimately, I don't want someone hearing about Val Town for the first time and landing on our website confused about what it is — ideally they hear about Val Town through someone else's val, the same way you'd discover a cool GitHub repo.
You've said GitHub repos became a 'web primitive.' What do you mean by that, and how does it relate to Val Town's strategy?
Before starting this company, I didn't appreciate what a coup GitHub pulled off making a repo into something every programmer immediately understands — you land on one and you know it's forkable, you know to scroll to the README, you know what the stars mean. It's a web primitive in the same way a tweet or an RSS feed is. I want a val link to become that same kind of primitive — something you'd see shared on the front page of Hacker News or Reddit the same way a GitHub repo would be. We're investing real effort into making vals rich enough to be worth sharing as bare links — we recently added READMEs to vals, the same way GitHub repos have them. It hasn't fully taken off yet, but that's the direction.
What does 'default' mean to you in terms of how people should think about reaching for Val Town?
Val Town needs to be the default place you go to code, the same way Twitter is the default place you go when you have a thought your audience might like — you just pull it open, even on the train, and start coding on your phone. It should also be the default place you go to find examples of things that already exist — search for an API you want to try, find a dozen examples, copy the closest one, and you're off. Part of the magic that makes that possible is that every val shares the same runtime — there's no installing a language version or getting package versions right. If it worked for someone else, it works for you, because you're only ever thinking about the code itself.
Doesn't sharing one runtime across every user create real technical risk?
Our solution is deliberately restrictive — there's only one version of TypeScript, so there are no conflicts between users. If we upgrade TypeScript and it breaks something, it breaks for everyone at once, which is a real trade-off. Maybe one day we'll support pinned runtime versions, but we want to avoid that complexity as long as possible, even though it might become inevitable eventually.
You've described Val Town as a social network built around composability. What does that actually mean in practice?
Vals are small snippets, the same way tweets are small snippets — I think the reason tweets are length-limited is so each individual piece is independently likable, reply-able, and retweetable in every direction, rather than one giant undifferentiated block. Val Town style favors small functions composed into larger ones, so you can reuse your own small pieces, and so can everyone else if you make them public. In theory, less code needs to be rewritten because you can just import someone else's val without them having to go through the extra step of publishing to npm — they wrote it, they're using it, they hit a button, and now it's public. That composability really only works well because everyone shares the same runtime; if everyone's code were pinned to different versions, spinning up a different runtime every time you wanted to compose someone else's val would make everything slower and more painful.
There are very few developer tools that have reached true mass adoption — GitHub, Replit, maybe CodeSandbox. How are you thinking about getting there?
It's a balance of doing things that don't scale while always keeping an eye on scalability — my investor is constantly watching me go way above and beyond on customer service, even for non-paying users in Discord or on Twitter, and pushing me to think about how to move that kind of care from me personally into the product itself, and eventually from the product into users helping other users. Ultimately, what needs to happen is vals need to go viral the way GitHub repos go viral, and infect other people with genuine enthusiasm for Val Town — true ambient word of mouth, where people sign up, make cool vals, those land on the front page of Hacker News, and that infects the next round of people. We're not there yet — we have a small, genuinely excited group of users, but not the mythical product-market fit moment you hear about. We're working on it.
What are you actually doing to try to make vals go viral?
There are a few different angles. One is getting people who already love Val Town to evangelize — write blog posts, make cool vals with a real shot at going viral, share them widely. Some of that isn't a growth activity on paper — people wanted Vim key bindings, so we added them, and while that's not inherently a growth feature, people started tweeting excitedly about it, which became a growth effect. Another angle is making sure a shared val is actually shareable — does the preview image look good, is it clear what you're looking at when you land on one, is the SEO solid, does an embedded val load fast. We've started a new ritual: every Thursday, the whole team is banned from working on the actual product, and instead has to try to make something go viral. It's genuinely one of the hardest and most fun days of the week — it's a different, harder skill to deliberately try to make something intrinsically interesting to other programmers in a single day than it is to just polish an existing feature.
Has that Thursday ritual actually produced anything that worked?
We haven't had a val go viral in a while, if I'm honest. The last one that really took off was a 'Hacker News Follow' tool, which let you synthetically follow someone on Hacker News via polling, since real following isn't a feature there. Interestingly, we didn't brand it as a 'val' — we branded it as an installable script, and all we actually changed was relabeling the fork button as an install button; the underlying behavior was identical. That one small framing change made a real difference, which tells me we probably need to experiment more with an 'app' framing rather than assuming vals themselves are the unit people get excited about sharing.
Your original onboarding had people set their handle by literally typing a JavaScript command. Why change it?
Originally, every setting you wanted to change, like your handle, was literally a command you'd type into the code editor — set the handle, pass a string, it would either work or throw an error. It was memorable, genuinely cool, but it created too many degrees of freedom, and people were getting errors during signup, which is exactly the wrong place for friction. A signup flow is a very specific kind of thing, and teaching someone JavaScript while they're trying to just create an account isn't the right moment for it — you want them signed up with an account and an email address first, then teach them the product while they continue setting things up.
What does the onboarding look like now instead?
We teach the product mostly through vals themselves. One tutorial step has you build a small API — not very meta. Another teaches console.email by having you send yourself Val Town's own welcome email, which is itself just another val you can open and inspect. A later step teaches scheduling by having you set up your own drip campaign of inspirational Val Town tips, fully customizable down to how often it fires, which is also a small meta joke about what we'd love to actually do to users if we could. We're going further in this direction — a notification system where, instead of building one rigid feature that tries to cover every case, like being notified when your val errors, gets liked, or is called via API for the first time, we expose the underlying data as an API and let a marketplace of 'notification vals' handle the actual logic, including things like exponential backoff on error notifications rather than getting spammed every second.
You care a lot about education. How do you think about Val Town's role in helping people learn to code?
My medium-term ambition is that someone builds an interactive learn-to-code course on top of Val Town — maybe with embedded, editable vals students can interact with directly. Long term, I'd love hundreds or thousands of such courses to exist. But I think it's better for us to just provide the building blocks — we're the evaluation engine — and let other people write the actual content, rather than building one official course ourselves. Someone recently reached out wanting to build a paid course using Val Town as the evaluation engine and offered to split the profits with us; I told them to keep everything, because they're effectively advertising our platform and turning their students into future Val Town users. I like to think about how long it took GitHub to make money off me — I became a GitHub user at 18, as a freshman, and didn't actually pay GitHub anything myself until GitHub Sponsors, years later, and now I pay for GitHub Actions through my own company. That's a genuinely long payback period, and I'd be completely happy if Val Town works the same way — someone creates an account at 14, and the first dollar we ever see from them comes when they start their own company at 27. That's a 13-year payback period, and I'm at peace with that being the kind of company Val Town is.