Forem: Matija Sosic

🎨 Join Wasp Design-AI-Thon - Pimp our website and win TRMNL, Playdate, and OB-4! 🤖

Matija Sosic — Mon, 13 Oct 2025 13:39:38 +0000

As promised at the start of this Launch Week, we're bringing our hackathon back! And this time, it's a bit special - we're asking you to give a revamp to Wasp's website! Our design is kinda dated and looks like it was done by a backend engineer (looking at myself), and we think it's about time we did something about it!

We want to come up with something fun and not what you see every day, which reflects our style and personality.

The only rule is: there are no rules!

Key things to know

You have 10 days to create a redesigned mock-up of Wasp's website
- Starting 10:00 am PT Friday, Oct 10th, 2025
- The submission deadline is 11:59 pm Sunday, midnight PT, Oct 19th, 2025
Use any tool or format - code, Figma design, drawing. Anything.
You're welcome to adapt the copy on the website. If you have an idea for a tagline you think would work better (e.g., "Laravel for JS"), we'd love to see it!

You can find Wasp's existing website code and use it as a starting point here.

FAQ

Here are answers to some questions you might have. If there is something we haven't covered, ping us on Discord!

What should I create? What level of fidelity should it be?

We leave this part up to you. Whatever you think might be a good way to represent your idea on how to upgrade Wasp's page design and/or branding. It could be a page you actually coded and deployed, a Figma/Illustrator design, a drawing or a video in which you present your vision.

Maybe even a poem. Ok, probably not, but would be interesting to see someone give it a try.

To get your juices flowing, here's an example we played around with internally :

How much of the website should I mock up?

You can go as far as you want. As a minimum, we recommend focusing on the Above-The-Fold aka Hero section of the page. That is the portion of the page you see on your screen when it loads for the first time, before you scroll down.

Which tools should I use? Can I use AI?

Of course! As the title says, it's a design-AI-thon. We believe that AI has made better design more accessible to anyone (even backend engineers, although that's a tough one) and would love to see it in action!

You're of course also free to go old-school and do it Figma/Sketch/Photoshop/Illustrator or any other design tool out there.

Prizes

There are 3 categories, and there will be prizes for:

Best overall project
Most fun / innovative
Most technically impressive

For the prizes themselves, we'll give away three beautifully designed pieces of hardware. We think that is just right for the theme of this competition, and will inspire you to channel your inner Jony Ive or Dieter Rams.

Prize #1: OB-4 Bluetooth Loudspeaker by teenage engineering
Prize #2: TRMNL - E-ink companion for your desk
Prize #3: Playdate - A tiny handheld game system. With The Crank.

Special thanks go to folks at TRMNL for offering to sponsor this event by gifting a device! Seems like me tweeting a lot of stuff eventually pays off!

A lil' disclaimer: If for some reason we can't get our hands on one of the prizes, or can't ship it to your location, we'll swap it out for something just as cool (promise!).

Submission

You should submit your project using the submission form before 11:59 pm PT, Sunday, October 19th, 2025.

Judging

The Wasp team will judge the winners for each category. We will be looking for:

Creativity & thinking out of the box

How well it showcases Wasp’s playful personality
Visually pleasing
Attention to detail
Fun!

Rules

Multiple submissions are allowed. You can do as many as you want.
You must submit before the deadline (no late entries)

Additional info

By making a submission, you grant Wasp permission to use screenshots, code snippets, and/or links to your project on our Twitter, blog, website, email updated, and in the Wasp discord server.

That's - it have fun. Find your inner artist, pair it with AI and let the sparks fly. We can't wait to see what you come up with!

🐝 Wasp: a full-stack, "Laravel for JS" framework. Vibe-coding approved 🕹️

Matija Sosic — Wed, 23 Apr 2025 12:57:21 +0000

What is Laravel, and why do I need it for JavaScript?

Laravel is one of the most popular web frameworks for PHP. It was released in 2011 and has since become a synonym for a well-designed, enjoyable developer experience. Its "superpower" is that it provides pretty much everything you need with the best practices out of the box. Authentication, ORM, emails, jobs, testing - there is a "Laravel" way to do it, and there's nothing for you to figure out - it all just works!

On the other hand, the JavaScript ecosystem is on the drastically opposite spectrum. There is a standalone library/service for pretty much every web app feature, and it's up to you to figure out the best way to integrate it all together.

It can be fun to hand-select every part of your stack, but it can also be quite frustrating when you have an idea and want to get it out to users as soon as possible.

This is why developers who used all-in-one full-stack frameworks such as Laravel, Rails, and Django have been very strongly calling for the same experience in JavaScript.

There are historical and maturity reasons why we didn't have that in JavaScript for so long, but finally, the times are changing.

There are multiple solutions and frameworks that aim to solve this problem, and today we'll take a look at one of the fastest-growing among them: Wasp! 🐝

Wasp: A full-stack, “Laravel for JS” framework. Great for vibe-coders, too!

