val-town-blog

If Claude Code is Amazon, Val Town is same-day shipping. Growbots, a lead generation agency for SMBs, creates tools and apps with Claude Code and instantly deploys to Val Town using the Val Town MCP server.

Who/what: Growbots helps SMBs with outbound sales

Growbots is a lead generation agency for small- and medium-sized businesses. They've served over 3,000 customers since their founding just over a decade ago, helping customers generate over $500 million in total revenue. They save businesses time on customer prospecting and outreach, and Val Town saves them time building and deploying tools to run their business.

We talked to Greg Pietruszynski, Growbots' co-founder and CRO, and Jakub Kalbarczyk, GTM Engineer, about how they're using Val Town with Claude Code.

Problem: codegen is frictionless, deployment is not

There's a lot of talk lately about how code is cheap, but working software isn't. Part of that is the bridge between codegen and deployment. Greg put it eloquently:

99% of non-technical users have no f***ing idea how to deploy apps, and it's even f***ing hard to register on GitHub now because you need to do this captcha verification spending 10 minutes listening to strange animal noises.

Solution: deploy Claude's code with Val Town's MCP

Val Town solved that deployment gotcha for Greg, who doesn't write code and isn't used to dealing with engineering infrastructure.

As I started digging more into Claude Code, I obviously ran into deployment issues. Instead of fighting with GitHub, I now have a simple solution: I just talk to Val Town using MCP. That's the most reliable part of my process.

Sales vals

For example, Greg compressed his sales knowledge and experience into a val that ingests meeting transcripts, updates their HubSpot CRM, and crafts a suggested follow-up for his sales team.

I built a sales coach into it that suggests a follow-up. We could even send those follow-ups directly from Slack with our Slackbot val. We're minimizing all of that manual CRM work.

The Growbots val sending action items after a sales meeting

In their Slack workspace, the Growbots team is joined by bots hosted on Val Town. The sales team can type /proposal exampleclient.com to run a val that generates a first draft of the outbound playbook for a sales pipeline, for example.

Scraper vals

Jakub on the GTM engineering team talked about using Val Town with Clay (see also: how we built an API for Clay). Jakub told us about switching to Val Town from another vendor to host their Cloudflare crawler, saving an order of magnitude in cost.

We use our Cloudflare scraper val for everything. It's an easily accessible endpoint that runs Cloudflare crawlers on Val Town, and it's something like 20x cheaper than our previous vendor. We import that val into other vals, or use it with tools like Clay. Actually, Val Town was the first tool recommended to me by Claude when I was looking for how to host "Claygent" workflows.

Takeaway: Val Town lets you forget about deployment

There's that old business advice to spend time on your core competency and outsource the rest. For Greg, that means letting Claude combobulate some code and deploying right to Val Town.

My goal is to test to what extent I can automate the whole company with Val Town so that I can focus on building. As a CRO, the biggest advantage of Val Town for me is that I've never even seen it. I do everything in Claude Code, and then it just runs on Val Town.

For Jakub, he also likes the instant deployment from Claude Code, but also having the full flexibility of code.

We dropped every single no-code automation builder we were using before. I just try to do everything with Val Town and Claude Code now. Those workflow tools are more complicated than Val Town—you have to fight with the platform, not the code itself. And it's cheaper with Val Town.

So again, if Claude Code is Amazon, then GitHub + deploying somewhere with a build step would be like USPS. Sometimes it's good to go with USPS—the Val Town application itself is deployed to Render—but often you want the convenience of same-day shipping (in our case, 100ms deployment).

Metaphors aside, it's quite productive to have an immediate feedback loop where the code you or Claude write is instantly live at a URL, or in Slack, or wherever. Sign up for Val Town, or book a demo with our founder Steve to learn how your team can enjoy frictionless deployment.

Lately: Claude front and center, a fresh val layout, MCP upgrades, new Pro pricing (for new users), and more.

The month of Claude

More and more Val Town users are having Claude Code bebop, wibble, photosynthesize, and jitterbug1 their vals, using the Val Town MCP server. Every val's homepage now includes a copyable command for using Val Town MCP + Claude Code.

