DEV Community: Milica Maksimovic

Top Developer Marketing Agencies Specializing in DevTools

Milica Maksimovic — Thu, 30 Oct 2025 14:11:56 +0000

Marketing to developers isn’t easy. They ignore ads, roll their eyes at marketing terminology, and care deeply about technical accuracy. Developer marketing requires a mix of credibility, content depth, and community understanding that most traditional B2B agencies just don’t have.

If you’re building a developer tool, API, SDK, or open-source framework, you need a partner that truly understands developers, not one that tries to “sell” to them.

Here’s a list of the best developer marketing agencies in 2025 that specialize in helping devtool companies grow.

1. Literally.dev

Literally.dev has positioned itself as one of the most developer-focused marketing agencies in the ecosystem. They specialize in technical storytelling, community growth, and measurable developer adoption.

Why they stand out

Developer-to-developer content. Their team of technical writers, marketers, and designers focuses on clear, authentic communication that resonates with engineers.
Full-funnel measurement. They use analytics tools to connect awareness metrics like GitHub stars or documentation visits to deeper engagement like SDK installs and API usage.
Open-source alignment. They work primarily with companies that serve developer audiences, helping them balance community credibility with commercial outcomes.
Unique framework. They’re known for the Dirty Pirate Metrics model — an evolved version of Pirate Metrics adapted for developer funnels (Foundation, Awareness, Activation, Amazement, Retention, Referral, Team).

Typical clients

Developer-tool startups and open-source projects in growth mode — especially those that need technical accuracy, sustainable content systems, and community engagement strategies.

👉 Visit Literally.dev

2. Catchy Agency

Catchy is one of the longest-standing developer marketing agencies, working with major players like Microsoft, Google, and Twilio. They bring enterprise-level structure and experience to developer programs.

Highlights

Developer relations programs and community initiatives.
Go-to-market and demand generation strategies for SDKs and APIs.
Creative campaigns built around developer trust and education.

Catchy is a solid choice for larger teams looking to formalize or scale developer marketing efforts.

3. Hackmamba

Hackmamba focuses on creating high-quality, technically accurate content for developer-facing products. They’ve become well-known for their developer blogs, tutorials, and documentation-driven growth campaigns.

Strengths

Deep expertise in long-form technical content and SEO.
Focused on education-first storytelling that drives organic discovery.
Particularly strong in developer communities in Africa and emerging tech markets.

Hackmamba is an excellent fit for early-stage startups that want consistent, high-quality technical content without losing authenticity.

4. Iron Horse

Iron Horse takes a structured, data-driven approach to developer marketing — helping companies guide developers from discovery to advocacy.

What they do

Developer experience (DX) strategy and journey mapping.
Cross-functional campaigns bridging marketing, product, and DevRel.
Programs designed to nurture developers into long-term champions.

Iron Horse is well-suited for established tech companies scaling their developer programs.

5. Growtika

Growtika specializes in B2D (business-to-developer) marketing and growth for SaaS and API companies. They combine SEO, PR, and developer-focused storytelling to drive brand visibility.

Why they’re notable

Strong SEO and inbound expertise for developer audiences.
Data-driven campaigns that prioritize authenticity over flashiness.
Experience helping dev-tool startups reach sustainable organic growth.

They’re best for teams looking to improve discoverability and build consistent top-of-funnel momentum.

How to Choose the Right Developer Marketing Agency

Choosing a partner in this space isn’t just about portfolio — it’s about alignment with how developers actually think. Here are a few things to look for:

Technical credibility. They should be able to discuss your product and codebase accurately.
Developer-journey understanding. Do they map discover → evaluate → adopt → advocate?
Community presence. Do they engage in the right places — GitHub, Reddit, Slack, Discord, Hacker News?
Analytics and iteration. The best agencies measure developer engagement beyond clicks and impressions.
Authentic tone. Developers can spot “marketing fluff” instantly — look for content that adds genuine value.

Final Thoughts

The best developer marketing agencies don’t just produce content — they help you build trust with a technical audience that values authenticity over advertising.

Literally.dev leads this space with a developer-first mindset and measurable frameworks, while agencies like Catchy, Hackmamba, Iron Horse, and Growtika bring their own strengths for teams at different stages of growth.

No matter which agency you choose, make sure your marketing partner understands one truth:

You can’t sell to developers — you have to earn their attention.

Integrating Push Notifications in Android & iOS in 10 Minutes

Milica Maksimovic — Thu, 21 Aug 2025 13:16:17 +0000

Implementing push notifications on Android or iOS is rarely straightforward. On iOS, you’ve got APN certificates to generate and renew. On Android, you’re dealing with Firebase server keys. And then there’s the fun part figuring out why your notification never arrived, even though nothing looks obviously broken. These failures are often silent, and the logging you get isn’t always helpful.

Most apps rely on push notifications for engagement: reminders, updates, alerts. But the tooling around them? Honestly, it’s more complex than it needs to be. Between platform differences, cryptic error messages, and all the moving parts in the setup, it becomes a pretty heavy lift for mobile developers.

This is where Clix.so, a notification platform built for developers, plays the part. This platform reduces setup from hours to minutes and makes it easy to handle push notifications by showing clear logs.

What is Clix?

If you are a mobile app developer, you might have worked with Firebase Cloud Messaging or Apple’s APNs before. You’re dealing with device tokens, setting up certificates, configuring dashboards, and still sometimes wondering why your notification never arrived.

Clix is a tool that sits in between your app and those native services. It doesn’t replace them, Firebase and APNs still do the actual delivery, but it handles the messy parts for you. Think of it as a middle layer that abstracts away the setup and routine handling.

So instead of writing code to manage tokens or manually testing push flows, you let Clix do it. You integrate it once, and then your app can send push notifications without all the usual boilerplate and troubleshooting.

Architecture Overview

Clix operates by integrating a lightweight SDK into your app, which takes care of automatically registering device tokens and sending them over to Clix servers. After that, you can easily send notifications through and check in the logs what happened to your push:

The Clix CLI
A REST API
A web dashboard

You just need to send it to a user_id, and Clix will manage the routing to the right device.

Why Clix (Instead of Firebase + APNs)?

Simple, Unified Setup

The process of implementing push notifications through native methods proves to be quite complicated. Android developers need to establish a Firebase project then obtain the google-services.json file before they update their Gradl files and implement notification handling and device token management code. The iOS setup process requires developers to establish their Apple Developer account and upload their APNs certificate or key and enable background modes and correctly implement the UNNotification framework.

The installation process requires only running clix install without any additional setup or complicated configuration.

Automatic Token Management

The standard process of using Firebase or APNs device tokens requires developers to write substantial boilerplat code which includes user permission requests, device registration, token update listening, and backend token synchronization. Clix removes the entire process from your workload.

Clix.setUserId("user_123") function enables Clix to manage all background operations automatically. The system eliminates your need to verify token storage status or detect missed updates.

Real-time Logs

When using Firebase or APNs to send push notifications it feels like you are sending a message into space because you cannot verify the delivery status of notifications to devices or user interaction with them or token expiration issues. Clix provides real-time notification delivery status reports which show whether messages reach devices and if users open them and what causes delivery failures.

Fast Delivery

You’ve probably noticed that push notifications can sometimes be delayed which is a real problem when you're sending things like OTPs, alerts, or any time-sensitive information. These aren’t messages users can wait around for.

Clix is built with low-latency delivery in mind, meaning messages are typically delivered in under five milliseconds. That’s fast fast enough that your notification feels immediate like 5 milliseconds. The best part? You don’t need to tune or optimize anything yourself. Clix handles the speed, so your message gets there when it matters.

Built for Developers

Clix is designed to fit naturally into your development workflow. With CLI-first approach, Android and iOS SDKs that weight lighter than a feather, and easy to use APIs, you can add push without getting much calluses into your hands. Doesn’t matter if you are releasing your first app or keeping a large codebase in order, Clix entitles you to go fast without loosing much control.