Wasp is one of the fastest-growing next-gen full-stack web frameworks and is leading the pack when it comes to pushing for a Laravel-like experience in JavaScript. It appeared at about the same time as Redwood and was motivated by the same pain (too fragmented and modular JS ecosystem). Wasp is currently in Beta (recently went through its Launch Week #9) but is already being used by solopreneurs, startups, and Fortune 500 companies.

The main “secret sauce” is a declarative specification file where a developer describes their app at a high level - pages and routes, async jobs, database operations, and more. It helps cut down a lot of boilerplate and lets a developer focus on their unique logic in React, Node.js, and Prisma.

Support us! 🙏⭐️

If you find this post helpful,consider giving us a star on Github! Everything we do at Wasp is open source, and your support helps us make web development easier and motivates us to write more articles like this one.

⭐️ Thanks For Your Support 🙏

OpenSaaS - a free, open-source boilerplate starter for React & Node.js

Finally, one of the big drivers for developers choosing Wasp for their projects is OpenSaaS - a 100% free and open-source SaaS boilerplate starter on top of Wasp. It comes with a lot of common features out-of-the-box (Stripe & OpenAI integration, blog via Astro, admin dashboard, file uploads, …) and will save you hundreds of development hours. Since its release about a year ago, it has skyrocketed toover 10,000 stars on GitHub, and has been used to bring hundreds of SaaSes to life.

Wasp helps vibe coders build their apps further and safer 🕹️

Recently, Wasp has been gaining a lot of popularity among so-called “vibe coders”, which is just a trendy term for people who want to build their app as fast as possible using AI. It turns out that a Wasp app’s robust structure that spans the whole stack of your app (client, server, database, and deployment) and less boilerplate code helps AI develop more features and make fewer mistakes along the way.

Here you can find a detailed video guide that explains the whole process, step-by-step, on how to build your next app with Wasp and Cursor, and then also deploy it to production.

Happy building and stay safe!

Hopefully, this post gave you an insight into the latest developments of the JavaScript ecosystem and prompted (pun intended) you to start working on your next idea, be it with Wasp or another framework that fits your needs the best.

Also, whether you adopt less or more AI in your development workflow, make sure to check and understand your app’s code before putting it into production. Although full-stack frameworks such as Wasp can help with ensuring best practices out of the box, it’s still your responsibility as a developer to make sure that the code that goes out meets all the security standards.

With that said, happy coding! If you want to support our mission with Wasp, we’d appreciate it if you starred it on GitHub. We’d also love to hear from you, and we’re here if you have any questions about Wasp or web dev in general - you can always find us in our Discord.

From “You will fail” to 15,000 GitHub stars: The story of Wasp, a "Laravel for JS" full-stack framework

Matija Sosic — Wed, 05 Mar 2025 13:03:40 +0000

"What you're building is the holy grail for developers. No one has succeeded so far." 🏆 ☠️

This is the feedback from Y Combinator when Martin (my twin brother) and I applied with Wasp for the second time in May 2020. At that point, we had worked on Wasp for 1.5 years, the last nine months full-time. We had quit our previous jobs and gone all in.

Today, Wasp has over 15,000 stars on GitHub. Even more importantly, developers of all backgrounds have used it to develop thousands of web apps, from side projects that have grown into acquired or revenue-generating businesses to venture-backed startups and internal tools deployed within Fortune 500 companies.

Some people have grown to love Wasp and the vision it pursues. Thanks to them, we enjoy working on it. Without the community that gathered around Wasp (>4,000 devs in our Discord), we wouldn’t have been even close to where we are today. For them, we keep pushing towards the holy grail we promised.

Our work has just begun - but we’re more excited about it than ever.

The journey - getting from 0 to 15,000 stars

As with most success stories, the success rarely happens linearly. It usually starts with a long period of "drought" with occasional signs of life, and then there is a moment when things click together and start moving really fast. We experienced the same, and it looked something like this:

The inception - “Why not?”

In the beginning, Wasp was just an idea—or rather, a question: "Why hasn't anyone built this yet? What would we discover if we tried?" After spending a decade building web apps and using every major tech stack (from PHP to Java and Node.js on the server to Backbone, Angular, and React on the client), we were feeling the pain of "framework fatigue," aka reinventing the wheel with each new stack.

So we set out to start thinking about it and put things on paper (ok, Google Slides). This is how the original idea for Wasp was born - can we create a framework that removes a lot of boilerplate by offering higher-level abstractions, but is still flexible enough and is not strictly bound to the specific stack and architecture?

Now looking that, it really does sound like a holy grail.

Getting in YC and things getting real

We had already quit our jobs a year ago and were quite exhausted and doubtful of the whole concept. We were getting some early traction and received promising feedback from Reddit, Hacker News, and Product Hunt, but we also started realizing how much work is needed to bring a full-stack web framework to a state where it’s usable, especially with the ambitious requirements we set for ourselves.

Finally, we got into YC the third time we applied for it. They were following our progress for the last year and, having seen the community excitement, decided to take a bet on our crazy idea.

Beta and beyond - MAGE and OpenSaaS

Looking at the graph, you can spot two key inflection points. The first one happened in July 2023 when we launched MAGE, a GPT SaaS starter that uses Wasp under the hood (you can think of it as one-shot Loveable/Bolt). It was among the first LLM products that could generate a working full-stack web app, bringing many eyes to Wasp.

The second major growth catalyzer came in December 2023 with the launch of OpenSaaS, our open-source SaaS starter built on top of Wasp, which now has almost 10,000 stars on GitHub.

We realized that most builders really want to start working on their idea as quickly as possible without picking out and patching together all the different features every SaaS needs - authentication, payments, admin dashboard, sending emails, blog, …

And this is exactly what we provided - a 100% free & open-source, high-quality, SaaS starter based on React, Node.js, Prisma, and Wasp. OpenSaaS basically became a “killer app” for Wasp as it attracts developers to try it and realize how helpful the framework is.

Open SaaS also pairs extremely well with Cursor - given Wasp’s robust structure and higher-level primitives, many developers have found it as an ideal combo for getting their SaaS-es from an idea to a production-ready app in a matter of days.

// Detect dark theme var iframe = document.getElementById('tweet-1832194642596508076-687'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1832194642596508076&theme=dark" }

Language/DSL vs framework - so which one is it?

As you can see from the examples above, we used to refer to Wasp as a language, DSL - a Domain Specific Language. It was for these reasons that we originally set out to have an abstraction layer that can, in the future, work with any language, library, and architecture.

For this, we needed to introduce our own compiler that would first analyze your app’s specification that you defined via Wasp (e.g., your routes, async jobs, db operations, …), combine it with the “native” code you wrote in React & Node.js, and finally generate a React/Node.js app. That effectively meant we’ve invented our own language, albeit very limited and simple.

This is how we initially presented Wasp, but we learned that is the wrong way to think about it. Wasp is by its function a web framework, just like Laravel, Rails, or Next.js. The fact that it uses a compiler under the hood is simply an implementation detail that gives it its superpowers. For example, thanks to this approach, we can easily visualize the topology of your whole app, from database to server and client components:

The road to 1.0 and building the next-gen framework

This is the story of how Wasp came to be where it is today. For more details on the very early days (getting from an idea to the first 1,000 stars), you can check out this post.

What’s next? After almost five years of building and getting feedback from you, we have a pretty clear picture of what Wasp 1.0 needs to look like. Simply put, we have set out to build a full-stack framework with the best possible developer experience. We want you to focus on building your product and spend as little time as possible fighting your stack.

Think what Rails and Laravel did for Ruby and PHP - we’re doing the same for the modern, AI-powered, JS ecosystem.

To follow our story and support us, star Wasp on GitHub and join our Discord - we can’t wait to see you there!

🚨GIVEAWAY🚨 - Help us reach 15,000 stars and win our Ultimate Swag Pack! 🐝 👕

Matija Sosic — Tue, 11 Feb 2025 12:49:47 +0000

Hey DEVelopers 👋,

It feels like it was yesterday when we published a post here about Wasp, an open-source web framework for React, Node.js and Prisma, reaching 9,000 stars on GitHub!

Today, we're just 50 stars away from hitting 15,000 stars on GitHub!

To celebrate, we're offering a very special treat for three lucky devs that star our repo before we hit 15k stars - our Ultimate Swag Pack! That includes:

🌑 Dark tee for the code ninja in you
🌔 Light tee for when it gets hot outside
🎩 Beanie to stand out in a crowd
🐝 Wasp plushie to help you out in debugging sessions!

Sounds like a sweet deal, right? Here's what you need to do to win:

Like this post ❤️
Star Wasp on GitHub ⭐: https://github.com/wasp-lang/wasp
Reply with your GitHub handle 💬 (so we can id you)

We will announce the winners once we hit 15k stars! (so very soon)

That's it! Happy starring and we can't wait to ship the Ultimate Swag Pack your way! 🐝✈️

Watch this. It will be awesome 🔥

Matija Sosic — Thu, 16 Jan 2025 18:41:06 +0000

Can I build & market a SaaS app to $100 in 1 month?

vincanger for Wasp ・ Jan 15

#webdev #saas #marketing #ai

Should You Use an Open-source SaaS Boilerplate Starter or a $300+ Paid One?

Matija Sosic — Wed, 11 Dec 2024 13:18:43 +0000

SaaS boilerplate starters became a very popular thing in the web dev community, and also a pathway to a luxury lifestyle for those behind them, sometimes making north of five figure amounts per month.

On the other hand, there's also been a rise of the open-source SaaS boilerplate starters, that cover various stacks and offer similar features as their paid counterparts, but completely for free and with an active community alongside.

So, what's the catch? Why pay $300 or $500 for something that you can simply get for free? Are there any trade-offs you should be aware of, and what are the pros and cons of each option?

As it usually turns out in the real world, the answer isn't completely black and white and depends on what you need (your requirements) but also what you want (your personal preferences).

The goal of this article is to break these further down and give you an objective, simple framework to follow when choosing a boilerplate starter for your next project. So, let's get into it!

Why a sudden craze with all these starters? SaaS-es are not a new thing at all

We have all been building web apps and SaaS-es for decades, you may rightfully observe, so why this became a thing just now? It seems like everybody is making their own starter today and getting a ton of excitement (and money) from the community.

The answer is that the complexity of building a SaaS (or in another words, a web app) in the last ten years increased tenfold. Partly it is due to the evolution of the underlying architecture (we switched from monolithic, server-based approach to “rich client ↔ backend”) which introduced more moving parts into the equation, and partly due to the explosion of options for each part of the stack.

If you were about to build a SaaS fifteen years ago, you pretty much knew you'd go with either Ruby on Rails, Laravel, or Django, depending on which language and community you preferred. These would come as a batteries-included solution, give you their best defaults and you'd be up and running in a matter of hour(s). You got a single, well-tested path to follow and not much decisions to make.

If you sit down and try to do the same today, your head would probably get dizzy after a few hour(s) of merely reading about all the possible options you could go with:

What to use for the frontend? Something mainstream as React, Vue or Angular, or something more sexy and bleeding edge like Svelte or Solid?
Should I use a React framework e.g. Next or Remix? Or just go with React + Vite?
Do I need SSR and SSG? Or should I just stick with CSR?
What should I use as an API layer? Good ol' REST, or maybe GraphQL, or maybe even typesafe RPC?
What to choose for the backend? Do I use something lightweight like Express.js with Node/Bun/Deno or a full-blown solution such as Nest.js/Django/Rails? Or maybe finally try Phoenix/Livewire combo everybody has been talking about? Do I go serverless or not?
What about the database and ORM? Relational or non-relational? Should I write raw queries or use a full-blown ORM such as Drizzle and Prisma? If yes, which one?
What are my hosting options? Am I going to get locked in with a single provider? What if I want/need to host my app somewhere else?

These are just some of the questions you need to start thinking about when deciding how to start your SaaS in 2024. As you can see, it's more then enough to make your head spin and even if you're a seasoned developer and makes you feel like you need to be a rocket scientist to figure out the right combination.

This is why people today turn to SaaS boilerplate starters and gladly even pay for it. It means somebody else did the legwork and (hopefully) made a sensible decision on the stack which will remain current and easy to maintain in the years to come.

Now that we gave some context to the sudden rise of SaaS starters, let's back to the original question - why pay for something when there is an open-source, free version of it? Let's take a look at some of the factors that come to play.

With an open-source SaaS starter, you know exactly what you're getting into

By the definition of open-source, you can see and examine the full code of the starter in advance, before committing to using it for your project.

Although it's not likely you will go through every line of code beforehand and try to understand it all (that's why you're looking for a starter in the first place), you can check it out and see how you like it - e.g. the style of the code, readability and how well documented and tested it is.

You can also see the repository's activity stats - number of open and closed issues, features in progress, commit frequency and how fast are things being resolved and new features added.

Paid, closed-source starters, again by definition, offer at best a fraction of these benefits. You can see the value proposition as the author designed it - some hand-picked testimonials, a demo and potentially have a peek at the docs.

With a paid starter, you become a member of an exclusive tribe (aka Air Jordans Effect)

The most popular paid boilerplates today often come from well-known developers, or “indie makers,” who've already built successful products. Buying their boilerplate feels a bit like joining an exclusive club—it's as if you're tapping into their expertise and using the same tools they once used to succeed.

It's like wearing a jersey signed by a famous athlete or a perfume co-created by a pop star. It won't guarantee instant success, but it gives you a sense of connection and inspiration. You're reminded that someone else turned these same tools into something great—and that you could do it too!

In the long run, this mindset might matter even more than the tools themselves. When things get hard, feeling part of that “club” could be what keeps you going, and taking your idea one step further.

Security: in open-source, everyone is a reviewer

Paid boilerplate starters are mostly an effort of a single person. It is the type of project that, past the initial development phase, doesn't require a full-time attention and is more of a seasonal nature (e.g. updating libraries to the latest versions). That makes it a perfect workload for a single person and also makes it much more profitable rather than splitting the margin with the team. If there was a whole team behind, it probably wouldn't cost $500, but rather $2000.

Recently, there was a security incident with one of the popular paid starters that allowed external parties to send unauthorized web hook requests, which caused a lot of ripples in the online community of builders.

It is a good reminder that, while it's important to ship quickly, security isn't something that can be skipped over. And while nobody can guarantee the security of any SaaS starter, be it paid or open-source, the fact is that in open-source projects there are much more people involved in both development and code review. Since the code is freely available, you're also free to review it yourself, use any pen-testing tools on it or ask another expert to check it before committing to it.

With a paid SaaS starter, the bus factor is 1, with open-source you get the full community support!

A paid SaaS starter typically depends on a single maintainer. Since the code is closed source, nobody else has access nor rights to it, and if for any reason the author becomes unable or unwilling to continue working on it, that's the end of the story. No support, updates, nor anybody to turn to with questions.

On the other hand, an open-source boilerplate starter like Open SaaS is a living organism, with a number of contributors behind it. As with any open-source project, there will typically be a smaller core team which does the bulk of the work and steers the project (and that might as well be a single person in the start), but anybody can join at any point, and they will. As the project grows and becomes more used, more and more people will start adding fixes and features they need themselves and take ownership of the specific parts.

Another thing to account for is it takes a long time for SaaS starter business to become more than a side income, and only a fraction of builders will ever come to that point. That means most of boilerplate creators will still have a full-time job or other engagements going on. Which means they will have a limited time for customer support and adding new features.

Open-source SaaS starter === unlimited updates. Closed source? Sometimes.

An another direct benefit of the SaaS starter code being open-source is that you will have an immediate access to all the updates, as soon as they get released. That includes both security patches, version bumps and completely new features.

With closed source, it varies a lot from one starter to another. Some offer updates as an upsell (e.g. basic and pro tier), some offer a limited time updates (e.g. 1-year), and some promise a lifetime of updates.

With a paid SaaS starter, you might need to buy a “license” for every new app

Another thing to be aware of is that, with paid starters, there often might be a limit to the number of apps you are allowed to start with a single starter purchase. It is typically phrased in terms of “licenses”, and if you exceed a limit you're legally required to buy a new one, although you already own the starter code.

Again, this is not the case with all paid starters (some offer unlimited projects with a single purchase), but it is a common pattern worth checking before buying.

With an open-source starter, there naturally isn't any such limit - the full source code is publicly available and you're free to use it in any way you see fit.

With an open-source SaaS starter, you can add new features yourself!

One of the most exciting benefits of the open-source approach is that anybody can contribute! If there is a feature you're missing or want to improve, you can simply do it yourself it and create a pull request. Then, the core maintainers will review it, give advice and point you in the right direction if needed. Once it gets merged, it is available for everyone to use!

Summary

Now that we have gone through the main differences between open-source and paid SaaS starters, let's give it a bird's-eye view:

	Cost	Lifetime updates	Unlimited apps	Maintainers	Community	Air Jordans Effect	Easily contribute
Open-source SaaS starter	$0	YES	YES	Many	Big, public	Rarely	YES
Paid starter	$300+	Depends	Depends	Typically one	Sometimes, private	Often	No

This is a useful list to be aware of when making a decision which route to go, but in the end there is no one answer that will fit all. Your decision will depend on what exactly you're looking to build and which tech stack you prefer using.

Also, the factors above will not be equally weighted by everyone - one person might be excited about being a part of a wider community and being able to easily contribute to the project, while other most appreciate the fact there is a strong online personality they can follow and get inspired.

In the end, the only important thing is to take action and successfully ship that application you've been thinking about for so long. Good luck!

🎉 Our web framework reached 9,000 stars on GitHub! ⭐️ 9️⃣0️⃣0️⃣0️⃣ ⭐️

Matija Sosic — Tue, 05 Mar 2024 14:01:52 +0000

TL;DR - we reached a milestone with a web framework we created, despite all the odds! Check it out (and support us with the star if you like it - thank you! 🙏), and read below to learn about our story and what it took to get here.

As a developer, starting your own web framework is probably one of the scariest things you can do. It is almost certain your project will die, and as the added bonus, other developers will make fun of you along the way, counting all the reasons why it won't work.

How sharing your idea for a new web framework feels like

It's been no different for us. When we started Wasp, everybody asked "Why another web framework? Why would anybody use your tool next to mature, famous frameworks?". These are good questions, I admit, and we didn't have all the answers, not even close. But that was in no way the reason for us not to do it.

Three years ago, when we launched Wasp Alpha

We kept going. We had a vision in our mind and we wanted to see if we can make it a reality. We didn't care at all whether Wasp lives or dies, we just knew that we needed to see it through, and that's all that mattered. In a few months, we released Alpha version and got our first 100 stars. As a result, that brought in even more questions, and we weren't any closer to figuring out if the concept we imagined can really fly or not.

But, we also couldn't believe that somebody actually starred our repo. We were both surprised and motivated. I still clearly remember Martin Šošić asking me "Matija, can you imagine that the project we created gets to 1,000 stars on GitHub?". Both of us immediately shooked our heads and laughed, thinking "yeah, right, like that's gonna happen!".

Our first community update, celebrating 100 stars on GitHub!

9,500 stars and almost 3 years later, here we are today. Wasp is getting close to entering the elite 10,000 stars club on GitHub, next to the giants of the industry. The framework we started, and developed further with the invaluable feedback from the community, is being used by all kinds of developers - from weekend projects, to startups and top enterprises. Startups made with Wasp have been acquired. I just saw a job ad today on Upwork, where a company is hiring for Open SaaS (an open-source, free boilerplate starter for React & Node.js, powered by Wasp) developers 🤯.

Looking back, I still find it hard to believe it. Starting from my brother's girlfriend's (now wife) apartment with pretty much no open-source nor community-building experience, we made it to the product that developers all over the world use daily, and willingly choose to use it over the mainstream, famous frameworks we all know. We are incredibly honored and humbled by this.

We still have an a lot of questions (figured that won't ever go away), but now it's also starting to feel like we got a couple of the answers right.

The feedback we're getting today

Thanks for reading! Find more about Wasp and support us on our journey to reaching 10,000 stars here.

P.S.: If you ever wondered who's really the boss at Wasp, now we've finally made that clear in the photo above. Had to carry the li'l dude all the way to the top just so he could get a nice shot. 🐝

🏞️5 beautiful open-source web apps to learn from and get inspired 🙇‍♀️💡

Matija Sosic — Wed, 17 Jan 2024 13:11:12 +0000

As the title says, in this post, we'll cover open-source web apps you can learn from and use as a starting point for your next project. Stick around till the end, as there is a cool bonus waiting for you there!

Before we get into it, a few words of wisdom (hopefully 😅):

The importance of (open source) role models

When starting a new project from scratch, one of the most helpful things you can do is pick one or more role models. For example, if you’re building a new productivity app, you might look after products such as Trello or Asana. Of course, your app will not be the same, and you probably have in mind some core differences that make your app unique, but there will still be a lot of shared concepts and mechanisms that you don’t want to reinvent.

Even if your role model is a closed-source app, you will still get a lot of value simply by observing it in the wild - design elements, UI, user journey, and terminology used, …

But now imagine if the app you decided to learn from was open source, and you could easily access its full source code on GitHub - that opens a whole new universe of possibilites! Next to simply observing how the app works from the “outside” and guessing what’s happening under the hood, now you get to see every single detail and understand every decision made. Architecture, deployment, API design, libraries, and algorithms used - it’s all in there for you to see!

Mind the scale (aka don’t over-engineer)

Credit: this tweet by Dominus Kelvin

One more thing to keep in mind is the stage at which your project is currently. Below, we’ll see different examples of open-source SaaS apps, ranging from indie hacker, “build it in a weekend” side projects to enterprise-grade web platforms. Although you might find a project with millions of users an amazing resource to learn from, keep in mind that not everything they did is what you have to strictly follow. Their architectural and design decisions will often be more complex due to the sheer scale and amount of users they experience daily. If you are just starting out, it is best to stick with the simplest (but still sound) approach until you, hopefully, need a more advanced one.

From here on, for each app we mention, we’ll use a “t-shirt size” methodology (S, M, L, …) to give you a rough feeling of its size and complexity, both in terms of features and users.

Now, with the foreword out of the way, let’s together check out some amazing open-source apps you can start learning from right away:

CoverLetterGPT - the perfect starting spot for an AI-powered SaaS

💾 Source code: https://github.com/vincanger/coverlettergpt
👕 Size: S
🛠️ Stack: Chakra UI, React, Node.js, and Prisma, powered by Wasp

CoverLetterGPT.xyz is every indie hacker’s dream - it’s a GPT-powered SaaS, fully open-source, and most importantly, it’s a real product that people use every day and also pay for! Given your CV and a job description, this tool will generate a professionally written cover letter. You can then further adjust the tone for each paragraph or edit it manually.

It’s perfect for learning since it isn’t too big and the architecture is simple, but it has all the features you might need in an app - social authentication (Google), cron jobs, file upload, GPT integration, payment integration via Stripe, and even payments via Bitcoin!

CoverLetterGPT is made with React, Node.js, and Prisma, powered by the Wasp framework, which takes care of all the plumbing and removes a ton of boilerplate. The best part is you can deploy your app for free when you’re ready by running a single CLI command: wasp deploy.

🚨 Attention 🚨

Hint: The Wasp team recently released OpenSaaS, a completely free and open-source boilerplate starter for React and Node.js. It contains everything mentioned + Tailwind, admin dashboard, landing page, blog, and more. Check it out here to get started even faster.

⭐️ Star OpenSaaS on GitHub ⭐️

Supabase Studio - a dashboard masterpiece 🖼️

💾 Source code: https://github.com/supabase/supabase/tree/master/apps/studio
👕 Size: M/L
🛠️ Stack: Next.js (React), Tailwind

Supabase is a renowned open-source project with its core written in Elixir. But, since we are focusing on web apps in this article, we’ll take a look at Supabase Studio - a dashboard where you can see and manage all of your projects. It is a masterpiece in itself and also fully open-source!

The design is custom-made with Tailwind, and there are plenty of elements you might want to reuse for your own project - user management, tables, lists, etc. It also has its own AI integration for writing SQL queries, which works surprisingly well.

Papermark - the open-source DocSend alternative ✉️

💾 Source code: https://github.com/mfts/papermark
👕 Size: M
🛠️ Stack: Next.js (React), Tailwind, Prisma

Papermark has recently been getting a lot of love from the community, especially for its clean design and intuitive interface. Although it might look simple from the outside, this app packs a lot of functionalities that make everything work smoothly: file upload, email sending, built-in analytics, and custom domains…

If you’re building something that involves a lot of document management and user collaboration, this is definitely a project you should take a look at.

Crowd.dev - dev community data platform, made with Vue 📊👩‍💻

💾 Source code: https://github.com/CrowdDotDev/crowd.dev
👕 Size: M
🛠️ Stack: Vue, Node.js

Crowd.dev is one of the latest rising stars of GitHub - it is a platform for monitoring your community activity, be it on Slack or Discord. If you are running your own developer community, a tool like this is a must-have in order to understand what’s happening and who the most active members are.

It offers a lot on the dashboard side, but its other forte is integrations - if you are building an app that ingests and processes a lot of data from outside sources, this is your go-to role model. Bonus points if you are a Vue lover because that’s what this project is made with!

Habitica - Habit tracker as an RPG 🐲⚔️

💾 Source code: https://github.com/HabitRPG/habitica
👕 Size: L
🛠️ Stack: Vue, Bootstrap, SAAS, Node.js, MongoDB

Habitica is one of the coolest web apps (they also have iOS and Android apps) I’ve seen in a while - it helps you organize your life, tasks, and habits through the RPG game! Imagine a Kanban board like Trello, but for each task you complete, you earn XP and gold, and you can even team up with friends to take up quests.

Habitica has been around for 10 years, and it has stood the test of time beautifully with a classical stack of Vue, Node.js/Express, and MongoDB. If you want to see how rich, interactive UIs are built but also what kind of architecture is needed to run a project at this scale, this app is definitely worth checking out. Who knows, you might even end up as a Habitican yourself!

🏆 Bonus 🏆 Appflowy - Notion alternative in Rust and Flutter 🤯

💾 Source code: https://github.com/AppFlowy-IO/AppFlowy
👕 Size: M
🛠️ Stack: Flutter, Rust

If you came this far, you deserved a special treat! This one isn’t a web app, but it is so cool I couldn’t help myself - it is a Notion alternative (so note-taking on steroids) built with Rust and Flutter! Due to its local-first nature, the user experience is extremely smooth, and it also syncs everything to the cloud (which you can host yourself if you wish).

If you’ve been playing around with Rust but are also looking for a project to contribute to that you could use daily, Appflowy might be a perfect fit. It has everything from data storage to business logic and UI, all in one package for you to learn and see what you find the most interesting.

That's it! I'd love to hear from you 🫵

That's all we had for today (drops the mic), thanks so much for reading! I hope you found it useful and/or interesting.

There were so many open-source web apps I came across while writing this, and it was so hard to select only 5 of them.

Now, I'd love to hear from you - what are your favorite open-source apps, and how are you using them? Write it below in the comments 👇

Thank you, and see you next time! 👋

🥇The Best Web Framework Doesn't Exist 🚫

Matija Sosic — Wed, 10 Jan 2024 13:23:04 +0000

TLDR; The web app framework you choose doesn’t really matter. Well, it matters, just not as much as others would like you to believe.

The fact that so many libraries and frameworks exist in 2024, and that the best one is still hotly debated, proves my point. It’s the web developers' biggest “first-world problem” — a problem that’s not really a problem. On Maslow’s Hierarchy of Developer Needs, it’s definitely near the top (ok, I made that up 😅)

For example, according to the StateOfJS survey of 2022 (we're still waiting for 2023 results to roll in), there were 5 Front-end Frameworks with good retention in 2018; there were 11 in 2022. That’s a 120% increase in a matter of 4 years, and that’s not even taking into account the hot meta-frameworks like NextJS, Wasp, SvelteKit, or Astro!

These are great developments for the space, overall. They improve things like developer speed, bundle size, performance, and developer experience. But they also make it damn hard for developers and teams to make a decision when trying to decide which to use for their next project. It’s even worse for beginners, which is probably why they just go for React, the most "mainstream" solution.

And I think all of this is OK, because in the end it doesn’t really matter which one you choose. When it really comes down to it, all that matters is the framework you chose:

Is stable (enough)
Allows you to move quickly
Allows you to reach your end goal

Why? Because most of them are built around the same concepts, have proven themselves capable of performing at scale, and have communities you can engage with and learn from.

React might be the most prominent one in job descriptions, but if you’re looking for a new role and only have experience in Vue or Angular, I can’t imagine it would take you more than a week to build a side-project with React to display your ability to prospective employers.

On the flip side, if you’re a beginner or Junior dev, once you have the basics of HTML, CSS, and JS under your belt, it doesn’t really matter what framework you learn. I personally started learning backend development with PHP, but then later switched to frontend in Angular. In my second subsequent role I used React, and now I work with Wasp (a full-stack framework built on top of React and Node.js) to develop my side project, https://reflectdaily.app/. Developers never stop learning, so it’s kind of a non-argument to deride any specific framework — unless it really sucks, but then no one will continue to use it anyway.

So, in the end, use what works. Because in 99.99% of cases, your choice of web framework will not decide the fate of your project.

If you’ve done a bit of research and found a framework that suits your needs and you enjoy using it — use it. There’s really no good reason not to.

Support us! 🙏⭐️

If you liked this article, consider giving us a star on Github! Everything we do at Wasp is open source, and your support helps us make web development easier and motivates us to write more articles like this one.

⭐️ Thank You For Your Support 🙏

AI code generation vs. coding by hand - what programming is going to look like in 202X 🤖 🤔

Matija Sosic — Mon, 11 Dec 2023 14:39:35 +0000

We are working on a full-stack web framework for React & Node.js, that uses a simple configuration language to get rid of boilerplate. A number of times, we've been asked, “Why are you bothering creating a new framework for web app development? Isn’t ChatGPT / LLM X soon going to be generating all the code for developers anyhow?”.

This is our take on the situation and what we believe things will look like in the future.

Why do we need (AI) code generation?

In order to make development faster, we first came up with IDE autocompletion - if you are using React and start typing use, IDE will automatically offer to complete it to useState() or useEffect(). Besides saving keystrokes, maybe even more valuable is being able to see what methods/properties are available to us within a current scope. IDE's awareness of the project structure and code hierarchy also makes refactoring much easier.

Although that was already great, how do we take it to the next level? Traditional IDE support is based on rules written by humans, and if we, for example, wanted to make IDE capable of implementing common functions for us (e.g., fetch X using API Y, or implement quicksort), there would be just too many of them to catalogize and maintain by hand.

If there was only a way for a computer to analyze all the code we’ve written so far and learn by itself how to autocomplete our code and what to do about humanity in general, instead of us doing all the hard work ...

Delicious and moist cake aside, we actually have this working! Thanks to the latest advances in machine learning, IDEs can now do some really cool things, like proposing the full implementation of a function, based on its name and the short comment on top:

This is pretty amazing! The example above is powered by Github Copilot - it’s essentially a neural network trained on a huge amount of publicly available code. I will not get into the technical details of how it works under the hood, but there are plenty of great articles and videos covering the science behind it.

Seeing this, questions arise - what does this mean for the future of programming? Is this just IDE autocompletion on steroids or something more? Do we need to keep bothering with manually writing code, if we can just type in the comments what we want, and that’s it?

Support us! 🙏⭐️

If you wish to express your support for what we are doing, consider giving us a star on Github! Everything we do at Wasp is open source, and your support motivates us and helps us to keep making web app development easier and with less boilerplate.

⭐️ Thanks For Your Support 🙏

The Big Question: Who maintains the code once it’s generated?

When thinking about how ML code generation affects the overall development process, there is one thing to consider that often doesn’t immediately spring to mind when looking at all the impressive examples.

The question is - what happens with the code once it is generated? Who is responsible for it, and who will maintain and refactor it in the future?

Although ML code generation helps with getting the initial code for a specific feature written, it cannot do much beyond that - if that code is to be maintained and changed in the future (and if anyone uses the product, it is), the developer still needs to own and understand it fully. You can again use AI to help you, but in the end, you're the one responsible for it.

Imagine all we had was an assembly language, but code generation worked really well for it, and you could say “implement a function that sorts an array, ascending” and it would produce the required code perfectly. Would that still be something you’d like to return to in the future once you need to change your sort to descending 😅?

Or, to get closer to our daily lives, would it be all the same to you if the generated React code used the old class syntax, or functional components and hooks?

In other words, it means GPT and other LLMs do not reduce the code complexity nor the amount of knowledge required to build features, they just help write the initial code faster and bring the knowledge/examples closer to the code (which is really helpful). If a developer accepts the generated code blindly, they are just creating tech debt and pushing it forward.

Meet the big A - Abstraction 👆

If ChatGPT and the gang cannot solve all our troubles of learning how to code and understanding in detail how, for example, session management via JWTs works, what can?

Abstraction - that’s how programmers have been dealing with code repetition and reducing complexity for decades - by creating libraries, frameworks, and languages. It is how we advanced from vanilla JS and direct DOM manipulation to jQuery and finally to UI libraries such as React and Vue.

Introducing abstractions inevitably means giving up on a certain amount of power and flexibility (e.g., when summing numbers in Python, you don’t get to exactly specify which CPU registers are going to be used for it), but the point is that, if done right, you don’t need nor want such power in the majority of the cases.

What Uncle Ben actually meant: avoiding responsibility is the main benefit of abstraction! (Peter totally missed the point, unfortunately, and became Spiderman instead of learning how to code)

The only way not to be responsible for a piece of code is that it doesn’t exist in the first place.

Because as soon as pixels on the screen change their color it’s something you have to worry about, and that is why the main benefit of all frameworks, languages, etc. is less code == fewer decisions == less responsibility.

The only way to have less code is to make fewer decisions and provide fewer details to the computer on how to do a certain task - ideally, we’d just state what we want, and we wouldn’t even care about how it is done, as long as it’s within the time/memory/cost boundaries we have (so we might need to state those as well).

Let’s take a look at the very common (and everyone’s favorite) feature in the world of web apps - authentication (yaay ☠️ 🔫)! The typical code for it will look something like this:

import jwt from 'jsonwebtoken'
import SecurePassword from 'secure-password'
import util from 'util'

import prisma from '../dbClient.js'
import { handleRejection } from '../utils.js'
import config from '../config.js'

const jwtSign = util.promisify(jwt.sign)
const jwtVerify = util.promisify(jwt.verify)

const JWT_SECRET = config.auth.jwtSecret

export const sign = (id, options) => jwtSign({ id }, JWT_SECRET, options)
export const verify = (token) => jwtVerify(token, JWT_SECRET)

const auth = handleRejection(async (req, res, next) => {
  const authHeader = req.get('Authorization')
  if (!authHeader) {
    return next()
  }

  if (authHeader.startsWith('Bearer ')) {
    const token = authHeader.substring(7, authHeader.length)

    let userIdFromToken
    try {
      userIdFromToken = (await verify(token)).id
    } catch (error) {
      if (['TokenExpiredError', 'JsonWebTokenError', 'NotBeforeError'].includes(error.name)) {
        return res.status(401).send()
      } else {
        throw error
      }
    }

    const user = await prisma.user.findUnique({ where: { id: userIdFromToken } })
    if (!user) {
      return res.status(401).send()
    }

    const { password, ...userView } = user

    req.user = userView
  } else {
    return res.status(401).send()
  }

  next()
})

const SP = new SecurePassword()

export const hashPassword = async (password) => {
  const hashedPwdBuffer = await SP.hash(Buffer.from(password))
  return hashedPwdBuffer.toString("base64")
}

export const verifyPassword = async (hashedPassword, password) => {
  try {
    return await SP.verify(Buffer.from(password), Buffer.from(hashedPassword, "base64"))
  } catch (error) {
    console.error(error)
    return false
  }
}

And this is just a portion of the backend code (and for the username & password method only)! As you can see, we have quite a lot of flexibility here and get to do/specify things like:

choose the implementation method for auth (e.g. session or JWT-based)
choose the exact npm packages we want to use for the token (if going with JWT) and password management
parse the auth header and specify for each value (Authorization, Bearer, …) how to respond
choose the return code (e.g. 401, 403) for each possible outcome
choose how the password is decoded/encoded (base64)

On the one hand, it’s really cool to have that level of control and flexibility in our code, but on the other hand, it’s quite a lot of decisions (== mistakes) to be made, especially for something as common as authentication!

If somebody later asks “so why exactly did you choose secure-password npm package, or why exactly base64 encoding?” it’s something we should probably answer with something else rather than “well, there was that SO post from 2012 that seemed pretty legit, it had almost 50 upvotes. Hmm, can’t find it now, though. Plus, it has ‘secure’ in the name, that sounds good, right?”

Another thing to keep in mind is that we should also track how things change over time, and ensure that after a couple of years, we’re still using the best practices and that the packages are regularly updated.

If we try to apply the principles from above (less code, less detailed instructions, stating what we want instead of how it needs to be done), the code for authentication might look something like this:

auth: {
    userEntity: User,
    externalAuthEntity: SocialLogin,
    methods: {
      usernameAndPassword: {},
      google: {}
    },
    onAuthFailedRedirectTo: "/login",
    onAuthSucceededRedirectTo: "/dashboard"
  }

Based on this, the computer/compiler could take care of all the stuff mentioned above, and then depending on the level of abstraction, provide some sort of interface (e.g. form components, or functions) to “hook” in with our own e.g. React/Node.js code (btw this is how it actually works in Wasp).

We don’t need to care what exact packages or encryption methods are used beneath the hood - it is the responsibility we trust with the authors and maintainers of the abstraction layer, just like we trust that Python knows the best how to sum two numbers on the assembly level and that it is kept in sync with the latest advancements in the field. The same happens when we rely on the built-in data structures or count on the garbage collector to manage our program’s memory well.

But my beautiful generated codez 😿💻! What happens with it then?

Don’t worry, it’s all still here and you can generate all the code you wish! The main point to understand here is that AI code generation and framework/language development complement rather than replace each other and are here to stay, which is ultimately a huge win for the developer community - they will keep making our lives easier and allow us to do more fun stuff (instead of implementing auth or CRUD API for the n-th time)!

I see the evolution here as a cycle (or an upward spiral in fact, but that’s beyond my drawing capabilities):

language/framework: exists, is mainstream, and a lot of people use it
patterns start emerging (e.g. implementing auth, or making an API call) → AI learns them, offers via autocomplete
some of those patterns mature and become stable → candidates for abstraction
new, more abstract, language/framework emerges
back to step 1.

It’s the circle of (language) life, and it moves us all - Ingonyama nengw' enamabala, …

Conclusion

This means we are winning on both sides - when the language is mainstream we can benefit from AI-powered code generation, helping us write the code faster. On the other hand, when the patterns of code we don’t want to repeat/deal with emerge and become stable we get a whole new language or framework that allows us to write even less code and care about fewer implementation details!

Thanks for reading and hope you found this post informative! I'd love to hear if you agree with this (or not), and how you see the future of programming powered with the AI tools.

Develop the right thing every time and become a 10x engineer 🏆: The art of writing RFCs 🥋

Matija Sosic — Tue, 05 Dec 2023 13:11:40 +0000

Imagine you’ve been tasked to implement a crucial new feature in the product you’re working on. That’s the opportunity you’ve been waiting for - everybody will see what a 10x developer you are! You open a list of the coolest new libraries and design patterns you’ve wanted to try out and get right into it, full “basement” mode. One week later, you victoriously emerge and present your perfect pull request!

But then, the senior dev in a team immediately rejects it - “Too complex, you should have simply used library X and reused Y.”. What!? Obviously, they don’t get how genius your solution is, and soon, you’re looking at 100 comments on your PR and days of refactoring to follow.

If only there were a way to know about X and Y before you implemented everything. Well, it is, and it’s called RFC!

We’ll learn about it on the example of RFC about implementing authentication in Wasp. Wasp is a full-stack framework built on top of React, Node.js, and Prisma that offers a ton of features out of the box and is the fastest way to build and deploy your app. It also comes with a free GPT-powered codebase generator, MAGE, that has been used to create over 30,000 applications.

Let’s dive in!

Support us! 🙏⭐️

If you find this post helpful, consider giving us a star on Github! Everything we do at Wasp is open source, and your support helps us make web development easier and motivates us to write more articles like this one.

⭐️ Thanks For Your Support 🙏

So, what is an RFC?

RFC stands for Request For Comments, and simply means “a document proposing a codebase change to solve a specific problem.”. Its main purpose is to find the best way to solve a problem before the implementation starts. RFCs were first adopted by the open-source community, but today, they are used in almost any type of developer organization.

There are other names for this type of document you might encounter in the industry, like TDD (Technical Design Document) or SDD (Software Design Document). Some people argue over the distinction between them, but we won’t.

Fun fact: RFCs were invented by IETF (Internet Engineering Task Force), the engineering organization behind some of the most important internet standards and protocols we use today! Not too shabby, right?

When should I write RFC, and when can I skip it?

So, why bother writing about what you will eventually code, instead of saving time and simply doing it? If you’re dealing with a bug or a relatively simple feature, where it’s very clear what you must do and doesn’t affect project structure, then there’s no need for an RFC - fire up that IDE and get cracking!

But, if you are introducing a completely new concept (e.g., introducing a role-based permission system) or altering the project’s architecture (e.g., adding support for running background jobs), then you might want to take a step back before typing git checkout -b my-new-feature and diving into that sweet coding zone.

All the above being said, sometimes it's not easy to figure out if you should write that RFC or not. Maybe it’s a more prominent feature, but you’ve done something similar before, and you’ve already mapped everything out in your head and pretty much have no questions. To help with that, here’s a simple heuristic I like to use: Is there more than one obvious way to implement this feature? Is there a new library/service we have to pick? If the answer to both of these is “No", you probably don’t need an RFC. Otherwise, there’s a discussion to be had, and RFC is the way to do it.

What’s in it for me?

We’ve established how to decide when to write an RFC, but here is also why you should do it:

You will organize your thoughts and get clarity. If you’ve decided to write an RFC, that means you’re dealing with a non-trivial, open-ended problem. Writing things down will help distill your thoughts and have an objective look at them.
You will learn more than if you just jumped into coding. You will give yourself space to explore different approaches and oftentimes discover something you haven’t even thought of initially.
You will crowdsource your team’s knowledge. By asking your team for feedback (hence Request For Comments), you will get a complete picture of the problem you’re solving and fill in any remaining gaps.
You will advance your team’s understanding of the codebase. By collaborating on your RFC, everybody on the team will understand what you’re doing and how you eventually did it. That means next time somebody has to touch that part of the code, they will need to ask you much less questions (=== more uninterrupted coding time!).
PR reviews will go much smoother. Remember that situation from the beginning of this article, when your PR got rejected as "too complex"? That’s because the reviewer is missing the context, and you made a sizeable change without a previous buy-in from the rest of the team. By writing an RFC first, you’ll never encounter this type of situation again.
Your documentation is already 50% done! To be clear, RFC is not the final documentation, and you cannot simply point to it, but you can likely reuse a lot - images, diagrams, paragraphs, etc.

Wow, this sounds so good that I want to come up with a new feature right now just so I can write an RFC for it! Joke aside, going through with the RFC first makes the coding part much more enjoyable - you know exactly what you need to do, and you don’t need to question your approach and how it will be received once you create that PR.

Ok, ok, I’m sold! So, how do I go about writing one?

Glad you asked! Many different formats are being used, more or less formal, but I prefer to keep it simple. RFCs that we write at Wasp don’t follow a strict format, but there are some common parts:

Metadata - Title, date, reviewers, etc…
Problem/Goal - what are you going to solve
Proposed solution (or more of them)
Implementation overview
Remarks / open questions

That’s pretty much the gist of it! Each of these can be further broken down and refined, but this is the basic outline you can start with.

Let’s now go over each of these and see what they look like in practice, on our Authentication in Wasp example.

Metadata ⌗

This one is pretty self-explanatory - you will probably want to track some basic info about your RFCs - status, date of creation, etc.

Some templates also explicitly list the reviewers and the status of their “approval” of the RFC - we don’t have it since we’re a small team where communication happens fast, but it can be handy for larger teams where not everybody knows everybody, and you want to have a bit more of a process in place (e.g., when mentoring junior developers).

The problem 🤔

This is where things get interesting. The better you define the problem or the goal/feature you need to implement, and why you need to do it, the easier all the following steps will be. So this is something worth investing in even before you start writing your RFC - make sure you talk to all the involved parties (e.g., product owner, other developers, and even users) to refine your understanding of the issue you’re about to tackle.

By doing this, you will also very likely get first hints and pointers on the possible solutions, and develop a rough sense of the problem space you’re in.

Here are a few tips from the example above:

Start with a high-level summary - that way, readers can quickly decide if this is relevant to them or not and whether they should keep reading.
Provide some context - Explain a bit about the current state of the world, as it is right now. This can be a single sentence or a whole chapter, depending on the intended audience.
Clearly state the problem/goal - explain why there is a problem and connect it with the user’s/company’s pain, so that motivation is clear.
Provide extra details if possible - diagrams, code examples, … → anything that can help the reader get faster to that “aha” moment. Extra points for using collapsible sections, so the central part of the RFC remains of digestible length.

If you did all this, you’re already well on your way to the excellent RFC! Since defining the problem well is essential, don’t be afraid to add more to it and break things down further.

Non-goals 🛑

This is the sub-section of the "Problem" that can sometimes be super valuable. Writing what we don't want or will not be doing in this codebase change can help set the expectations and better define its scope.

For example, if we are working on adding a role-based authentication system to our app, people might assume that we will also build some sort of an admin panel for it to manage users and add/remove roles. By explicitly stating it won't be done (and briefly explaining why - not needed, it would take too long, ...), reviewers will get a better understanding of what your goal is and you will skip unnecessary discussion.

Solution & Implementation 🛠️

Once we know what we want to do, we have to figure out the best way of doing it! You might have already hinted at the possible solution in the Problem section, but now is the moment to dive deeper - research different approaches, evaluate their pros and cons, and sketch how they could fit into the existing system.

This section is probably the most free-form of all - since it highly depends on the nature of what you are doing, it doesn’t make sense to impose many restrictions here. You may want to stay at the higher level of, e.g., system architecture, or you may need to dive deep into the code and start writing parts of the code you will need. Due to that, I don’t have an exact format for you to follow, but rather a set of guidelines:

Write pseudocode

The purpose of RFC is to convey ideas and principles, not production-grade code that compiles and covers all the edge cases. Feel free to invent/imagine/sketch whatever you need (e.g., imagine you already have a function that sends an email and just use it, even if you don’t), and don’t encumber yourself or the reader with the implementation details (unless that’s exactly what the RFC is about).

It’s better to start at the higher level, and then go deeper when you realize you need it or if one of the reviewers suggests it.

Find out how are others doing it

How you find this out may differ depending on the type of product you’re developing, but there is almost always a way to do it. If you’re developing an open-source tool like Wasp you can simply check out other popular solutions (that are also open-source) and learn how they did it. If you’re working on a SaaS and need to figure out whether to use cookies or JWTs for the authentication, you likely have some friends who have done it before, and you can ask them. Lastly, simply Google/GPT it.

Why is this so helpful? The reason is that it gives you (and the reviewers) confidence in your solution. If somebody else did it successfully this way, it might be a promising direction. It also might help you discover approaches you haven’t thought of before, or serve as a basis on top of which you can build. Of course, never take anything for granted and take into account the specific needs of your situation, but definitely make use of the knowledge and expertise of others.

Leave things unfinished & keep it dirty

The main point of RFC is the “C” part, so collaboration (yes, I know it actually stands for "comments"). It’s not a test where you have to get the perfect score and have no questions asked - if that happens, you probably shouldn’t have written the RFC in the first place.

Solving a problem is team effort, and you’re just the person taking the first stab at it and pushing things forward. Your task is to lay as much groundwork as you reasonably can (refine the problem, explore multiple approaches to solving it, identify new subproblems that came to light) so the reviewers can quickly grasp the status and provide efficient feedback, directed where it’s needed the most.

The main job of your RFC is to identify the most important problems and direct the reviewer’s attention to them, not solving them.

The RFC you’re writing should be looked at as a discussion area and a work-in-progress, not a piece of art that has to be perfected before it’s displayed in front of the audience.

Remarks & open questions 🎯

In this final section of the document, you can summarise the main thoughts and highlight the biggest open questions. After going through everything, it can be helpful for the reader to be reminded of where his attention can be most valuable.

Now I know when and how to write an RFC! Do you have any templates I could use as a starting point?

Of course! As mentioned, our format is extremely lightweight, but feel free to take a look at the RFC we used as an example to get inspired. Your company could also already have a ready template they recommend.

Here are a few you can use and/or adapt to your needs:

Squarespace RFC template
Do you have a template you'd recommend? I'm happy to list it here!

What tool should I use to write my RFCs? There are so many choices!

The exact tool you’re using is probably the least important part of RFC-ing, but it still matters since it sets the workflow around it. If your company has already selected a tool, then of course stick with that. If not, here are the most common choices I’ve come across, along with quick comments:

Google Docs - the classic choice. Super easy to comment on any part of the doc, which is the most important feature.
Notion - also great for collaboration, plus offers some markdown components such as collapsibles and tables, which can make your RFC more readable.
Github issues / PRs - this is sometimes used, especially for OSS projects. The drawback is that it is harder to comment on the specific part of the document (you can only comment on the whole line), plus inserting diagrams is also quite clunky. The pro is that everything (code and RFCs) stays on the same platform

We currently use Notion, but any of the above can be a good choice.

Summary

Just as it is the best practice to write a summary at the end of your RFC, we will do the same here! This article came out longer than I expected, but there were so many things to mention - I hope you'll find it useful!

Finally, being able to clearly express your thoughts, formulate the problem, and objectively analyze the possible solutions, with feedback from the team, is what will help you develop the right thing, which is the ultimate productivity hack.

This is how you become a truly 10x engineer. Thank you for reading, and until the next time!

🛠️6 tools to kickstart your full-stack app with AI 🤖

Matija Sosic — Tue, 28 Nov 2023 14:32:58 +0000

“It’s 2021, where is my flying car?” - that’s a sentence that Joel Spolsky (creator of Stack Overflow and Trello) used to express his disillusionment with how web development still feels pretty much the same as 20 years ago.

But today, with GPT in the equation, we can rightfully ask this question again. We see all these fancy tweets and demos, but what does that mean for me as a developer today, right now, when I need to start a new full-stack web app? Do I really have to go through npm create vite my-new-app, and start with a blank page once again?

The answer is, finally, “no” - there is a lot of cool stuff you can use that will make your life easier. It might not be a supersonic DeLorean yet, but it’s definitely at least hovering above the ground.

Let’s explore what the AI scene has to offer us today to make it easier to start and build a full-stack web app:

🐝 🤖 MAGE - from a single prompt to a full-stack, React & Node.js app in a minute (Free to use!)

MAGE (Magic App GEnerator) is probably the easiest-to-use AI coding agent there is - everything happens through the web interface, and all you have to do is type in the short description of the app you want to build. With that, MAGE will generate a complete, full-stack codebase in React, Tailwind, Node.js, and Prisma powered by Wasp, that you can freely download.

The best part about MAGE is that it is fully open-source and completely free to use - all you need to do is log in with your GitHub, and you can start creating apps!

MAGE was launched in July on Product Hunt and has since then been used to create almost 30,000 applications. You can read more about it and what types of apps you can build with it here.

📟 Aider - an AI pair programmer in your terminal

After you’ve created the v1 of your app with e.g., MAGE, and got the basic functionality in place, you will probably want to add more features. And why not use AI for that, too? That’s where Aider comes in!

Aider’s superpower is that you can plug it into any existing project and get going! It feels like chatting with a fellow developer sitting right next to you - simply describe your next feature, and Aider will do its best to implement it while providing all the details of the process and automatically adding a new commit to your repo! How cool is that?

You can learn more about Aider and try it out here: https://github.com/paul-gauthier/aider

🦀 🚀 Shuttle AI - build backends in Rust with GPT!

When you hear the term “web app”, most of us immediately think of JavaScript. While that is in a big part true for the front-end, we can build our back-end in any technology we like!

Other than the regular suspects such as Python, Java, and PHP, what about Rust? It is one of the most loved languages among developers, and it shouldn’t be reserved only for low-level algorithms.

Shuttle AI made that possible - their powerful Rust-based framework already makes it easy to build and deploy backends, while AI on top makes it a total breeze!

Learn more about it here: https://www.shuttle.rs/ai

⚡️📦 Supabase AI - goodbye, complex SQL queries

Supabase is one of the best ways to get the database for your full-stack app up and running, and you get a ton of features on top of that! Since it is specialized for Postgresql, that means you’ll occasionally have to write some SQL. And why not get some help from AI with that, too?

Supabase is already renowned for its beautiful and user-friendly dashboard with an integrated SQL editor, and now they made it even better by adding their own AI agent to it. Ask it to create new tables and indexes and even write database functions!

Learn more about it here: https://supabase.com/blog/supabase-studio-3-0

👁️ 🧑‍✈️Visual Copilot - Your Figma design to code

If you ever got a Figma design handout from a designer, and then it was your task to implement the UI with it, have you ever wondered if there was a way to automate this? This is what Visual Copilot is after!

With a single click, and given a Figma design, Visual Copilot will generate the front-end code for it! It will do its best to make it responsive and keep the code clean and reusable.

It is currently available as a Figma community plugin.

✈️ 🤖 GPT Pilot - Start a new app with a collaborative AI

GPT Pilot is a coding agent specialized for creating new apps from scratch. Its unique approach is that it collaborates with the developer - whenever it gets stuck, it will ask for your help!

Internally, it consists of multiple agents collaborating together and going through different stages of app development - from Product Owner and Architect to DevOps and Developer! It is a perfect example of PRD (Product Requirement Document)-led development.

It is another completely open-source solution that has lately gotten a lot of love from developers and has been featured on GitHub Trending leaderboard multiple times.

Learn more about it and give it a try here: https://github.com/Pythagora-io/gpt-pilot

Summary

And that’s a wrap! There are many more AI tools out there, and every day new ones are coming, but in this overview, we tried to focus on the ones you can use today to kick start a new web app.

Hopefully, you found this helpful and learned something new that might come in handy! I’d also love to hear from you in the comments - what are your favorite AI tools for web development, either ones you use daily or are simply excited about and what should we cover next?