The val.town homepage also now has that command handy to meet our potential users where existing users are using Val Town—in Claude Code. You can bring the Val Town MCP anywhere you get your LLMs, though—not just Claude. It works in Codex, Cursor, Copilot—you name it. If it starts with C and thinks all your ideas are great, it'll work with Val Town.

Townie now defaults to Claude Opus 4.6 with "Allow all" mode (a.k.a. YOLO mode) enabled (although you might consider taking things slow sometimes).

When starting a new chat, Townie remembers your selected mode and model from the last active chat. Opus 4.7 with xhigh effort level is also available, along with Sonnet 4.6 and Haiku 4.5 for faster and cheaper conversations. Inference is billed at-cost, without any markup: see our pricing update below for more information.

Our MCP server has new tools to remix vals and and copy files. That's over three dozen tools now. Pretty much anything you can do in Val Town, you can do with the MCP server:

• read/write/run code
• read/write SQLite and blob storage and logs
• set up cron jobs and email handlers
• visit HTTP URLs
• ...and more

New val layout

The biggest change in town lately is to the core val UI:

• Both the val sidebar and file tree are collapsible, allotting more real estate to the file you're editing
• There's an editor status bar abottom the code editor with logs, editor settings, and the Deno Language Server
• You can view history for folders, files, and the whole val
• The SQLite explorer makes better use of available space
• Townie launches from the top right rather than bottom left
• ...and dozens more changes

I've been loving the new layout, personally. Thanks to Jackson for his careful craftsmanship!

Pricing updates

We increased Pro pricing to $25/month, or $250/year. If you are an existing Pro user, your prices won't change! As a thank you for betting on us early, existing Pro users will pay the legacy $10 per month (or $100 yearly) forever.

After using up monthly Townie credits ($10 monthly for Pro and $100 for Business), billing is now pay-as-you-go with 0% markup on LLM inference costs. We pass through costs from our upstream provider, Anthropic.

Free plans are limited to public vals, only for new vals. Existing private vals on Free accounts will remain private.

Also, the Val Town Teams plan is now called Business.

Everything else

As always, many more changes have landed.

Val history and file diffs can attribute edits to Townie.