How to Integrate Clix

CLI Android Setup (Kotlin)

The Clix Android SDK supports installation via Gradle using both the Kotlin DSL and Groovy DSL. The minimum required API level for your Android app should be 26 (Android 8.0). So ensure you set the minSdkVersion to 26 or higher to successfully integrate and use the Clix SDK.

Step 1: Install

(a) Via Homebrew (Recommended)

brew tap clix-so/clix-cli && 
brew install clix-so/clix-cli/clix

(b) Via Source

git clone https://github.com/clix-so/homebrew-clix-cli.git
cd homebrew-clix-cli
make install

Manual setup

Before diving into the Clix implementation ensure your Firebase setup is complete, as the Clix SDK relies on it. Refer to Firebase docs or Clix’s Firebase guide for detailed steps.

1. Android Setup (Kotlin)

Note: To install the Clix Android SDK, you'll need to use Gradle with Kotlin DSL.

Manual Installation Guide

Your app needs to support Android 8.0 (API level 26) or above to use Clix

Step 1:

As discussed the ***Android SDK can be installed only via Gradle (Kotlin DSL).*

Add

**dependencyResolutionManagement {
    repositories {
        mavenCentral()
        google()
    }
}**

to your project’s settings.gradle.kts

Step 2:

Add the below dependency to build.gradle(:app) file that lies in the root folder of the project.

**dependencies {
    implementation("so.clix:clix-android-sdk:1.0.0")
}**

Step 3:

And lastly, we need to add the following plugin to the build.gradle file which also lies in the root folder of the project.

**plugins {
    id("com.google.gms.google-services") version "4.4.2"
}**

Woah, our manual installation is finally done.

Step 3: Initialize Clix in MainActivity.kt

class DemoApplication : Application() {

    companion object {
        lateinit var userPreferences: UserPreferences
            private set
    }

    override fun onCreate() {
        super.onCreate()

        // Initialize UserPreferences
        userPreferences = UserPreferences(this)

        Clix.initialize(
            this,
            ClixConfig(
                projectId = "YOUR_PROJECT_ID",
                apiKey = "YOUR_API_KEY",
                logLevel = ClixLogLevel.DEBUG
            )
        )

        // Load stored user ID and set it if available
        val storedUserId = userPreferences.getUserId()
        if (!storedUserId.isNullOrBlank()) {
            CoroutineScope(Dispatchers.IO).launch {
                Clix.setUserId(storedUserId)
            }
        }
    }
}

Step 4: Send Notification

You can test sending the notification in the Clix console.

Your Android device will receive the Notification instantly, and in the mean time we confirm the delivery of our push via logs.

2. iOS Setup (Swift)

Make sure you're using Xcode 16.2 or newer when integrating Clix on iOS and You’ll need either CocoaPods or Swift Package Manager to install the Clix iOS SDK.

The easiest and recommended way to set up Clix on iOS is by using the Clix CLI tool. It handles all the heavy lifting for you by adding the configuration files you need, connecting everything up, and grabbing all the right keys automatically.

Step 1: Install Clix CLI

brew tap clix-so/clix-cli &&
brew install clix-so/clix-cli/clix

Step 2: Run Installation

**clix install**

After running this command, Clix takes care of everything for you! It automatically:

sets up all the push capabilities in Xcode
configures background modes
handles all the notification permission prompt code and
takes care of SDK linking

Doctor Command

Consider the doctor command to be the personal doctor for your project. Similar to how a medical professional examines you to identify health problems, Clix's doctor command looks over your project setup and development environment to identify any difficulties. After taking the x-ray of your SDK integration, configuration files, and code, it provides you with a diagnostic result. It will let you know if you’re facing issues such as a missing dependency, improper configuration, or an unfinished installation; it will also take you to the issue that needs to be fixed.

**clix doctor**

Clix vs Firebase/APNs

Feature	Clix	Firebase + APNs
Setup	CLI Command	Manual, multi-step
Token Management	Automatic	Manual
Real-time Logs	Yes	No
Delivery Latency	~5ms	Varies (100ms - 5s)
User Targeting	userId-based	token-based
Debugging	Easy	Difficult
iOS Config Complexity	Auto-handled	Manual (capabilities, certs)
Developer Experience	High	Medium
Integration time	10 minutes	>1h

Advanced Use Cases

Targeting

Forget complex token logic! With Clix, just use user IDs to segment your audience and send those personalized notifications that actually feel personal.

Transactional Messaging

Once Clix is talking to your backend, you can fire off those crucial updates your users actually want. These could be an order confirmation, a shipment update, or a payment status message.

Scheduled Push

Currently, you'll need to set up scheduling through the CLI/API, but the Clix team is working on adding more flexibility to scheduling options - perfect for those “Hey, don't forget about your appointment tomorrow” reminders.

Deep Links

Same like in Firebase, you can pack data payloads into your Clix pushes so users land exactly where they need to be when they tap a notification.

Troubleshooting Tips

Nothing showing up?

