The first 2,000 GitHub stars with Matija Šošić from Wasp
Wasp's original pitch was "we built a whole new programming language" — and it scared people off immediately. Matija Šošić's team hadn't changed a single line of how the product worked when they repositioned it as "a super simple config layer on top of the React and Node you already know." That was the whole fix.
Matija Šošić is co-founder of Wasp, a configuration language for building full-stack React and Node.js web applications, built with his brother Martin.
We get into why building something as fundamental as a new language made incremental validation nearly impossible, how a batch of problem interviews — not solution pitches — shaped the product roadmap before a line of code shipped, and the milestone system the brothers used to survive the psychological grind of not giving up.
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.
What does Wasp actually do?
Wasp is a simple configuration language for building full-stack web applications with React and Node.js, which is what we support today. Developers describe high-level, general concerns — auth, CRUD, API data models, cron jobs — declaratively in Wasp's own language, and write the rest of their actual business logic in ordinary React and Node.js. We're trying to simplify both getting started and maintaining a full-stack application over time.
How did the idea for Wasp actually come about?
My brother Martin and I always thought of ourselves as general software engineers — algorithms, machine learning, app development, never specifically web development. But no matter what we built, we always needed some kind of web app to actually deliver the solution to users, and web development was consistently the hardest, most frustrating part of any project. We kept having to relearn an entire tech stack every couple of years — PHP and Java, then Backbone and jQuery, then Angular, then finally React and Node — just to rebuild the same common pieces over and over. The real trigger was working at a company in London building a fairly complex biometrics analysis platform across AWS, Azure, and Google Cloud. We started tinkering with the idea while still employed there, eventually went full-time on it, expecting to spend a couple of months — that turned into a full year before we got into Y Combinator on our third attempt.
Building something as fundamental as a new language makes incremental validation really hard. How did you deal with that?
Most frameworks start life as libraries — you build a small piece, plug it in, try it, and iterate incrementally, which is a great validation loop. We didn't want to build another library or runtime; we wanted our own language, which meant building something from scratch that you genuinely can't test in small increments or get someone using in production immediately. That's a real structural challenge, and it's part of why we knew we'd eventually need to raise funding — this wasn't going to be self-sustaining until the core technology, the language itself, actually existed.
Without incremental validation, how did you stay motivated day to day?
Honestly, the hardest part isn't the idea or even the work itself — it's not giving up. Every day you have to ask yourself why you're doing this when you're still so far from anything resembling an alpha or beta that someone could use. Our first real move was just a landing page describing the idea honestly: you keep using React and Node, we're not asking you to abandon your stack, we're trying to radically simplify the developer experience around it. It was far less polished than what exists now, but it was a starting point — the actual GitHub repo existed, but you had to compile Haskell source code by hand with no real instructions to try it, so the real goal was just getting the idea in front of people and gathering initial reactions.
What was that early feedback actually like?
We posted on Reddit across several communities — React, JavaScript, programming languages — and got picked up on Hacker News too. Reactions were mixed: some people were genuinely excited but skeptical about feasibility, some were curious to watch it develop, and some were flatly dismissive — one person specifically told us we were cheaters, that this was vaporware because there was nothing real to try. But it was clear some people were genuinely excited by the idea itself, even amid the skepticism.
How did you decide whether that mixed, skeptical feedback meant you should keep going?
It came down to a mix of things. We were both already senior developers with experience building complex applications, including at companies like Google, so we knew theoretically that what we were attempting made sense, even without being certain how far we'd actually get. The feedback itself was less a go/no-go signal and more genuinely motivating — seeing people engage with and actually grasp the idea the way we described it. What we learned early wasn't really about the underlying idea changing, but about learning to communicate it far better than we initially did.
How did the way you described Wasp actually change over time?
Initially we were genuinely excited about building a brand-new programming language — we love compilers, we built ours in Haskell, and we were proud that the vision was tech-agnostic, potentially supporting Vue or Go down the line. But saying 'we built a new programming language' scares people immediately, and we hadn't even mentioned upfront that you could keep using React and Node. Naturally, people got skeptical: why would they learn an entirely new language when they already knew JavaScript? Once we recognized that, we flipped the narrative entirely — Wasp became 'a super simple configuration layer, and you still write mostly React and Node code,' framed almost like a web framework rather than a language. Functionally, nothing about the product changed at all — the code stayed exactly the same. People just started reacting to it completely differently.
Before writing a single line of code, you did structured 'problem interviews.' What does that actually mean, and how is it different from a normal user interview?
The natural instinct is a solution interview — 'here's what I built, what do you think, would you pay for it?' — which is actually the wrong order if you're following customer development or lean startup methodology. A problem interview instead starts by asking someone, unprompted, what their biggest challenge is in web development or starting a new full-stack app, and lets them tell you what comes to mind first, without leading them. If the problem you want to solve comes up naturally without prompting, that's a strong signal. If it never comes up at all, that's a red flag that it might not be as important a problem as you think. We ran a batch of these interviews before writing anything, and clustered the answers into themes — things like the pain of relearning best practices for connecting React to GraphQL and Redux each time, or being overwhelmed by 'magic' and unclear state management choices — which directly informed both what we built first and how we described it on the landing page.
Who did you actually interview — was it a broad mix of developers, or something more targeted?
A real range: people at startups building their own products, people at web development agencies building for others, and even a couple of non-technical product or brand managers who experienced developer pain secondhand through their teams and could describe what developers around them struggled with most. Some were front-end focused, some back-end, some full-stack, across both startups and larger companies and agencies.
Have you noticed distinct groups of people who get excited about Wasp for different reasons?
Yes, and I think it's a mistake to assume the people excited about your product right now are the only audience you'll ever have — that changes as the product matures. Right now, in alpha and early beta, one big group is developers on the more junior side, sometimes fresh out of a bootcamp, or more front-end-leaning developers, who are genuinely excited just to get a full working React and Node app running with best practices baked in, deployed to something like Heroku or Fly, without having to hand-roll CRUD APIs or wire up their own data layer. The second group is more senior developers — people from companies like eBay, Airbnb, Lyft, and Facebook, some of whom became angel investors after seeing Wasp in action. They're less focused on today's alpha and more interested in the longer-term vision — using something like Wasp to help junior engineers on their teams move faster and avoid common mistakes, and eventually as a standardized, stack-agnostic way of building typical business web apps across React, Vue, and beyond.
How have you actually reached those early users, given it's just the two of you?
Almost entirely through public launches — Hacker News, Product Hunt, and especially Reddit, which was surprisingly our strongest early channel; a handful of subreddit posts brought in 200-300 upvotes and a lot of genuine engagement, even before we joined YC. We simply didn't have the resources for more extensive marketing with just two of us, so we leaned entirely into these external launch moments rather than sustained content or paid channels. Our Discord has become more important since, now that there's a real community to answer questions in, but early on it was almost entirely launch-driven.
Is there something specific you think made those Reddit and Hacker News posts land well?
Honestly, I'm not fully sure — we tried different approaches and some worked better than others. My brother always framed posts as 'my brother and I built...' rather than describing it as just another framework someone was pushing. I think that personal touch mattered — it read as two people genuinely trying to build something themselves, asking for help, rather than a faceless company promoting its own product. We used the same approach on Hacker News, telling our actual origin story in the first comment, which is a pretty typical YC-style format — here's the problem we personally ran into, here's what we're building because of it.
If a friend came to you building a different developer tool and asked for advice, what would you tell them?
The biggest thing is convincing yourself not to give up, and having an actual system for doing that rather than relitigating the decision fresh every single day. If you don't have a system, you spend all your willpower each morning just deciding whether to keep going at all, and end up getting almost nothing done. My brother and I set concrete milestones instead — something like, we'll work toward this specific outcome over the next three months, and if it gets no traction and no meaningful feedback, we'll know something's genuinely not working. That structure meant we weren't relitigating the whole decision daily, just focused on executing toward the next checkpoint. On top of that structure, genuine personal curiosity matters enormously — if you're only doing something opportunistically, chasing whatever's trendy at the moment, the first real setback will kill your motivation. We had countless moments that felt like clear failure, but staying genuinely curious about 'what if we tried this instead' is what got us through the long stretch where nobody, including ourselves some days, fully believed in it yet.