A Val ID field and HTTP section were added to val settings, so you can copy IDs and set *.val.run custom subdomains (as well as which HTTP file to preview on the val's homepage, as before). There's also a new save-and-copy button when adding a custom subdomain or email.

The main val.town/dashboard now has a switcher for toggling between your personal account and any orgs you belong to. User profiles also got a facelift—you can pin vals to feature your best work (like you'd pin repos on your GitHub profile).

The new val creation flow always has you fill out a form with owner, name, description, visibility, and image. Previously, you could create an untitled-* val, which was convenient, but it meant metadata wasn't as deliberate.

You can now download any public val, not just your own vals.

Script val logs now stream during execution rather than buffering until exit.

You can now sign in with Google, as an alternative to GitHub and email.

Townie now remixes opinionated starter templates by default when building new projects.

When you're on a branch in a val's code and navigate to another top-level resource, like SQLite, then back to the code—your branch now persists.

A confirmation dialog now appears in the SQLite explorer for destructive actions.

That's it for this changelog. As always, send us your feature requests! Our Discord server is the best place to discuss requests.

Footnotes

(1) Bebopping, wibbling, photosynthesizing, and jitterbugging are all, in fact, in the Claude Code spinner verb dictionary. I'd play a quiz game of "Is it a Claude spinner verb?" if someone made one. Hm, you could probably make one in 5 minutes with Claude Code and the Val Town MCP server...

Despite the countless failed attempts at trying to democratize coding while not understanding coding, we're faced with the reality that you cannot understand code without engaging with it.
-Lars Faye, Agentic Coding is a Trap

Lars's blog post got me thinking: what if we designed a deliberately slow, hand-holding agent? One that keeps the human programmer involved, to understand and learn. One that doesn't paint you into a corner with slop. No one-shotting, no agentic looping, but instead moving at a human pace to match your particular human knowledge at the time. I use the word programmer on purpose because I think even vibe coders should at least be learning programming concepts, like what data their app needs to store and how, or where that data travels (say, from their laptop to a data center in Ohio then into a database somewhere else).

We'll call this Slow Mode.

Slow Mode 1.0 with Claude Code

As a low stakes experiment, I first wrote Slow Mode 1.0 as instructions in CLAUDE.md for using Claude Code + the Val Town MCP server:

You are in "Slow Mode," which emphasizes human learning and decision making, not
speed and productivity.

- Do not agentically loop and iterate.
- Keep the human (me, Pete) involved every step along the way.
- Hold me accountable. Ask me to make decisions. Make sure I understand the
  tradeoffs of those decisions.
- Don't generate code right away. Plan first, together with me. When you do
  generate code, do it incrementally, one step at a time, just as I would,
  testing whether it's working as expected after each step.
- Ask me what to name functions. Ask me whether some code should go in a new
  file or an existing one, and how I'd like my folders organized.
- You can use the accompanying preferences so that you don't have to ask
  repetitively for straightforward things. Those preferences should give you a
  ballpark sense of what I know about programming.
- When necessary or helpful, pause to teach me something, but don't be too
  verbose up front. I can ask when I'd like to learn more and let you know when
  I'd like to move forward instead.

Stop and think

Of course, when an LLM thinks or reasons, it is really just generating more and more text.

...the models can only "think" by spooling out more text — while human thinking often does the opposite: retreats into silence, because it doesn't have words yet to say what it wants to say.
-Robin Sloan, Thinking Modes

LLM "thinking" can be problematic, assuming it's important to me to understand what's happening. I'd actually like to see the thought process, if you can call it that. In some ways, I think it's a feature, not a bug, that a slow mode agent would brainstorm linearly, token by token. It's the machine's way of rubber ducking, and I think we should be doing it together. I should be talking aloud and then dictating or typing the next decision or question back to my robot collaborator-teacher. I should be making some edits in the code myself, extracting a helper function here, renaming a variable there, running the code, poking around the database. I like that my slow agent keeps me in the weeds, so I can keep the whole program in my head. Like this:

I find coding in Slow Mode to be more pleasant. It's partially the prompt enforcing Slow Mode, but in large part it's also me self-enforcing by staying focused and thinking (much easier when your agent doesn't run off for 10 minutes in a loop!). Slow is smooth, and smooth is fast.

Slow Mode 2.0 (Slow Townie)

After experimenting with Slow Mode using Claude Code + Val Town MCP, we've started privately testing Slow Townie within Val Town.

The instructions are pretty much the same as above in CLAUDE.md for now, but an ideal slow mode would factor in your particular knowledge and preferences, building on the "memory" feature that many agents currently use. We should have a lot to learn from prior art when it comes to personalization.

YOLO Mode

The polar opposite of Slow Mode is YOLO Mode, where your agent loops again and again without stopping to ask for permission. It fulfills vibe coding's original definition. In Townie we do have YOLO Mode (a.k.a. "Allow all") because, well, to each her own. I enjoy YOLO'ing sometimes, typically when the stakes are low and time is short.

But more often than not, it's important to me that when I need a break—when I shut the laptop to go for a walk or cook dinner or sleep—my robot takes a break, too. Contrary to what seems like consensus among tech workers in San Fransisco, I think my agent should mostly stop working when I do (and I myself should probably stop working around dinner time most nights!). Plenty of developers I respect feel the opposite—fair enough.

Trading productivity for learning

Val Town's end goal is end-user programming, the dream that anyone should be able to customize their own software. Like a spreadsheet, there should be a natural gradient from beginners making something useful in the first hour to experts spending hundreds of hours on complex models. Users progress along that gentle slope by learning continuously over time. But is end-user programming about learning, or about building the thing? I think it's about both: the more you learn while building, the better you get at building.

There's an inherent learning-versus-productivity tradeoff when using AI. I am no stranger to sacrificing my own learning or solid understanding of an implementation to prioritize shipping. When you have a lot on your plate, that can be the right side of the tradeoff. But there's also a short-term gains versus long-term maintenance tradeoff, and I'm betting Slow Mode will help with that.

Learn to cook

I know many people think moving more slowly means falling behind, or worse, that by insisting on understanding code we're gatekeeping. By embracing Slow Mode at Val Town, we're telling vibe coders we believe in your ability to learn fundamentals about code that might've previously seemed unreachable. Building in Val Town (or elsewhere) with Slow Mode should empower you. You should feel like you know what you're doing, not like you're dependent on your agent and helpless if there's downtime.

It's like cooking with recipes versus learning about food fundamentals so you can improvise in the kitchen and create food that's all your own. Val Town is the Salt Fat Acid Heat of vibe coding platforms.

Prior art

We're not the first to propose something like Slow Mode. It turns out Claude itself already has a "Learning mode," ostensibly for education but also relevant to professional and hobbyist (vibe) coders. ChatGPT has "study mode" (also more geared toward students). Just last week, the same day I wrote the first draft of this very essay, a Claude/Codex Skill for "deliberate skill development" attracted a bunch of GitHub stars and Hacker News comments.

Just like Val Town fast-followed all the best coding assistants while building Townie, we'd like to learn from others and share our own improvements to Slow Mode along the way.

In 2023, I wrote about how Val Town moved away from Supabase and toward a more conventional database setup. We were using a lot of Supabase's functionality, including their authentication. So when it came time to move we found equivalents: Render for the database, and Clerk for authentication. But life came at us fast, and by late 2023 we had an issue filed: get off of Clerk. That issue was finally closed a month ago, when we switched to Better Auth.

Some important context is that Clerk is a major success. They just raised 50 million dollars and they have lots of satisfied users. Heck, in related news Supabase raised 100 million dollars at a 5 billion dollar valuation. Congratulations to both of them. I would make a terrible venture capitalist. Whatever opinions and experiences I hold about authentication and row level security are secondary to these numbers and proof. You can't argue with success.

But still, I am happy to have closed that issue and switched to Better Auth. It's been a tough experience, with a lot of workarounds, bugs, and outages. The architecture of Val Town sharply conflicted with Clerk's expectations.

The core issue

The core issue is that Clerk tried to be your users table and your sessions table. I think they've been shifting away from saying this, but it started from a pretty extreme place: there's a 2021 blog post titled "Consider dropping your users table". There's a YouTube video from 2023 called DELETE your Users table. I strongly suggest you don't!

There are two big problems with farming out your users table to a third-party service.

Clerk was a pretty bad replacement for a users table because it was heavily rate-limited and not very reliable. When we initially switched, I assumed we could load user data from Clerk's API whenever we needed to. After all, we want to know things like user settings, avatar URLs, and emails. Clerk's SDK made this pretty convenient: the rootAuthLoader, the thing that handles auth for your whole application, had a nice little option called loadUser which would do the request for you. Worked great in development. In production, the rate limit for that endpoint was five requests per second. For the whole account, across all users. Tough! A pretty bad footgun, that we discovered in production, and was eventually fixed by removing the option.

The rate limiting hit us especially hard for the social aspect of Val Town. For example, let's say you have a social website, so a lot of pages have lists of content from other users, and usernames and avatars to identify them. Clerk's default UIs are based on the assumption that a user only sees their own avatar and needs their own settings and information, and they can get all of that stuff from their nifty JWT token. Social websites like Val Town completely break this assumption, and the advice was to sync avatars and other information between Clerk and our users table: so now we have two authorities for that information, and the complexity of two users tables.

So we had to sync Clerk's data to our database by using webhooks, which meant that signing up was convoluted and tricky - for a few moments, a user has a Clerk account but no Val Town database row. Or, because our platform requires usernames, users can be in a state where they have a Clerk account, a database row, but their account is incomplete. Our user settings had to be split between things that Clerk controlled, like auth strategies, and things that we needed, like usernames and editor settings.

The second is that Clerk became a single point of failure for all our user sessions. Cookie-based user sessions are usually short-lived with constant refreshing: that way they can be invalidated quickly. But that also means that every few minutes users need to swap their session cookies for new ones. So when someone's login session needed to be refreshed, it was a subdomain of Val Town that passed the request to Clerk that did the refreshing. We didn't have a sessions table or any responsibility over sessions.

That's great, if you're trying to keep avoid any responsibility for authentication, but on the other hand, if Clerk goes down, the whole website goes down. Clerk outages don't just break the login & logout flow, they make the site unusable to people who are already logged in. And Clerk went down pretty often, and went down for long periods of time. Since May 2025 it's been teetering between two and three nines of uptime. There isn't data from before then, but I remember many times that we had a broken site and no way to fix it because of this single point of failure.

A hard lesson you learn building a complex system is that its reliability is the minimum of the combined reliability of its critical parts.

Besides these two major issues, there were other bugs and problems we encountered. Most got fixed eventually, but I spent a lot of time battling the "Stale Issue Bot" from auto-closing them.

Three-ish years

If it was so bad, why didn't we switch away immediately?

First of all, even though this will be the second "switching from X to Y" article I've written, and I'm not trying to make it a habit. Making decisions and sticking with them is good for development velocity and team sanity. We're not trying to rewrite Val Town any more than is absolutely necessary. And writing critique is less fun and positive than building.

And Clerk did some things well. They provided SDKs for all the tech we were using: Remix, Fastify, and Express. They did a decent job of keeping up with the churn of those frameworks, a task that I know is a full-time job. And their administration and anti-abuse measures were decent at helping us solve customer support issues and keep scammers at bay.

Where Clerk definitely shines is relatively simple, heavily frontend apps that don't have a social component, so they don't need a users table. It was incredibly easy to get started, affordable, and the Clerk dashboard is pretty nice.

And there aren't a ton of great options for authentication. The bar for a Clerk replacement was actually pretty high: a lot of open source auth solutions are ancient and semi-abandoned. Authentication-as-a-service platforms had vendor risk and potentially the same problems as those in Clerk. The right level of technical control is hard to nail. We don't want to build authentication from scratch and open Val Town up to new and embarrassing new vulnerabilities, but we also don't want to offload so much responsibility to a provider. Definitely not trusting third-party session management again.

Better Auth enters the frame

Better Auth checked a lot of boxes right out of the gate: high code quality, good integrations with different frameworks, and truly usable as an independent open source project.

There still is vendor risk: it's a big, complex codebase developed mostly by one company. There's always vendor risk. But we are no longer dependent on a third party staying online in order for sessions & user auth to work.

A close second place was AuthKit from WorkOS. I trust WorkOS and AuthKit is incredibly slick, but after bouncing between two vendors, it was important to me to find something that could work independently and was open source at the core.

I find Better Auth's dashboard and paid add-ons to be really clever, too. We manage all of our data, and a plugin provides an API on our site that lets their dashboard pull information and do some light user administration. Better Auth's paid service (called 'Infrastructure') is basically stateless in the way that we use it, and uninvolved in session management.

In short, so far it really has been better.

And reluctantly I have to hand it to the LLMs here: with the augmentation of the robots, we were able to take the more complex route of supporting both Better Auth and Clerk for a transitional period of two weeks. Every endpoint that handled authentication would accept either kind of cookie, and users slowly moved over to Better Auth because that was the kind of session that the sign-in page provided. Like anything related to security, close reading, rewriting, and testing of all of the code was necessary to make sure we didn't self-own, and the eventual pure-Better Auth auth was handwritten entirely.

Better Auth also works pretty well with Vals: you can try out the Better Auth starter template to add authentication to your code on Val Town.

I've learned a lot along the way. You really do depend on upstream providers for your uptime, and should think hard about how exposed you are to that risk. Products can be good for a lot of use-cases and really successful and still not the right thing for your specific problem. The world of software changes quickly and the right solution might not exist at the moment you need it, but might appear a year later.

Code is inert. How do you make it ert?

-Paul Ford, What is Code[1]

Right now, there is more inert code in the world than at any other point in history. Tomorrow even more inert code will exist, only to be one-upped again every day after that. I wouldn't be surprised if soon one of the leading AI labs claims something like, "90% of all the code there ever was has been produced in the last week." Produced, mostly generated, not written.

90% might be an exaggeration. Paul Kinlan's napkin math has language models taking credit for 5% of public commits on GitHub, but that doesn't count uncommitted nor unattributed LLM code. Either way, written or generated, much of that code is inert.

What does it mean for code to be inert?

One reasonable answer is that code is inert whenever it's not going brrr, not running, not "being executed." And of course, code can run locally on your personal computer or elsewhere on some server. But in this essay, I mean code is inert when it's not deployed. Code that isn't deployed can't be easily shared and run, at least not without friction.

There was a meme in the early ChatGPT days where a programmer gets a text from a non-programmer friend. It goes something like this:

The non-programmer friend's smile fades (one imagines) upon realizing they have no clue how to actually bring that code to life, how to make it ert. Since that meme, companies like Lovable, Replit, and Bolt have largely solved that particular disconnect for vibe coders, but even for you the programmer and your collaborators there's still often a bridge of friction from inert code to deployed code.

Well, Val Town makes code ert.

Val Town makes code ert

Concretely, Val Town lets you write and run JavaScript. It's a code editor in your browser, synced to our servers to run that code "in the cloud" (read: an AWS data center in Ohio). And whenever you save a file with your code in it, we sync that code to our servers in 100 milliseconds.

There's no localhost, which means there's no deployment bridge to cross from localhost to production. Steve (one of Val Town's cofounders) told me that my first draft of this essay severely undersold this point about skipping localhost. He gave that feedback in a video articulating Val Town's core bet (on the browser, against localhost) in a raw, honest sort of way that is hard to replicate on a podcast or scripted video. With his permission, I'm including a clip of it here.

When code is always deployed, you get a satisfying instant feedback loop. And as importantly, it's trivial to share your code and collaborate. It's why Val Town suits a Computer Science professor teaching web dev fundamentals to university students; OpenAI's Head of Realtime launching their new voice model; and Kilo Code engineers collaborating on a support agent.

Whether or not you read the code, it's gotta be ert

Our industry is in the middle of a debate over whether the code itself matters at all. Whether you the programmer need to read and review your LLM's code. Historically, Val Town has defended the position that code does matter. Steve wrote a blog post a couple weeks ago that floated right up to the front page of Hacker News with over 400 comments: Reports of code's death are greatly exaggerated.

But whether or not you think code matters, it must be ert.

Unsurprisingly, a lot of our users are vibe coding internal automations, agents, prototypes, and demos. They're writing less code than ever but generating more code than ever (remember, "90% of all code..."). Many archetypes are doing this sort of work: technical founders, go-to-market engineers, forward deployed engineers, product engineers and PMs, business analytics teams, and internal devtools teams.

A common sentiment is that it's super easy to produce the code, asymptotically approaching zero cost. Or at least it's getting faster, smarter and cheaper all the time. But then the gotcha or bottleneck—the hard, slow part—is deployment. We hear people say deploying is where they got stuck, or where their less technical teammate or friend gave up. And that's the whole point of Val Town. There isn't any deployment because it's already, automatically, always deployed.

The code is ert.

***

Footnotes

(1) What is Code is Paul Ford's famous essay in the June 2015 issue of Bloomberg Businessweek. B-list famous in some programmer circles, anyway. The essay is practically a novella: 38,000 words divided across seven sections (chapters?). The scrollbar on the web version is stubby, hard to even see, and you get a sardonic "Certificate of Completion" at the bottom for reading it. The web version also has all sorts of interactivity and easter eggs. Scroll through the paragraphs too quickly and you'll see, "Are you reading my essay, or looking at my essay?" I've never read the print version, but I've searched around for an old copy more than once, so please do email me if you know where I could get my hands on one (seriously).

Better Townie system prompt, std/oauth, migrating from Clerk to BetterAuth, Deno 2.7.5, and more

Your agent should answer to you, not your vendor

Every user gets a database interface!

Townie v5, powered by Val Town MCP and Claude 4.5

Bring Val Town to your favorite LLM

Continuing to fund open source software

I/O with a val in the middle

How I wrangle the many tools that we use to build Val Town

Write your scripts on the internet, from your terminal, or in any editor

Running the Deno LSP to make our TypeScript language tools dramatically better

Bring Val Town to work

Code that nobody understands is tech debt

Townie is now pay-per-use

Saying goodbye to a platform we admired

Vals are being upgraded to support multiple files, folders, and more