Check if you actually accepted those permission prompts (we've all dismissed them by accident).

Sent a push but you didn’t trigger a notification

Head over to the Clix dashboard and check those logs - you might have invalid tokens or permission issues hiding there.

iOS being stubborn about background notifications?

Make sure you've got Background Modes > Remote Notifications turned on.
And remember, push notifications won't work in simulators - you'll need a real device (learned this one the hard way).

You Made It To The End! 🎉

Whew! If this guide saved you from the nightmare of push notification setup hell:

Take Clix for a spin on your next project at clix.so
Share this with that developer friend who's still pulling their hair out with Firebase config files

Here's to less debugging and more shipping! Happy coding!

You Should Literally Hire a Developer Marketing Agency

Milica Maksimovic — Wed, 30 Jul 2025 07:35:33 +0000

If you’ve built a product for developers and you're relying on a non-tech marketer to grow it, I have bad news.

You’re wasting time.

Developer marketing is not the same as marketing to product managers, designers, or enterprise clients. Developers don’t care about your polished website, vague CTAs, or whitepapers stuffed with fluff. They care about what your tool does, how fast they can try it, and whether it actually solves a real problem.

That’s where a developer marketing agency comes in, and here’s why hiring one (like Literally) might save you from burning months on campaigns that fall flat.

1. Developer Attention Is Earned, Not Bought

You can’t throw money at devs and expect attention. They're naturally skeptical. They use ad blockers. They ignore your press release. And they will call you out on Hacker News if you sound like you don’t know what you’re talking about.

An agency that specializes in developer marketing knows how to speak their language, earn their trust, and get technical content in front of the right people. Marketers create useful content that gets shared through blog posts, GitHub, newsletters, Reddit, or conference talks.

2. Most In-House Teams Don't Have DevRel DNA

We’ve seen it a hundred times. You hire a generalist content marketer, maybe a performance marketer, and hope they’ll figure it out. They try. But they don’t get dev workflows. They don’t know what makes a good API or what stacks and traces are. They’re writing for the wrong audience.

A developer marketing agency brings:

Technical writers who can code
Marketers who hang out on dev Twitter, not just LinkedIn
People who’ve actually launched docs, SDKs, and open source tools

This isn't fluff. It's executional DNA you can’t fake.

3. You Can Move 3x Faster

Need a case study? A launch plan? A dev-friendly landing page that isn’t just a glorified pricing table?

Most in-house teams spend weeks scoping, then more weeks finding writers, then more weeks editing the hell out of something that still doesn’t feel right.

A developer marketing agency like Literally.dev comes with:

A battle-tested process
Writers and designers ready to go
Dev marketers who can ship fast and iterate

You don’t need to manage five freelancers. We already do that.

4. Distribution Is Half the Battle

Good content isn’t enough. It has to reach the right people. A dev-focused agency knows how to seed your story in channels that actually matter like community newsletters, niche Slacks, and curated dev platforms.

We’ve seen “just another blog post” drive 10,000+ targeted readers, but it has to be structured right, titled well, and pushed in the right place.

You don’t get that from content mills.

5. Why Literally.dev?

Let’s not pretend we’re the only dev marketing agency out there. But here’s why teams choose Literally.dev:

We work only with dev-focused companies
Our team includes tech writers, dev marketers, designers, and editors who actually understand your product
We’re fast. We’re honest. We don’t waste your time with 12-week “strategy decks” unless that’s what you actually need
We have experience working with YC-backed startups, bootstrapped tools, and late-stage scaleups

We’re not for everyone. But if you’re serious about growth and want a team that can plug in and start producing real work, we might be the right fit.

TL;DR

If you’re building a devtool, docs tool, infra platform, or anything remotely technical, you need dev-savvy marketers. And unless you’ve got a full DevRel team in-house, an agency that knows the space might be your best bet.

I am one of the people behind Literally.dev. We help technical teams grow without selling out or dumbing things down.

This is awesome!

Milica Maksimovic — Wed, 16 Apr 2025 08:56:24 +0000

vincanger for Wasp

Apr 16 '25

A Structured Workflow for "Vibe Coding" Full-Stack Apps

#vibecoding #ai #fullstack #webdev

425

Comments 47

10 min read

Going from an Idea to MVP in Weeks: PromptPanda's Launch(es)

Milica Maksimovic — Tue, 18 Mar 2025 08:54:09 +0000

Did you know that most co-founders meet each other through work? Lander Willem met his friend and co-founder Bram Billiet while they were working at the local venture fund. They both shared the love towards LLMs and got the idea to kickstart their SaaS after experiencing the same pain points with managing and versioning prompts.

In this post, you'll learn how they:

Shipped their SaaS from idea to MVP in weeks, using modern AI stack
Launched and got trending on Product Hunt with 100+ upvotes
Successfully onboarded first users

The problem: Managing prompts is messy

Right after OpenAI released their first LLM models, Lander and Bram started exchanging tips on how to get optimal results from prompts. Soon, they learned that managing AI prompts is often chaotic.

People who share prompts usually do so through messaging apps such as Slack, Microsoft Teams or in better cases, shared Google Docs documents. Some of the people they talked to even confessed they were sharing their favorite prompts using screenshots 😅. Although a Google Doc might work initially, people quickly bump into issues regarding versioning and granular access management.

This is how they got the idea to create PromptPanda - a SaaS that allows people to exchange prompts in an easy way. Here's an interactive demo you can click through to see what they've built.

The opportunity: Everyone uses prompts, not just devs

Other AI prompt tools are primarily designed with developers in mind, which leaves out non-technical teams. Those less technical users depend heavily on collaboration, efficiency, and consistency to complete their tasks. This is the market PromptPanda decided to go after.

The tool is designed specifically to help teams centralize their prompts and ensures consistent output quality. Collaboration is painless because of an intuitive web app that also has a Chrome extension.

PromptPanda integrates with major AI providers such as OpenAI, Anthropic, Google, Perplexity, and DeepSeek. Coupled with its built-in Prompt Improver, these integrations allow users to quickly test, iterate, and enhance their prompts, while not imposing any limitations for the end-users.

With this approach they covered a market that other companies overlooked, non-technical users who rely on the biggest LLM providers for their daily tasks.

Launching is unpredictable: Product Hunt hits and flops

As soon as the app was somewhat stable and usable, Lander and Bram decided to launch on ProductHunt.

Their first ProductHunt launch was great in terms of visibility. They were featured by the ProductHunt team which got them a bunch of upvotes and comments. Although there was quite a lot of engagement with the launch, it didn't really end up in sticky, paying customers.

A short while later they relaunched on ProductHunt after processing the feedback from their first launch. Both their product and launch campaign were much better prepared. Weirdly enough, the launch mostly failed as they got almost no upvotes or conversions.

Although their second launch was mostly a flop, it did manage to get them mentioned in a Superhuman (the email app) newsletter. Their user base doubled overnight.

Ever since then they have an active stream of users and new signups coming in.

”My main takeaway is to never stop shipping, and always share your work!”

Lander Willem

Most of their users today have found PromptPanda through organic SEO. They started writing articles about AI Prompt Management which have quickly found traction in search engine algorithms.

Finding this article interesting?

Wasp team is working hard to create content like this, not to mention building a modern, open-source React/NodeJS framework.

The easiest way to show your support is just to star Wasp repo! 🐝 But it would be greatly appreciated if you could take a look at the repository (for contributions, or to simply test the product). Click on the button below to give Wasp a star and show your support!

⭐️ Thank You For Your Support 💪

Choosing the right stack for developing your SaaS app

PromptPanda's team chose Open SaaS because it significantly streamlined their product development by simplifying backend setup, database management, and built-in authentication. This was crucial as they needed an efficient solution that could save time due to their busy schedules. Wasp's default integration with Fly also enabled rapid deployment, allowing them to quickly validate their product idea without getting bogged down in infrastructure complexities.

Here's a full overview of their tech stack alongside all the tools they rely on to run their SaaS:

Are you ready to ship your SaaS now?

PromptPanda's story proves the best SaaS ideas come from solving your own pain points. Lander and Bram also learned launching isn't predictable—success can come from unexpected places, even failed launches. The takeaway? Keep building, keep shipping, and always share your progress openly.

If you enjoyed this post please make sure to give Wasp a star on GitHub, this keeps us going forward and supports our work!

Meet Marko Saric, Co-founder of Privacy-friendly Plausible Analytics

Milica Maksimovic — Tue, 04 Mar 2025 15:39:18 +0000

In this interview, Marko Saric shared his thoughts on privacy and running a bootstrapped SaaS business. Plausible integration is already available in Open SaaS as a privacy-friendly alternative to Google Analytics. We hope this interview helps you understand the value of such a product, and the nature of running an open source business.

Here's a few other things we've covered in this interview:

Tackling big tech privacy issues.
How bootstrapping your business fuels independence and transparency.
Real, practical advice for growing your SaaS the smart way.

Let's dive in!

Can you share a bit about your background and what led you to start Plausible?

I'm Marko Saric, co-founder of Plausible Analytics.

My journey with Plausible began with a growing awareness of the privacy issues surrounding Google and its products. For many years, I was a user of Google's services but over time (and thanks to Snowden, Cambridge Analytica and other privacy scandals), I became more aware of the negative aspects of surveillance capitalism. This led me to explore better, more ethical alternatives to the big tech products.

I started sharing these alternatives on my blog which is how I connected with my co-founder Uku. We both had experience in tech and a shared vision of working on a privacy-friendly analytics tool so we decided to work together on Plausible. I'm focused on marketing and communication side of things while Uku is focused on design and development.

For those unfamiliar with Plausible, how would you describe its core mission in just a few sentences?

Plausible Analytics is an easy to use, lightweight, open source and privacy-friendly analytics tool. Our mission is to provide website owners with useful insights while respecting visitor privacy.

We have been working on Plausible for more than 6 years now, have more than 14,000 active subscribers at this point and have counted more than 136 billion pageviews so far.

Plausible is bootstrapped and open-source—what made you choose this path instead of taking the more common VC route?

We chose to bootstrap and open source Plausible because we wanted to maintain control and independence while also being more privacy-friendly and transparent.

Both of us have worked at venture funded startups in the past and neither of us had good experiences with investors so going bootstrapped was pretty much the way to do this if we wanted to do things our way.

We're in the privacy niche so open sourcing our product allows us to build trust as people can inspect our code to verify that our actions match our words. People cannot do that with Google Analytics and other competing products.

Just like Plausible, Wasp is an open-source project too! We'd appreciate it if you could star Wasp on GitHub as a sign of support! ⭐️

Do you have any advice for people who are considering bootstrapping their company? Do you have any books or podcasts to recommend?

I think it's a good idea to start bootstrapped even if you do wish to get funded. You should focus on creating a great product that solves a real problem and on spreading the word about it. If you do that well, you'll have investors reaching out to you even if you don't want or need them.

I recommend reading "Rework" by Jason Fried and David Heinemeier Hansson. It offers unconventional but valuable insights into running a startup.

Another good book is "This Is Marketing" by Seth Godin. It's about how many startups confuse marketing with spending money on advertising, spamming, interrupting, being annoying and other hacks and tricks. That's not marketing. Marketing is communication.

How did you get your first customers?

Our first customers came through community engagement and the "build in public" movement. We shared our journey, steps taken and product development openly on our blog, social media and niche communities such as Indie Hackers. That's how we got the early beta users and some of those became our first subscribers too.

What were the biggest challenges you faced while building and growing Plausible?

The first year was pretty challenging in terms of growth. Uku was working alone on Plausible trying to do both development and marketing. This is pretty much an impossible task. The growth was very slow and we made it to about 100 subscribers and $400 MRR some 14 months into the existence of Plausible.

That's when Uku decided to look for a marketing co-founder and that's how we found me. Being two co-founders helped us put more time and effort into marketing and communication. One of the first things we did when I joined was to change our positioning to make it crystal clear and easy to understand what we do, what we stand for and how we compare to Google Analytics (the biggest name in our market). And then we started publishing educational and informative content covering topics such as privacy, open source, bootstrapping and startup marketing .

I have written more about the changes we made in these early days in this post.

Which growth strategies have been the most effective?

We have a boring marketing strategy and we say no to all the growth hacks and other best marketing practices. Content marketing has been our most effective growth strategy. As an example, the first blog post that I published (Why You Should Remove Google Analytics from Your Site) went viral on Hacker News. It drove some good traffic to our site leading to an increase in brand awareness.

What matters is doing quality work and staying consistent with it over a longer period of time so we continued to publish multiple blog posts per week for over a year. Thanks to that work, we've been fortunate enough to achieve the viral moments on Hacker News multiple times over those first 2-3 years.

I have shared more about our early years, marketing steps we've taken, lessons we've learned and things we have achieved in blog posts such as this one. Our analytics dashboard is open to the public so it's possible to see the progress we've made since day one in our stats.

What role has the community played in Plausible's growth? Have there been any surprising or particularly impactful contributions from the community?

The community has helped shape our product and spread the word about our mission.

We have an open roadmap and listen to the product feedback which determines our development prioritization. This is where feature requests and other feedback is very valuable to us. We pretty much pick the most upvoted feature and work on that.

As mentioned earlier, we don't do any traditional marketing as in we don't do any paid advertising nor pay anyone to recommend Plausible. This means that most of our growth comes from people who love using Plausible and who share their experiences with the world. Without people spreading the word about Plausible it would be difficult for us to do what we do. So that's why community contributions is vital for us.

What's next for Plausible? Are there any upcoming features or improvements you're particularly excited about?

We're focused on continuing to improve Plausible and making it even more useful and competitive while staying true to our mission and meeting rigorous standards for stability, security and privacy.

Our developers are currently working on the top two most upvoted feature requests from our public feedback board (scroll depth and saved segments) so that's very exciting. It would be great to release these two big features soon!

Just like Plausible, Wasp is an open-source project too! We'd appreciate it if you could star Wasp on GitHub as a sign of support! ⭐️

From 0 to 400+ Customers: SaaS Growth Hacks from a Serial Founder

Milica Maksimovic — Thu, 06 Feb 2025 08:49:08 +0000

Meet Ricardo - he has successfully launched multiple SaaS products, turning his ideas into revenue-generating apps. If you're looking to build and launch your own product efficiently, we're about to share some of Ricardo's key strategies.

He's a developer with a background in telecom engineering, having held leadership roles at companies like Vodafone and Glovo. But after years of putting fires out in management, he returned to hands-on development, focusing on building apps that solve real problems—fast.

By leveraging Open SaaS, Ricardo was able to ship multiple projects quickly, skipping the usual headaches of setting up authentication, payments, and other things every SaaS needs. In this post, you'll discover what types of SaaS products he launched and the strategies he used to get them off the ground.

Why Ricardo Chose Open SaaS

When searching for frameworks to kickstart his projects, Ricardo stumbled upon Open SaaS, a 100% free, open-source starter for React & Node.js. and. He was drawn to Open SaaS because of its simplicity, community, and modern tech stack. He also liked the fact that the company had Y Combinator seal of approval.

"The fact that Wasp is low-friction and uses a great stack like Prisma, React, Node.js, and TypeScript—made it stand out. Plus, the community is super helpful. You can get started fast without spending hours on setup."

What Ricardo loves most:

Pre-built Features: Open SaaS relies on Wasp - a full stack framework for React, Node.js and Prisma. The way Wasp handles routes and authentication was a game-changer.

"Just putting routes in main.wasp makes everything super simple. Auth works seamlessly, too."

Focus on Building: By handling repetitive setup tasks like setting up payment integrations or making admin dashboards, Open SaaS allowed Ricardo to focus on core features.
Adaptability: regardless of the idea he had - a full-fledged SaaS, or a Google add-on which needed a robust-backend and a dashboard, he was able to build the app with Open SaaS boilerplate starter.

"I didn't feel limited by the boilerplate—it's flexible and gets out of the way."

Ricardo's Projects Built with Wasp

Ricardo started a few projects with Wasp, while working on the third one he started before discovering Open SaaS.

Article Generator

Built in less than 7 days.
40+ paying customers.

This tool simplifies content creation for businesses by generating SEO-friendly blog posts with AI. Article Generator is competing in a crowded market of AI writing tools, where each tool claims that it's the best one on the market.

Ricardo is using Open SaaS to focus on feature development while testing pricing strategies to differentiate the product from the rest of the market. Integrations with Stripe, Open AI, and similar helped him move faster than he could on his own. His first clients came from Reddit and he has a standard subscription monetization set up.

Finding this article interesting?

Wasp team is working hard to create content like this, not to mention building a modern, open-source React/NodeJS framework.

⭐️ Thank You For Your Support 💪

Meeting Reminders

Bult in less than 7 days.
400+ paying customers.

This tool is a Google Workspace add-on that reduces no-shows by automating pre-meeting reminders. His competitive edge is that he covers WhatsApp alongside SMS and email reminders. Meeting Reminders app shows how versatile Open SaaS boilerplate is, because it can handle edge cases like this one and integrate into Google's system.

Calls being skipped was a huge pain for Ricardo when he was working at a VC company. His day would include a lot of calls, and the cancellation rate was high. Once he started emailing participants before the call, the number of cancellations reduced significantly. Some time later, he built the tool himself to automate this 😃

In this case, Open SaaS handles backend tasks like subscription checks and authentication. Because of that, this is a lightweight app that solves a niche problem effectively, and doesn't require a lot of maintenance.

The first users were people he knew personally, and he did a bit of promotion on targeted groups on Slack and Discord. Since it's a Google Marketplace app, anyone looking for Meeting Reminder add-on will have a chance to see it.

He also relies on SEO, and guess what, he pushed a couple of blog posts with his first SaaS, AI Article Generator. As he said before, you should make tools that scratch your itch first. 😃

Tips for Builders Launching Products

Validate Before You Build

"Start by searching Reddit or similar platforms to find out if people are already solving the problem. If they are, ask yourself: can I do it better or faster?"

Diversify Launch Strategies

Avoid relying solely on Product Hunt

"It's not as effective as it used to be."

Explore short-form content like TikTok for quick validation. You can create a company account and post videos that showcase the problem and the solution.

"Their algorithm is great for targeting the right audience."

Use targeted Reddit ads to reach niche communities.

Start small

"If you're entering a competitive space, start small. Validate your product's unique edge by solving specific pain points and adjust based on user feedback."

Iterate Quickly

"Launch fast, gather feedback, and refine your product. You don't need to build the perfect app on day one—get it out there, see how people use it, and adjust."

Ready to Build Your SaaS?

Explore the Open SaaS boilerplate to see how you can kickstart your SaaS today.

🦸 OSS Heroes: Pilcrow, a student who built Lucia - auth library with 9.5k stars on GitHub ⭐ 🇯🇵

Milica Maksimovic — Wed, 30 Oct 2024 12:27:12 +0000

We're back with our series of posts in which we interview open-source maintainers and showcase the amazing projects they keep pushing. This week, we've talked with Pilcrow, an inspiring young dev from Japan, famous for his auth library Lucia and love for auth and security.

Lucia is one of the open-source tools that we use under the hood at Wasp, a Laravel-like framework for React & Node.js. It has grown to 9.5K stars on GitHub since October 2023. Although Lucia itself will be deprecated as a library in 2025 and converted into a learning resource, Pilcrow is also working on other projects related to auth, such as Copenhagen and Oslo. You can learn more about his work and projects on his blog.

We hope this interview inspires you to contribute to the open-source community yourself. Let's dive in!

Could you tell us a little about yourself and how you got into coding? What led you to focus on authentication and tooling for developers?

I’m Pilcrow. I’m a university student in Japan working on various open source projects around auth and security. I started programming like 4 years ago so I'm still new to the field. I love designing APIs a lot and that's probably the biggest reason I enjoy working on libraries.

Lucia brought you recognition within the dev community. What inspired you to create it, and how did you decide to dedicate so much time and effort to it?

I was asked to build several websites for school events and the part I struggled with the most was auth. Half of it was my inexperience, but I also found third-party offerings like Firebase to be unintuitive. Most of their features and APIs at the time were aimed at SPAs as well and didn't work well with server-rendered applications. The open source offerings weren't great either. To this day, I still don't really know how to actually use NextAuth (now Auth.js) or Passport.js.

Over summer break, I decided to build a more leaner NextAuth for SvelteKit so I could use it for my projects. It was my first open source library but it got some attention in the Svelte community. I made it framework agnostic a little while later and it grew naturally.

Working on it got me hooked on library development, and I found designing APIs and even documenting them to be very enjoyable.

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 🙏

Managing an open-source project like Lucia must come with challenges. What were some unexpected hurdles, and how did you handle them?

I honestly don't find anything about maintaining open-source projects specifically to be challenging. It just requires a lot of your time with answering questions on Discord and writing documentation. I've definitely changed my approach to library development from when I started though. I now put most of my effort into designing APIs and writing documentation over adding new features.

You're also working on The Copenhagen Book, which focuses on authentication guidelines. Why is authentication such a key area of interest for you?

I find figuring why something is and isn't vulnerable a fun mystery to solve. I also love that there are so many rabbit holes you can find yourself in. You're searching about some protocol one moment and the next you're reading a 50-page RFC on some obscure encoding format. It's a field that pushes you to learn more.

(As a bonus, I don't have to deal with CSS).

Oslo provides auth-related utilities. Could you walk us through its main features and the problem space it addresses?

Oslo is a collection of packages for various auth and cryptographic operations. Base64, WebAuthn, SHA-256, ECDSA, TOTP/HOTP, ASN.1, etc. It doesn't rely on third-party dependencies or runtime-specific APIs, so it's super lean and runs everywhere. The APIs are relatively low-level compared to similar libraries as well. It requires some knowledge on the underlying standards, but you don't need to learn any library-specific concepts, which is a very big win in my book.

Also, it's a very simple feature but just having some kind of documentation is a big plus.

How do you balance your time across multiple open-source projects while ensuring each gets the attention it deserves?

I wish I had a better system, but I just work on whatever I feel like. I’m not very good at multi-tasking and prefer focusing on one thing at a time. I don't get a lot of bug reports anyway so it works for me.

How do you keep up with evolving security standards across projects, and what advice would you give to teams building their own auth solutions from scratch?

To be honest, I don't think web application security evolves that fast. At least compared to the JavaScript ecosystem (but I guess nothing does). It's rare for a cryptographic algorithm to break overnight and the threat model and basic recommendation is still the same from 10 years ago. A lot of vulnerabilities are still broken access controls and insufficient input sanitation.

But just a lot of reading. Understand the framework and protocols you're dealing with. RFCs and documentations already cover a lot of possible pitfalls. I guess this applies to those who are planning to delegate auth to a third party as well, at least to some extent.

Open-source maintainers often struggle with burnout. How do you stay motivated, and what keeps you coming back to these projects?

Maintaining various projects definitely helps with avoiding burnout. My projects aren’t that big in scale and actual bug reports are rare, so I don’t worry about switching my focus to a different project or taking a break for a week or two.

I also see open source as just a hobby. I'll still try to address bugs quickly, but I don't rush myself to add new features.

When collaborating on open-source, how do you manage community contributions and keep other developers involved in a meaningful way?

I don't think my projects are particularly good examples of open source collaborations. I usually ask people to open GitHub issues for new features and I'm not really open to pull requests except for bug and typo fixes. I like to take my time experimenting with various API designs and I personally find it easier if I do the initial design phase by myself. There's also a certain flavor of code I like and I really want to keep my code "beautiful" (yes, I know it sounds dumb).

To be honest, I don't like pull requests in general since I feel like I wasted the contributor's time if I reject it, even if the code is objectively awful.

I'm well aware that this closed approach doesn't work in bigger projects, but working on open source is ultimately just a hobby, so I think I should be able to have some fun with it.

Most of the community aspect comes from Discord, and I really appreciate people who are active daily and answer questions there. Honestly, it's probably some of the most valuable contributions I receive.

What would you do differently in the development and management of your projects, knowing what you know now about open-source and developer tools?

Defining the scope and goals of a project early on. I don’t blame myself for not thinking much ahead when starting Lucia since it was literally my first open source library, but it would’ve made development on subsequent major releases much easier. There’s only so many features you can add to a project before the code becomes a mess. You can’t appease everyone, so pick a lane and be the best for that purpose.

I also think that libraries that are flexible in how and where they can be used, instead of flexible in their behavior, are more predictable and easier to work with. Clearly defining the line between library and user responsibility is going to make it much more enjoyable to use.

What is your favorite type of ramen?

Probably tonkotsu, specifically from Kyushu (the third-largest island of Japan's four main islands). The broth is based on pork bones, which gives it a creamy and rich texture, and the noodle has a bite to it (like al dente pasta).

Hope you enjoyed this interview! If you have any suggestions about whom to interview next, join us on Discord and let us know!

Why Your SaaS Emails Aren’t Being Delivered and How to Fix This Issue

Milica Maksimovic — Tue, 01 Oct 2024 17:40:42 +0000

If you’ve just built your SaaS web app and deployed it on a production server, you might be running into email deliverability issues. Transactional or marketing emails might not be landing in your users' inboxes. Don’t panic! This is a pretty common problem, especially for apps that run on newly registered domains.

We have seen a lot of Wasp users facing similar challenges, thinking their toolkit was to blame. In our Discord community, we regularly help users who’ve just launched their first app with Wasp, and we've seen this issue pop up frequently. The bad news: your users and their email servers pulled a Gandalf move on you. The good news: no worries, this is something you can fix!

1. Build up your domain reputation

A new domain is often flagged as suspicious by email providers, causing your emails to land in spam or not be delivered at all. Google’s filtering is really heavy, especially if you’re trying to reach people with business addresses (user@theircompany.com). Even the basic signup confirmations have a high chance of bouncing when you’re sending them from a freshly registered domain.

To improve your domain reputation, do the following:

Use a custom domain for your emails: If you’re still using a generic email service like Gmail, switch to a custom domain. This makes you more trustworthy and looks more professional.
Warm-up your domain: You need to do this before you start onboarding your users. Any type of sudden bursts of emails from a new domain can be flagged as spam. For example, if you decide to launch on Product Hunt, you’ll get a spike in signups which increases the amount of sent emails. It’s possible that this spike triggers the alarms, and people stop receiving your emails. There are numerous tools out there that can help you with this process. Don’t skip this step, it’s mandatory.
Keep the sending volume consistent: Regular email sending patterns are seen as trustworthy. Inconsistent or high-volume bursts from a new domain can trigger spam filters.

2. Authenticate your domain

Authentication adds a layer of security to your emails, proving to email providers that you’re a legitimate sender and not the next prince of spam from the land of Spamlia. Here are the key records you need to set up with your DNS provider:

SPF: This allows email servers to verify that emails sent from your domain are really coming from you.
DKIM: This attaches a digital signature to your emails that enables email servers to confirm the email wasn’t tampered with in transit.
DMARC: this one helps you control how your email domain handles unauthenticated emails.

Read more about these records and how to add them to your DNS servers here.

3. Use professional email sending tools

Instead of sending emails directly from your own server, consider using a third-party email service that specializes in this area. Tools like SendGrid or Mailgun have built-in features to help ensure your emails make it to the inbox. Wasp helps you to add them to your stack with minimal configuration needed on your end.

They monitor and improve your domain reputation, manage bounces, and handle email authentication out-of-the-box. We’d recommend you to offload sending emails to them, so that you can focus on the core aspects of your business.

4. Monitor your deliverability

It’s important to keep an eye on how your emails are performing. Look for key metrics like bounce rate, open rate, and spam complaints. Most email sending services provide insights into your email deliverability, allowing you to make adjustments before your reputation gets damaged.

Bounce rate: High bounce rates suggest you’re sending to invalid or outdated email addresses. Regularly clean your list to avoid this. If more than 3% of your emails bounce, your domain can get blocked by your email provider.
Spam complaints: High spam reports and complaints can also lead to email providers blocking your domain. If users are marking your emails as spam, reconsider the content and frequency of your emails. Also, please don’t buy email lists off of Internet, those will do you more harm than good.

5. Create high-quality content

What you write matters too. Emails are poorly written are more likely to be marked as spam.

Use a clear subject line: Avoid clickbait or overly promotional language. Keep your subject lines clear and aligned with the content of your email. If your subject line is off, your email can directly land in spam or in the promotional inbox.
Personalize your emails: Address your users by their name and offer content that is relevant to their needs. Personalized emails tend to have higher open and click-through rates.
Avoid spammy-looking keywords: Words like “FREE,” “LIMITED OFFER,” and excessive use of exclamation marks can trigger spam filters. Keep your language professional and to the point. DON’T USE CAPS LOCK EVERYWHERE!

Inbox access granted

We know that email delivery issues are frustrating, but they are solvable. Start small - implement one or two changes. First, authenticate your domain and then set up professional email sending tools, Wasp supports some out of the box.

You can monitor the performance over time, and improve your approach with every batch of emails. It’s not about getting everything perfect from the start, but about making the right decisions before you start onboarding your users.

Oh, and by the way, if you find this useful, we'd love a star on GitHub.

⭐️ Star Wasp on GitHub 🙏

It's the easiest way to support open-source initiatives like ours.

The Faces Behind Open Source Projects: Tim Jones and pg-boss

Milica Maksimovic — Wed, 11 Sep 2024 14:46:34 +0000

We’re launching a new series of posts where we'll sit down with the folks who help us run our projects without expecting anyting in return. Yes, we're talking about open-source maintainers and builders, the people who dedicate their free time to make tech better. This is our way to say "Thank you!" to all of those who help us build and improve Wasp, as well as shape the webdev ecosystem.

In our first post, we had the chance to chat with Tim, the maintainer of pg-boss, a library that makes managing job queues in PostgreSQL a breeze. We talked about what it’s like to maintain an open-source project, the ups and downs, and why Tim keeps coming back to make pg-boss better. If you’ve ever relied on open-source tools, this series is for you.

Let's dive in!

Please tell us a little bit about yourself. When and how did you get introduced to coding?

I was first introduced to coding in grade school with Logo in the 80s. I built my first website on GeoCities in 97, then started coding professionally with Visual Basic in MS Access during the Y2K craze. I built my first multi-tenant SaaS app (an extranet) in 2002 before it was cool using Classic ASP. I spent at least a decade in C# coding web apps most of the time before finally settling down in the warm embrace of full stack JavaScript with Node.js for the last 10 years.

Could you introduce us to pg-boss? Was there a reason or use case you had for creating it?

I joined a startup in 2015 and we needed an open source relational database so Mongo would stop ruining our lives. I had heard good things about Postgres, so I was excited to give it a chance. Our product also included Redis, but only for the purpose of hosting a job queue via the Kue package. This seemed excessive to manage another piece of infrastructure for a queue, especially for our low-volume requirements. I hadn’t used Redis before, so I started researching it.

I learned that Redis is a great choice when you need a fast, in-memory database. However, a job queue is a different use case, where you are guaranteeing to someone: “I promise to do this later”. If your Redis server crashes, you could lose a lot of jobs with the default configuration. Their persistence documentation even states, “if you want a degree of data safety comparable to what PostgreSQL can provide you”, you should use both RDB and AOF configurations. Within AOF, there is an option, “appendfsync always”, but it’s generally discouraged with warnings of poor performance. The recommended configuration is almost always “everysec”, but with the disclaimer, “you may lose 1 second of data if there is a disaster”. These warnings about safety should cause anyone in technical leadership to pause and ask some questions.

Even now in 2024 Redis seems to be the dominant queue persistence database in OSS, but it wasn’t designed to match the use case of a guaranteed job delivery system. Seeing the growth of open source Postgres-backed queues makes me optimistic that over time more development teams realize this mismatch and we’ll see a decline in popularity of the Redis queue projects. If your product relies on Redis for its queue, I encourage you to review your disaster recovery plans and server configurations. It’s concerning that the popularity of the “just use Redis for your queue” is likely producing a large population of applications vulnerable to losing jobs.

In 2015, the number 1 hit on Google for “Postgres job queue” was Brandur Leach’s “Postgres Job Queues & Failure By MVCC” blog post. LOL! The Internet replied with “don’t do this”. However, at this same point in time Postgres 9.5 was in beta and about to be released, and lo and behold a new core feature was added called SKIP LOCKED. This looked like a perfect fit, but it was too new for any packages to have this approach. After a successful prototype, I thought it seemed like a good opportunity to try creating the package myself, since I was new to Node and wanted to learn more about it. I started building it on nights and weekends, shipped version 0.0.1 in early 2016 then finally released 1.0 a year later.

How do you manage contributions and feature requests?

The best thing about OSS in my opinion is in its name: “open”. Having the entire world of developers not only use your software, but also be able to read its code and make contributions produces the highest quality code. You will get questions you never thought about, and find bugs you didn’t know existed. In the case of bug fixes, most of the time it’s as simple as making sure said bug has a new unit test then merging a pull request (PR).

Managing feature requests is not easy, however. If you don’t accept any contributions, it seems to violate the principle of OSS. If you accept every contribution, you risk the project drifting away from its original design or becoming too complicated. The balance between these extremes is evaluating each feature request against what seems to be best aligned with the core purpose of the project. This becomes a non-technical decision sometimes, and may result in a “let’s agree to disagree” outcome. My desire is to try and merge all PRs that arrive, and I really appreciate all the contributors that have sent them. It’s not fun saying “no”, because someone put in the coding effort and they felt strongly enough about it to spend their free time on your project.

What are the unexpected challenges of managing a successful open-source project?

I did not expect how time-consuming managing an open source project would be. This is probably the primary reason projects become abandoned over time if they are supported by only 1 or a few developers. For example, you could have a perfectly functioning code base in Node 0.12, then decide to upgrade to async/await later and have to rewrite everything. The same applies to changing a test suite, assertion package, or even striving to attain 100% code coverage.

Using Postgres as a queue solution has become quite popular recently :) What are your thoughts on differences between pg-boss and e.g. pgmq?

This is encouraging to see. I learned about pgmq from this question. It looks like a great option for a pure SQL implementation as a Postgres extension. I haven’t used it so I won’t be able to offer a detailed comparison, but after a quick review I see it uses SKIP LOCKED and a partitioned job table, which are good baseline scalability requirements. Postgres extension version management is challenging, however, and usually involves database service restarts and downtime.

What is the largest scale you’ve seen or heard pg-boss used at? How scalable / how far can you go with running background jobs directly in pg?

In terms of job storage, we’ve been able to store 2-3 million jobs in v9’s shared job storage and survive, but not really thrive, as database performance starts to degrade. Before v10, in order to mitigate this you have to use configuration settings to move completed jobs into the archive more often.

Once record counts are under control, in terms of job throughput, the number of concurrent queries to Postgres can be very high, especially when using connection poolers and job batching. I have a speed test in the suite that can both fetch and then complete 10,000 jobs in 0.5 seconds, a metric you would not easily be able to achieve even in some dedicated queuing products. For job creation on the other hand, you have the full power of SQL available in Postgres via INSERT or even COPY.

Did you know that Wasp uses pg-boss under the hood? We built Wasp Jobs on top of pg-boss, and here's how we did it.

While pg-boss has many production use cases, is there a scenario or limit where teams may need a traditional queue instead?

Because of the limitations in v9, we use pg-boss and AWS SQS side by side. Some of our queues rely heavily on pg-boss’s rate limiting and uniqueness features. We use SQS for queues that can grow very large quickly. Now that we’ve upgraded to v10, we might consider switching back for cost reasons, since SQS is not cheap at this scale.

There is a new version of pg-boss v10, what should people be excited about?

pg-boss v9 and below uses a shared job table across all queues. Once you run into the storage limitations mentioned earlier, all queues are affected. This is especially problematic since queues were also used internally for maintenance and scheduling. Maintenance controls archival, so if this queue can’t be processed, it prevents pg-boss from auto-recovering from this via the retention policy.

The design goal in v10 was to mitigate this performance issue first by isolating each queue into a dedicated table via partitioning. If a queue were to become backlogged with millions of jobs, it would affect the performance of that queue only. Then, if needed, you could use the newly added deleteJob() function in your workers, inspired by AWS SQS, to keep the record count as low as possible.

Another very useful new feature is queue policies. Over the years there were several issues opened around worker concurrency, which added several functions and configuration which made the API more complicated and difficult to understand. For example, there was a function sendSingleton(), which behaved entirely different from a configuration option named enforceSingletonQueueActiveLimit. In v10, these were all removed in favor of queue policies. A couple of examples are “short” queues, which only allow 1 pending job, no matter how many jobs are submitted, and “singleton” queues, which allow only 1 job to be active.

There are several other enhancements made to improve quality of life in v10:

All jobs have 2 retries enabled by default
FIPS compliant (dropped internal usage of MD5 hashing)
Replication support for HA or read-replicas (every table now has a primary key)
Serverless function supervision (maintain() function that can be run from another scheduler)
Postgres dependency-free (no pgcrypto extension needed uuid generation)
Dead letter queues (Replaces “completion job” feature and gains retry support for processing them)
What are your thoughts on things like pg_render which is a way to render HTML in Postgres? Is that going too far?

Since I’m a Postgres fan, it’s hard for me to see how adding more capabilities to it would be considered “going too far”. This particular project appears to be a simple abstraction of other open source packages and could be a useful case study of creating a Postgres extension in Rust. Since this is compiled, it should even have better performance benchmarks over other packages with the same feature in non-compiled languages.

Overall, I agree with the argument for simplicity in Stephan Schmidt’s article “Just Use Postgres for Everything”. The only issue with his article, which he continues to edit after all these years, is Stephan recommends River, a new OSS queue using SKIP LOCKED in Go, when we could have just mentioned little ole pg-boss that’s been around for years. The irony is that River was built by Brandur “don’t use Postgres queues” Leach. I’m kidding around here, of course, but who doesn’t enjoy a bit of irony?

What advice would you give to developers or companies who are thinking of open sourcing their projects?

For developers, I would encourage starting off by making a contribution to a package you use daily. For example, if you’ve ever thought “I like this package, but I think it could be better if it had this feature”, that might be something you could add. If you have an idea of a new project, my advice would be to focus on the MVP (minimally viable product). The more features you add, the more time required to release it and the more maintenance required to keep it running. This is the primary reason I don’t include a web API or UI with pg-boss, even though I’m sure it would make it more popular.

For companies, I would point to successful startups that became popular and attracted funding because of their OSS projects. TimescaleDB, Supabase, and Citus are examples just from the Postgres ecosystem.

What is the main reason you keep working on pg-boss? What do you get out of it?

It’s nice to be able to change what type of development you do occasionally. It gives you a different perspective and usually gives you new insights into your primary job. When you have responsibility over a popular package, it also adds some motivation to make sure it remains healthy. It’s not a good feeling when your package causes bad performance on a database server because of its own success (a large queue backlog could mean your company is growing). I did sign up for GitHub Sponsors a couple years ago, and I appreciate every company and developer that has benefited from pg-boss making contributions, but it’s still far from being able to fund itself.

Have you ever thought of introducing a paid product on top of pg-boss? Why yes/no?

I haven’t spent time evaluating what that would look like, but it is an intriguing idea for sure. If I was able to work on pg-boss full-time, there are several potential new concepts that could be explored now that partitioning and queue policies have been created.

For example, someone recently opened an issue to request arbitrary JSON querying capability to be included in fetch(). If done globally across all queues, this would require indexing the jsonb payload, which in some cases could be large, slowing down reads and writes. However, if applied only to a single partition, this index could be isolated to only the queue that needs it via a new policy. Postgres allows different indexes and unique constraints between tables within the same partitioning hierarchy, which could be used for this policy.

Furthermore, very large partitions could even have subpartitions, creating a tree-like structure for scalability purposes. This strategy has already been proven at scale in Postgres by the TimescaleDB team, and could potentially result in removing its storage capacity challenges entirely.

Yet another area of exploration is encapsulating all features into Postgres functions to make the logic of pg-boss more easily integrated with non-Node.js platforms, as most of the logic in pg-boss is actually already pure SQL. Some have also mentioned to me that it would be nice if we had a standard queue data schema that could be shared across platforms, which sounds like a noble goal, but challenging since it would involve collaboration across OSS projects to complete.

Apart from yours, is there an open source tool or project you’re particularly excited about?

I’m a big fan of Supabase at the moment. I’m currently evaluating their use of JWT claims and Postgres RLS for SaaS multi-tenancy. They have open sourced several of their projects as well, such as supavisor, a connection pooler. Their product also happens to use pg-boss internally, which means… “they use pg-boss btw” 🙂

Hope you enjoyed this interview, and stay tuned for the next one!

⭐️ Star Wasp on GitHub 🙏

It's the easiest way to support open-source initiatives like ours.

The Easiest Way to Monitor Ruby: Automatic Instrumentation

Milica Maksimovic — Thu, 17 Jun 2021 13:56:54 +0000

Setting up a proper monitoring overview over your application's performance is a complex task. Normally, you'd first need to figure out what you need to monitor, then instrument your code, and finally make sense of all the data that has been emitted.

However, with a few things set in place, and an APM that natively supports Ruby, it's easier than ever to take this step. In this post, we'll show you how you can do it too.

Automatic Instrumentation - Handsfree APM Setup

To discover which pieces of your code are causing your performance issues, you’ll need to add instrumentation to it. That way, you can break down all the actions and measure which ones are the slowest.

With AppSignal’s automatic instrumentation, we take away as much manual work as we can. Just run a few commands through the CLI, and you’ll be set.

Our monitoring agent detects the different parts of your infrastructure and automatically instruments it. This enables AppSignal app to digest, process, monitor, and show you the graphs and dashboards you need the most.

That means that for example for the graphql gem for Ruby, AppSignal will instrument every GraphQL request that comes in, meaning it will provide a breakdown of all events in the request.

Out-of-the-box Instrumentation

We've made a list of all the tools AppSignal supports. It's pretty extensive:

Type	Tool
Framework	Rails
Rails features	Action Mailer
Rails features	Action Cable
Rails features	Active Record
Rails features	Active Job
Rails features	Caching
Supported through ActiveRecord	PostgreSQL, MySQL, SQLite, etc.
Heroku integration	Heroku PostgreSQL
Framework	Padrino
Framework	Sinatra
Gem	Rack
Gem	WebMachine
Web server	Puma
Web server	Unicorn
ORM	DataMapper
ORM	Sequel
ORM	MongoDB
API	Grape
API	GraphQL
Standard library	Net::HTTP
Background job	Que
Background job	Sidekiq
Background job	Delayed Job
Background job	Resque
Background job	Shoryuken
Gem	Rake

As I've said, the list is pretty long, which is why we won't dive into each and every tool in this post.

Web Frameworks and APIs

AppSignal supports instrumentation of web requests in Ruby on Rails, Padrino, and Sinatra out-of-the-box. APIs using Grape or the GraphQL gem are also supported.

Ruby on Rails

The AppSignal integration for Rails works by tracking exceptions and performance in requests. When an error occurs in a controller during a request AppSignal will report it. Performance issues will be based on the duration of a request and create a timeline of events detailing which parts of the application took the longest.

It's even possible to track how long it took for HTTP requests to arrive at the Rails app through a loadbalancer of web server. If it's not on by default, set up the request queue time tracking header and AppSignal will automatically graph the queue time.

GraphQL

AppSignal supports the graphql gem for Ruby. It will instrument every GraphQL request that comes in and provide a breakdown of all events in the request. You'll be able to see how long it took to parse, validate and execute your resolvers. Events from the app's web framework and database calls are of course included in this breakdown.

This is great for those who wish to debug GraphQL queries that seem to take a long time, and you're not sure where the slowdown could be occurring. Don't forget about our anomaly triggers here also - these can be very useful for alerting when the query time reaches a certain threshold.

Sinatra, Padrino and Grape

Sinatra, Padrino and Grape are web and API frameworks for Ruby that can be part of an app in different ways. They are either a standalone app or mounted on a larger Rails app. Depending on how the app is mounted on a web server some different installation steps are needed for Sinatra, Padrino and Grape.

Once installed Sinatra, Padrino, Grape requests are all instrumented: errors and performance measurements are reported when traffic hits the API. Every (API) endpoint is its own action in AppSignal to easily find which endpoint encountered which error. As with Rails apps the performance breakdown provides insight in what database queries or other parts or the app were slower than others.

Databases

Active Record and other ORMs

To see how long a request took querying the database, open a incident detail page. On top of the page the types of events recorded in the request are broken down per group. Here you can see how much time in total was spend on what type of operation.

If we zoom in further on the performance of this sample, further down the page you'll find a timeline of all events in the request in the order they occurred. This provides you with an overview of each query that was executed and which ones are taking the longest.

The integration shows you the tracing for database calls, so you can see what query is the root of your evil (or genius) 😉

N+1 queries

Worried there may be N+1 queries occurring in the request and that's what is slowing it down? If we detect N+1 queries a warning will appear in the event timeline for those events that were detected.

Redis

With Redis integration, you'll see your calls to Redis appear in the Event Timeline:

You'll also be able to see the name of the command sent to Redis and the address of the Redis instance that the query was made to:

This is great news for those who wish to debug long running calls to a Redis cache. You can even set an anomaly trigger to send an alert on requests that run for a super long time!

Background Jobs

Whenever a background job is queued with Sidekiq, Delayed::Job, Resque, Shoryuken and Que AppSignal will automatically report errors and performance measurements. All Active Job adapters are also supported, and some background job libraries like Sidekiq and Delayed::Job report even more metadata from the libraries themselves.

Sending emails with Action Mailer

If Rails mailers using Action Mailer are set up to deliver_later they will also be routed through Active Job and can count on the same level of instrumentation.

Websockets

Using Action Cable in your Rails app? AppSignal automatically reports errors and performance measurements for messages and subscriptions. Every message is instrumented separately so even long running channels will report all activity. They are grouped per action giving a clear overview of how each individual action is performing.

Try AppSignal: Monitoring Made Easy And Sweet 🍪

Over the past 7 years, we've helped thousands of developers to automatically instrument their code, and we'd love you to try us out as well. When you do, feel free to reach out, we'll send you a free box of stroopwafels as well.

PS. If you are helping the world with a great OSS project, we help you back with a free AppSignal account. Spread the word to the maintainers you value!

Difficult Things About Difficult Discussions at Work

Milica Maksimovic — Wed, 28 Apr 2021 14:51:07 +0000

I'm writing this post for those who struggle with discussing social/political or any other sensitive topics within their workspaces. Placing a ban on discussions is not the right approach. Instead, let's teach people on how to have deep, meaningful, and respectful discussions.

I'm obviously inspired by the whole Basecamp thing. The one thing we’re not seeing is the tone of the internal communication about difficult things. We just see how they decided to handle it.

Just to be clear, I'm all up for diversity and against most of the steps Jason and David decided to take.

You need to be open for discussion

Drawing from my past experiences, there have been times when I was taking part in sensitive discussions. The most difficult thing when discussing things you’re sensitive about or feel strongly about is not to dismiss the other side. Having a meaningful discussion is very different from having a heated argument.

Polarisation, and looking at things as being either black or white isn’t helpful. It’s really easy to call out people for their behavior, and if the tone is accusative or aggressive, they start playing defense…. and then there’s no conversation.

How to approach people

I honestly believe that once you approach people in a calm manner, without being accusative, and try to understand why they do some things the way they do, and get them to see another perspective is the way to grow. For both parties. But both parties have to be open to challenging their own views.

It’s easy to approach someone and say “That’s wrong”. Instead, “Hey, can you help me understand why you [think this, did that, you name it]?”

Postponing the discussion is also ok

There are days when the topic we care deeply about makes us too emotional and we instinctively “defend” our position. It’s crucial to recognize those moments and retreat, because hot-headed people can’t have a meaningful discussion. It also takes away a lot of energy.

In some instances, the other party may be too emotional as well. It's important to take that into consideration, and voice that you have nothing against them, and that you're just interested in learning about their perspective and understanding them better. If that doesn't help, postpone the conversation or just back away.

Opinions can change

To end it with some personal examples:

It took me years to figure out that the person I had so many heated arguments about LGBT rights and to whom I stopped talking to was struggling to come out. A couple of years ago that one approached me and actually apologized and thanked me for talking openly about some stuff on my FB account.
It also took me years to fully accept myself. This is why I also get why there are others who struggle to understand me or understand the struggles I face in my daily life.

Understand that people can grow and change their opinions, and that some people just view the world differently. It's all ok as long as we're all being respectful and not harming others in any way.

Things are ~~never~~ rarely black and white.