Into the Gnar, Episode 3: The Stack We'd Use to Start a B2B SaaS Today

If you were starting a B2B SaaS company today, with 18 months of runway, a team of five, and real customers to win, what would you actually build on?

We get asked this constantly, and the honest answer has changed. For a decade, you picked the stack your team knew best. That rule is dead. In this episode, Nick and I make the case for a complete inversion: optimize for the LLM, not the developer. It matters less what your engineers have experience with, and much more what the models are proficient in. That's why a company that built its reputation partly on Ruby on Rails is recommending TypeScript for new builds, and it's why the LLM itself now belongs in your stack decision alongside the database and the framework.

We also get into the worst stack decisions we've inherited (including an API endpoint that would execute any query against a production database), the news that Cursor, Claude Code, and Codex are becoming layers in one stack, why we'd take a monthly AI license over an annual one every time, and the gap between the 84% of developers using AI daily and the 29% who trust what it produces. Then the concrete picks: TypeScript, Next.js or SvelteKit, PostgreSQL, Cloudflare, and boring technology everywhere you can get away with it.

This is the episode to send to your CTO before your next architecture conversation. Watch it above, or read the full transcript below.

Key moments

• 0:00 The scenario: 18 months of runway, a team of five, real customers to win
• 0:48 The worst stack decisions we've inherited: overcomplicated AWS on day one, and an endpoint that ran any database query
• 3:15 News: Cursor, Claude Code, and OpenAI's Codex stop competing and become layers in the same stack
• 4:30 Different brain, different blind spots: using a second model for code review
• 8:10 The licensing risk nobody prices in: why monthly beats annual for AI tools
• 10:11 News: 84% of developers use AI coding tools daily, only 29% trust the output
• 15:39 What a CEO should ask a dev shop that's pitching AI speed
• 18:36 The 80% done problem: AI drafts are exploding, finished work is still hard
• 20:06 News: JetBrains data shows Claude Code growing from 3% to 18% while Copilot goes flat
• 26:31 The mental model: optimize for the LLM, not the developer
• 29:39 Boring technology still wins, but for a brand new reason
• 32:31 What AI-ready architecture actually means (it's not exotic)
• 34:26 The Gnar stack today: TypeScript, SvelteKit, Cloudflare, Supabase, AdonisJS
• 38:22 Great people, good process, boring technology. That's what ships.

Full transcript

This transcript has been lightly edited for readability.

Mike: Welcome back to Into the Gnar, where the cutting edge of software gets built. I'm Mike Stone, here with my co-founder and co-host Nick Maloney. On today's episode, we're answering a question we get asked a lot, especially since the SaaS apocalypse: if you were starting a B2B SaaS company today, with 18 months of runway, a team of five, and real customers to win, what would you actually build on?

This is the episode to send to your CTO before your next architecture conversation. So let's get into it, Nick. We've seen a lot of codebases over the years. We've probably seen it all in the past decade. In your mind, what's the worst stack-related decision you've ever seen a client make, and what did it actually cost them?

Nick: Ooh, that's a good one. The one that immediately comes to mind for me is more in the infrastructure realm, but we'll call it stack. You get a non-technical founder that hears that they must use AWS. And I'll preface this by saying there is nothing wrong with AWS, but it is a skill set, and we've seen this many times. We inherit a codebase and it's a super complex AWS setup that they don't know how to manage. All of their time, or our time, is spent dealing with that and not shipping code. And it always ends up being that there's no automation, everything's super janky, and we're having to go in while they're manually configuring Linux on EC2 instances. Everything is way overkill, and they spend so much time and money on that versus just focusing on the core product. We've seen other examples with some questionable tech stacks, but the number one example for me is probably the super overcomplicated AWS build on day one.

Mike: Yeah, there's a common theme we'll be discussing throughout the podcast, related to this too: the tools themselves often aren't the problem. It's the implementation that's the problem, right? There's nothing wrong with AWS, but you can mess it up pretty good, just like you can mess up just about anything.

My mind went to an app we inherited from an overseas agency, I think it was at the time, that had an API endpoint where you could arbitrarily pass it queries that would execute on the database. Again, not a stack problem. It was a Node app, and people have their opinions there, but there's nothing inherently wrong with Node. But you can mess that up pretty good too. And they surely did. More of an execution problem versus the stack itself.

All right, let's get right into some news this week. This first story is a good one, and it connects directly to what we'll be talking about in the main segment. Cursor, Claude Code, and OpenAI's Codex, which are the three biggest AI coding tools on the market, stopped competing with each other this week and started working together as layers in the same stack. Nobody designed this. It just happened. So Nick, we're all in on Claude Code here at the Gnar, but would you recommend the three-tool stack to this hypothetical scenario of a five-person B2B SaaS team starting out today? Or do you think this is overkill?

Nick: I think it's overkill. My immediate recommendation is just use Claude. It does code exceptionally well, and it handles all the other non-technical pieces through its desktop application, and it's one billing. It seems to overcomplicate it if you start to use all these different tools. And we don't use a bunch of different tools anymore either. We've standardized on Claude, and I've been real happy with it.

Mike: So what do you think about over-reliance on one LLM? One thing that I think is cool here is that Codex released a Claude Code plugin that gives you skills, like using Codex to review code. And that to me seems really cool and not over-engineering, 'cause you essentially have a different brain, a different person, reviewing code that was generated by a different LLM.

Nick: Yeah, and I like the standardization on agent tools, for instance, so the skills you're writing are applicable to the other providers. And we have been bitten by being reliant on one. For instance, we had run out of tokens before and tried Gemini, which we have an account for through our workspace, but it just isn't as good. I think these are fine. For me it's a known risk that we incur for having a simpler stack, but it hasn't bitten us enough to overcomplicate things. Maybe at larger orgs it's a different matter and you have an entirely different setup. Maybe you're using Bedrock and it's all abstracted. But for most startups, I still wouldn't hesitate to use and recommend Claude, knowing what the compromises are.

Mike: Yeah. So if you're talking to a company choosing a tech stack, how much does AI tool compatibility factor into the decision they're making?

Nick: I think it's important, knowing which tools are better for coding, but it's not the only choice. There's an ecosystem here too. I would say your primary use case, or one of them, is for your dev team to use these tools. I'm biased towards Claude Code, but I don't think you can go wrong with Cursor. We've had really good luck with that too. I think we just wanted a more uniform skill set. But some of the others aren't as good at code, so I'd stay away from those. Gemini I'd shy away from. I haven't been pleased from the coding perspective. But any of the big players are pretty good. Codex is actually really good at coding as well, so I don't think you can really go wrong with any of them.

Mike: But if you look at the output, the code that gets generated and the framework it's written in, is there a framework or language that's dramatically better or worse for the AI tools to work in? Or does it not matter so much? Like Rails versus TypeScript versus JavaScript, Golang?

Nick: TypeScript. That's what the bulk of the training is on, just because there's a large corpus of projects out there. It's a safe bet. So that's my default answer on probably any question in that realm: just go with TypeScript, certainly if there's a front end component. If you have specific needs in a niche area, maybe it's different. But I'd start there and then walk through it. For microservices, sometimes Golang makes sense. That works really well. Having types is really important, I've found, just to ensure consistency. But I'd stay away from some of the esoteric languages, as cool as they are, and keep it simple.

Mike: Yeah, everyone has fun writing those languages, but no one's really writing code anymore. The AI is doing it, so it's better to choose the popular frameworks.

Nick: Yeah, exactly.

Mike: I think there's another risk here too, with the licensing. We're big into Claude Code because it's, in our opinion, best in class right now. But Anthropic, and I'm sure the others are similar, and this is no shade on Anthropic, but the way the licensing works adds risk to an organization too. As we've talked about with the team, Claude Code is where we're at right now, but we'll move where the market moves, and we've already used Augment Code, we've used Cursor, now we're on Anthropic.

But they're locking you into these annual licenses with no refunds. You can't switch from an annual license to a monthly license. So if you're trying to give your team the best tooling, you need to think about that risk. It's something that's been top of mind with us: how much are we really gonna commit to these annual licenses they want to get you into? Or you try to find other ways, monthly licenses, but you can't mix and match. So it's a whole headache in and of itself, which is not fun.

Nick: Yeah. Without question, go with a monthly license, even if it's 20% more, because it gives you that flexibility and it allows you to select different licenses. 'Cause if you prepay for an annual license and team members need to go up or down, you're out. With monthly, it's a lot more flexible, and like you said, you can't change. That's a big regret that I have, not doing that. We thought we'd save money, but I think we're gonna end up either getting bit by it, or now we have the overhead of needing to create separate orgs with a different billing scheme. So for anyone listening that's having to make that decision, I would highly recommend you go with a monthly license.

Mike: All right, on to the second story. There's a gap showing up in the data. 84% of developers use AI coding tools every single day, but only 29% actually trust what the tools produce in production. That's a massive gap between adoption and confidence. So as we build with Claude Code and Cursor at the Gnar, what's the actual governance process that lets you trust what ships? And how does the stack choice affect how easy it is to enforce that governance?

Nick: Yeah. As you know, we've made significant time investment in our own tooling, and we were talking about this exact topic with the team last week and this week. The summary for me is: you really need to trust the process so that you can trust the code, right? Making sure you have linting, testing, sane CI/CD, multi-layers of testing. And going back to our previous set of questions, choosing a language that works well in that space. That's why I'm a big advocate for type safety, because it catches a lot of things that dynamic languages like Ruby sometimes don't surface until runtime, and that has definitely bitten us. Not to throw shade on Ruby, but it's a pain point and why I really prefer TypeScript. But again, it's building out a robust process for these tools so that you can trust them for code, and you're not having to worry as much. And it's letting go, for sure. That's something you have to do to be able to push out that volume, but that's the way things are shaking out these days.

Mike: Yeah. I think that trust number, too, maps to what we're seeing and hearing about AI adoption generally. When we talk to experts that are handling change management related to AI at a lot of large companies, they're saying that about 25% of people are fully embracing it, about 50% accept it as the new reality of their job, and 25% actively resist it. So there's a bit of a bell curve. And outside of that 25% that are embracing it, there's real trust issues, and maybe even some within that 25%, which kind of maps to the same 29% of folks that are trusting the output.

So this seems very real to me and my experience. But to your point, there's all sorts of ways you can lock down the AI, or add guardrails, to have more trust in the output. At the end of the day, though, you've gotta let go, take the governor off, and let it rip. And the cool thing is that if things break, you can fix 'em a lot faster than you used to be able to as well. I guess there is a way to have some training wheels, but you're not gonna get the impact of the tools unless you really take them off.

Nick: Yeah, that's an interesting analysis on the 29%. Where does that sit against the AI champions, if we look at that segment you described? I bet that's spot on. The folks that are more confident have that fluency and the process in place, where the skeptics are just not as familiar with it.

Mike: Yeah. A lot of companies are really focusing on speed of output, right? There's the trust component, but then there's the speed. And I think a lot of the folks I've talked to that have the trust issues with AI, it's because they're very experienced and they can analyze the output, and they want to pull the reins back on AI a little bit. Whereas some of the people that immediately say, whoa, this is awesome, this is amazing, those are the non-technical folks that are just like, holy cow, I can make this whole application just by throwing a prompt in this text box.

So I think those sorts of hooks and guardrails are crucial for getting the folks that really know what they're doing comfortable with using the tool. 'Cause then you get the high amount of throughput with the high quality as well. It's related to the vibe coding stuff we talked about last episode, but it also leads to this next question I have for you.

For the CEO listening who's about to hire a dev shop that's pitching AI-assisted development as a reason they're faster: what questions should they be asking to find out whether that speed is real, or whether they're the future Monday morning incident?

Nick: I would zero in on what their process is. I think we've said the line on every podcast: one bad line of context or requirements is a hundred lines of bad code. If they don't have that process figured out, and they're just diving right in and cranking out lines of code, it's gonna result in Datadog, or whatever APM you have, paging you on a weekend night. It's all about front-loading the requirements and understanding the product and process upfront. The code is almost secondary, because the robots are essentially doing that. We manage it, we still own the code, but I just think of where we've been spending all of our time, and it's the process to code production, not the actual production in and of itself. Have that conversation and understand how they're working and what guardrails they have in place. Not "are you a 100x shop." There is a quantity component, but at the end of the day, it's quality that matters, to ensure things aren't broken.

Mike: Yeah. I think speed's the easiest thing to claim from AI-assisted work. There's no doubt that you can have a lot more throughput, but speed doesn't mean it's gonna work right. And there are so many examples we see of people getting the speed wobbles when they go a little too fast, and then they end up crashing and the app doesn't work.

So I think it's critical to learn more about process, like you mentioned. How are they making sure the code actually works as expected? What do they do when it doesn't? Just diving in a little bit more to understand how the sausage is made, so to speak.

Nick: Right. And just clarifying what the definition of speed is. It harkens back to when folks used lines of code as the unit of measure delivered, and that doesn't matter. What matters is features delivered. Working features delivered. That's what should be focused on, even when they're evaluating throughput. If someone says, oh, our devs are 50x or 20x, none of that matters if it's just churning out a bunch of bad code. How many things on your backlog are getting to done in Jira is all that matters at that level.

Mike: Yeah, that's super true, and it's not even code related. I think it's part of the journey with AI. You can produce so much, so fast. But people also get very overwhelmed by the output of AI. You're making all these documents that are dozens of pages, or producing just so much work so fast, that if you're a developer, it's: how do you review that much code? If you're in journalism, it's: how do you edit that much content? If you're just trying to do your job, you're getting inundated with the amount of work that's getting done. And getting that work, the work that's technically done, that the AI finished its draft of, over the finish line to actually deliver value to your organization, in whatever way that is, deploying a new feature to production or a new blog post or whatever, can become really hard. The amount of 80% done work is skyrocketing in the age of AI, but getting stuff to 100% is hard.

Nick: And it takes 80% of the time.

Mike: Yeah, exactly. All right, third story. JetBrains surveys tens of thousands of developers every year. It's one of the most reliable data sources in the industry. They just published their April results. The headline is that Claude Code grew its adoption rate from 3% to 18% in under a year, and GitHub Copilot, which Microsoft's been pushing hard, has gone flat. The conclusion from the data: when a tool is just better, developers find it, even if the incumbent has more distribution.

So, the JetBrains finding, performance over platform, developers choose the best tool. Does that change how you think about third-party services in a new SaaS build? Are we in a moment where best-of-breed just beats the integrated suite?

Nick: I don't know, that's a tough one. It's the classic "yes, but." I think there's a middle ground here, because as we've seen, you have to commit to something. You can't just change everything overnight because there's a new hotness. But at the same time, you can't stay married to something either, because you have an annual contract or it's a large incumbent.

So I think there's probably a layered strategy, where you have a suite of tools that you more or less standardize on, but you set yourselves up so that, not if but when, something more effective comes along, you have a process for evaluating it. It's not scrambling last minute to jump in. But if it checks out, and you've validated that this is a tool you should start to use, you have a plan for migrating over to it. It's not an if, but a when, that you're gonna be jumping on another tool. Just be comfortable with that and have a process for your team.

I think about the tools that we use, and we talked about this earlier with things like skills. If you're able to select a platform that's compatible with agent skills, that sets you up a lot, because then you're standardized on this universally accepted standard for doing things, but you're not married to one platform. So yeah, I think having that flexibility, and having a process around it, is how I'd evaluate it, versus feeling compelled to only stick with one, given all the churn that we've been seeing.

Mike: Yeah. I think Copilot is weirdly more of a dated AI model in my mind. It was helpful to use it for tab completion back in the day when it was first released, but the industry's moved so far beyond that. Which is crazy to think, 'cause it was what, a year and a half, two years ago that that was the case? It wasn't forever ago. But it never earned my trust that I could give it a prompt, anything beyond tab completion, and not have to tweak it. I always had to do some manual work to the output I was getting from Copilot.

But I will say, its integration into GitHub, its distribution for code reviews within GitHub, is meaningful. To just be able to click the button to have Copilot review code. I think it does a good job reviewing code. That seems really solid, and you don't have to think much about your AI stack. It's just integrated into the tool.

We've done a fair amount of switching around between the models, and it's one of those things where trust is slow to build and easy to lose. It never built for me with Copilot. But it built, and ChatGPT was kind of the base that everyone was using, and then as I got more and more exposed to Claude and Anthropic, I really rallied behind that. I thought the outputs were good to begin with, and it also gave all of these other tools and connectors and skills that would just make the output so much better.

Nick: Yeah, and I gave a fairly generic, watered-down response where I didn't get into specifics, but you touched upon it. Copilot isn't even on my radar for something we'd use as a proper LLM. I don't even have it enabled on GitHub anymore, 'cause the Claude plugin is just as effective, and we're already paying for it. I think they're really focusing on building an ecosystem. They might not be as flashy in the eyes of consumers, but amongst tech folks, they're an incumbent. I think Codex is making inroads there, but I don't see Copilot ever gaining market share in the dev space. But I could be wrong.

Gemini was an interesting one for me too. I loved it because it came with our Google Workspace, and the thinking side of it was pretty good, and I was pretty excited about their equivalent to Claude Code. But after using it, it wasn't nearly as good. I'd still have my eye on it. I wouldn't jump in, but a year out, it could be a contender again. I think things are stabilizing a little bit. I say that, and something new and big's gonna come along. But I think we're gonna see less churn and more folks rallying around sort of the big three.

Mike: Yeah. Just give it a week.

Nick: Yeah, exactly.

Mike: All right, let's jump into our main segment here. This is the stack we'd use if we were starting a B2B SaaS today. Before we get into specific tools, let's establish the mental model. Most founders make the mistake of asking, what's the best technology? When the right question is, what's the best technology for this team, at this stage, for this type of business? So let's start here. Before we pick any specific tools, what's the mental model for making stack decisions when you have limited runway and no margin for error?

Nick: I think mitigating for churn. We talked about this earlier, but really understanding what your vision is for the product, and what it isn't. I know that's non-technical, but that's where all the problems we typically encounter start. If you're not clear on what it is you're building, then it's just gonna be a whole lot of churn and rework. Versus, if you say for v0, v1, MVP, whatever, here's what we need to ship. Once you have that defined, then you start making the technical and architectural decisions. And from there, I think we have our vanilla suite of tools. It might differ a little bit, and we've already touched upon this, but TypeScript-based platforms are always a good starting point. I don't know if we wanna get into the exact tech stack just yet, but we've got our usual suspects that we recommend there.

Mike: Yeah. I think the LLM tool is becoming more and more a part of the stack too. You could even consider it almost an employee, where it's the one actually producing the work and you have the humans guiding it and steering it. But I think it's important to consider, in the stack, what LLM you're using and what it will be good at producing.

Nick: Yeah. And thinking through some examples we've had, particularly on starting points: it's okay to start with a vibe coded solution too. That's a good exercise to hash out what I was talking about earlier, defining what the core functionality is. But I wouldn't recommend going to market with that. I would be extremely hesitant to say, launch your production-grade app from something you built in Lovable. But I think that's a really compelling way for non-technical folks to get their ideas on paper, maybe some of the visuals, and then hand that off to the dev team as a requirements artifact. Not a "hey, here's this pile of spaghetti code, fix it up." I'd replatform, but use that as a reference point.

Mike: Yeah. It's a communication tool.

Nick: Yeah, that's a great way of putting it.

Mike: And we've always made the case for boring technology at the Gnar. Back when humans were coding, we would always play the "keep it as simple as possible, use the established tech" card. And that's not saying we were working in anything too ancient, but Ruby on Rails is an example. We enjoyed working in that framework, the developer experience is good, but it's also a secure, robust framework with a test suite built in. It was a natural choice. The answer to boring technology seems to be changing now, though. I'm curious what you're thinking in terms of that mentality. Are you still in on boring old tech, or has your mindset shifted?

Nick: I'd say for the most part, yes, when it comes to language and framework. This is probably my fifth time saying it on this episode alone: go start with TypeScript. I already touched upon why I don't reach for Ruby and Rails anymore. It's all about type safety, and a shrinking ecosystem. I don't wanna hate on it. I was a Rubyist for years. But TypeScript with some framework. If your dev team is familiar with React, you can do no wrong with that. I have opinions on Next.js, kind of the default. I don't like its security posture. I think there's a reason Cloudflare rewrote it, so at the very least, use that. I love SvelteKit and Svelte. That's my go-to stack at this point, and if I were to be CTO of a SaaS company, I'd go with SvelteKit, maybe with Drizzle as the ORM, running on Cloudflare. They're bulletproof. Super reliable. Pretty straightforward.

Where it starts to get a little more blurry for me is all the new tech you're gonna need related to AI, because more and more products need that level of integration. When you get into vector databases and things of that nature, they just haven't been around long enough to have truly boring tech. You could make the case for Postgres and pgvector, but there might be other tools better suited for your need that are new. So you're gonna have to make some decisions there. But when there is an option to choose boring tech, go with it, and then for specific niche areas or needs, make a very data-driven decision on what you're optimizing for.

Mike: Yeah. You touched on this a little bit, but how do you build the stack so that AI features can be added later without a rewrite? What does AI-ready architecture mean to you?

Nick: That's a good question. I'm thinking through how we model engagements and a lot of the setup work I talked about. We call it Ideate, when we're in the ideation phase, but it's more than just a PRD. When we're thinking about building out these products, there is a technical component, and we're laying out what the architecture is. It's as complicated, or probably as simple, as you need it, and nothing more. But there's other pieces on top, like a sane data model to begin with. Don't do anything weird. I don't like document stores or anything like that if you don't need them. Keep it as simple as you can. Define that upfront, from your data model to your infrastructure stack, and then build up on it. The more planning you can do upfront, the better. I've found that's working a lot better for us than winging it on the fly, and it makes it a lot more extensible.

And then just follow all the good old-fashioned best practices we've always followed. Good engineering best practices haven't shifted that much in this new world we live in, right? We still want good tests, composable code, a framework so that both you and the AI know where things live, conventions and standards. All of that is still really important. You're just doing it a lot faster.

Mike: All right, so wrap up this section by telling me about the Gnar stack today. What is it? Is there anything you'd change about it?

Nick: Playing this out, because it's not singular, right? But, and I mentioned it a little bit, if I were a CTO, my tech stack would probably be SvelteKit. For infrastructure, my go-to is Cloudflare to start with, if it covers all of your bases. They've got a wonderful dev environment and deployment story. Super easy. It's incredibly robust, and I just don't have to think about it. So really happy with that. I will take that any day over Vercel or some of the other tools. It also happens to be even cheaper, which is a bonus too. If costs were the same, I'd still go with Cloudflare.

On the tech side of things, I, again, am biased towards SvelteKit, but you might be needing the React ecosystem. So I'd probably gravitate towards Cloudflare's rewrite if you need to go with Next, or we've had really good luck using TanStack or Remix.

On the database side, that's the only caveat I'll say with Cloudflare. Their D1 is a very robust, battle-tested flavor of SQLite, and I haven't hit scalability issues there, but it also limits some of the ecosystem that Postgres offers. I think it's just a matter of time till they come up with a D2, Cloudflare's Postgres offering. But if Postgres is a must, Supabase is something we reach for pretty regularly. Super happy with it, and because it's agnostic, you can use it with any other runtime platform.

I'm trying to think what else we reach for. We keep it pretty simple on the tech side of things. Obviously GitHub. That's it for CI/CD; we get as much as we can out of GitHub Actions.

Mike: AdonisJS has been a great full-stack TypeScript framework we've used a lot.

Nick: Yeah. If you're having to get into building really robust APIs, or need something with a little more depth than what some of the more Next.js-influenced frameworks provide, that has been great. But I think the pattern here is pretty clear. We've been heavily into TypeScript land, where five, ten years ago we were big into Ruby on Rails. We've done a little bit with Golang, but that's usually for a very specific reason, so it's not something we reach for regularly. But I think that mostly covers it.

Mike: Cool. And I think one important thread there: it's less important what your team is familiar with, and more important what the LLMs are familiar with. Obviously it helps to have experience, but in the example of Golang, it's super easy to pick up, and it's one the LLMs have a lot of learning on. Especially Gemini with Golang. That's probably gonna improve a lot more.

Nick: Yeah. I did put a little bit of shade on Gemini when it came to coding, but I have built a few CLI apps in Golang, and it did really well there. I imagine their training model has a lot of Golang reference codebases. If that's your ecosystem, it works really well.

Mike: Awesome. All right, well, that's episode three. If you're sitting on a stack decision right now, someone on your team's pushing you toward shiny new frameworks, or you're not sure what to build your next product on, I hope this gave you something concrete. The answer's almost always simpler than you think. Great people, good process, boring technology. That's what ships. Drop a comment and tell us what you want us to go deeper on. And if you've been wondering whether your team is actually ready for AI tools, take the free two-minute assessment at aiassessment.thegnar.com. It tells you exactly where you stand. Link is in the show notes. See you in the Gnar.

‍