DEV Community

EP3: Native Kubernetes deployment is officially working in Coolify. But getting there meant wrestling with vicious race conditions.

drtobbyas — Mon, 11 May 2026 07:19:14 +0000

If you missed Episode 2, we realized that Coolify's SSH-native engine is surprisingly cluster-friendly. The architecture wasn't locked to Docker; it simply lacked a translation layer.

In Episode 3, it was time to build that translation layer and prove the concept. But turning theory into reality required two massive, distinct phases of implementation and this led to one of the most stressful race conditions I've ever debugged, all while I was backpacking across 4 countries.

Here is the story of how the Kubernetes Proof of Concept (POC) came to life.

🏗️ Phase 1: The Struggle for a Cluster

Before you can deploy an application to a Kubernetes cluster, you must actually have a cluster to deploy to.

This was the first major hurdle. The official Coolify deployment currently has zero built-in Kubernetes infrastructure. I knew that I couldn't just build a deployment script without giving users a way to actually spin up an environment to test it on without leaving the UI.

I spent days searching around, reviewing so many different options for how to bootstrap a cluster natively. Ultimately, I settled on K3s. It is an incredibly lightweight, production-ready Kubernetes distribution that is perfectly suited for the types of servers Coolify normally runs on.

I integrated it directly into the frontend. I built out the UI and the underlying backend logic so that users can now do two things straight from the dashboard:

Spin up a brand new K3s cluster from scratch on a server.
Link securely to an existing Kubernetes cluster.

Phase 1 was a resounding success. I had the foundation.

🌍 Phase 2: Racing Across Borders

As I moved into Phase 2, life happened. I had to pause active work while I took a 5-day tour across 4 different countries.

But while I was navigating borders, the codebase I had just written to handle my deployments was locked in an intense race condition of its own.

I was literally racing across borders while trying to stop my codebase from "racing" and locking up the UI.

Here is what went wrong.

🐉 Deploying the Docker Image & Fighting the Clock

The second phase of the POC was the grand finale: taking a standard Docker image (I used Nginx), deploying it as a service directly to the K3s cluster I had just created, and ensuring it was accessible via an Ingress route.

The translation script worked flawlessly. My Docker manifests were effortlessly converted into K8s Deployments, Services, and Traefik Ingress rules. But making the status UI sync was a nightmare.

To ensure the deployment succeeded, I initially set the core action to run synchronously. The deployment worked! But because it waited for the cluster to finish, it held the PHP process hostage and completely locked up the Coolify frontend.

"Simple," I thought. "Just revert the deployment to an asynchronous background job."

The UI immediately became snappy again. But this introduced the ultimate syncing problem. The moment the async deployment fired, Coolify's Application Status Checker instantly polled the K8s API.

Because Kubernetes is eventually-consistent, it takes a few seconds to pull the image and schedule the pods. The API responded, accurately, that there were zero pods running. Instead of understanding that the app was just booting up, the Coolify orchestrator aggressively flagged the perfectly healthy deployment as "Exited" or "Failed."

A fully functional deployment was showing a glaring red error state.

🚀 The Resolution: The POC is Alive

You cannot force an intrinsically asynchronous system (Kubernetes scheduling) to behave linearly against a strict synchronous status check. The absence of a resource immediately after creation is an expected state, not a failure.

I solved the "racing codebase" by injecting an intelligent, two-minute graceful memory window into the status pipeline. If the checker polls an application within two minutes of an update and finds zero pods, it simply holds the UI status at "Starting" until the pods are scheduled. The moment the K8s API confirms the pods are healthy, it seamlessly flips the interface to "Running."

The end-to-end "Docker Image -> K8s" flow is now incredibly fast, fully observable, and completely robust. I conquered the K3s installation, I defeated the deployment race conditions, and I proved that Native Kubernetes fits perfectly inside Coolify.

⏭️ Next in the Investigation

Letting the automated systems handle the eventual consistency of Kubernetes meant I could actually close my laptop and enjoy the rest of my tour across countries. But the work is far from over.

Next up, I dive deeper into linking external production clusters and polishing the features for robust availability. You will not want to miss what's coming next!

GitHub Issue: https://github.com/coollabsio/coolify/issues/2390

Connect with me: Twitter/X, Linkedin, Telegram

This is the third post in a series documenting my investigation into building native Kubernetes support for Coolify. Next up: Connecting robust external clusters.

Suggix Weekly: Stop Building Everything: Let Users Decide What Matters

Mike — Mon, 11 May 2026 07:17:00 +0000

One of the most common traps founders fall into—especially indie hackers and small SaaS teams—is believing that every piece of user feedback should become a roadmap item.
A user asks for a feature. It sounds reasonable. Maybe even urgent.
So you build it.
Then another request comes in. And another.
Before long, your product becomes a patchwork of half-used features, your roadmap is bloated, and your velocity slows to a crawl.
The hard truth is this:
Not all user feedback should be built.
The real skill isn’t listening to users—it’s knowing what not to build.
The Feedback Fallacy in Feature Prioritization
We’re often told to “listen to your users.”
That advice is correct—but incomplete.
Users are great at identifying problems:
“This workflow is slow”
“I wish I could export this”
“This doesn’t integrate with X”
But they are not always good at proposing solutions.
When you treat every suggestion as a feature request, you end up:
Solving symptoms instead of root problems
Building edge-case features for a few loud users
Losing clarity on your product’s core value
In other words, you stop building a product—and start managing a backlog.
A Real SaaS Problem: Backlog Overload
A small SaaS team (12 people) once shared their situation publicly:
They had accumulated over 1,000 feature requests.
At first, it felt like progress—users were engaged, feedback was flowing.
But internally:
No one knew what to prioritize
Engineers were constantly context-switching
Product decisions became reactive instead of strategic
Most importantly, very few of those 1,000 requests actually mattered.
They weren’t building what was important—they were building what was visible.
Signal vs Noise in User Feedback
User feedback is not equal.
It’s a mix of:
High-signal insights → core product gaps
Low-signal noise → preferences, edge cases, one-offs
Without a system to separate the two, everything feels equally important.
And when everything is important, nothing is.
Feature Prioritization Starts with Validation
Instead of asking:
“Should we build this feature?”
Ask:
“How many users actually need this?”
This is where most teams fail.
They collect feedback—but don’t validate demand.
A single request ≠ a real problem
A repeated pattern across users = opportunity
Let Users Vote: A Better Way to Prioritize Features
One of the simplest but most effective ways to manage user feedback is this:
Stop collecting feedback in isolation. Start aggregating it.
When users can see and vote on existing requests:
Duplicate ideas collapse into one
Demand becomes measurable
Priorities become obvious
Instead of 50 scattered requests, you get:
One request with 120 votes.
That’s signal.
Tools like Suggix are designed around this exact model—helping teams centralize feedback, merge duplicates, and prioritize features based on real user demand instead of assumptions.
Case Study: From Chaos to Clarity
An early-stage SaaS product introduced a public feedback board with voting.
Before:
Feedback was scattered across email, chat, and support tickets
Ideas were tracked manually in spreadsheets
Prioritization relied on gut feeling
After:
All feedback lived in one place
Users voted on existing ideas
The team quickly identified the top 5 most requested features
The result:
They shipped fewer features—but saw significantly higher adoption.
Because they were finally building what users actually cared about.
Why More Features ≠ More Value
There’s a common assumption in SaaS:
More features = more value
In reality:
More features → more complexity
More complexity → worse UX
Worse UX → lower retention
Great products don’t win by doing more.
They win by solving a small number of problems extremely well.
The 80/20 Rule in Product Usage
In most SaaS products:
20% of features drive 80% of usage
The rest are rarely touched
Yet teams spend most of their time building the 80%.
Why?
Because those features are:
Easier to implement
More visible (users explicitly request them)
Less risky than making bigger decisions
But optimizing for “easy wins” leads to long-term stagnation.
A Practical Feature Prioritization Framework
To prioritize effectively, evaluate every request across three dimensions:

Demand (User Signals) How many users want this? Votes Frequency of requests Repeated patterns
Impact (Business Value) Will this improve: Retention Conversion Revenue
Alignment (Product Vision) Does this fit your long-term direction? If a feature scores high on all three → build it. If not → it’s likely a distraction. When Voting Alone Is Not Enough Voting is powerful—but not perfect. Be careful when: A small number of high-value customers dominate revenue Users don’t yet understand what’s possible You’re building something fundamentally new In these cases, combine: User signals (votes) Product intuition Strategic bets The goal isn’t democracy. It’s informed decision-making. Practical Steps to Manage User Feedback in SaaS If your backlog is getting out of control, start here: Centralize feedback→ Stop collecting ideas across scattered channels Merge duplicate requests→ Reduce noise and fragmentation Introduce voting→ Let users signal priority Identify top feature requests→ Focus on highest-demand items Say no clearly→ Archive or reject low-impact ideas Close the loop→ Tell users when features are shipped

FAQ: Feature Prioritization & User Feedback
How do you prioritize feature requests in SaaS?
Use a combination of:
User demand (votes or frequency)
Business impact (retention, revenue)
Product alignment
Avoid prioritizing based on individual requests alone.
Should you build every user request?
No.
Most user requests represent symptoms, not solutions.
Focus on identifying patterns instead of reacting to isolated feedback.
What is the best way to manage user feedback?
The most effective approach is to:
Centralize feedback
Aggregate similar requests
Let users vote
Prioritize based on validated demand
Platforms like Suggix help automate this process and turn feedback into clear product decisions.
Final Thought
Building a great product isn’t about doing more.
It’s about doing the right things.
Your users don’t need you to build everything they ask for.
They need you to understand what truly matters—and deliver on that.
So the next time a feature request comes in:
Pause.
Measure.
Validate.
And let your users decide—together—what’s actually worth building.

original:

Stop Building Everything: Let Users Decide What Matters | Suggix

suggix.com

Let’s Talk About Micromanagement....

Alexi — Mon, 11 May 2026 07:16:07 +0000

Is Micromanagement Sometimes Good and Necessary?

Let’s Talk About Micromanagement....

The dictionary defines micromanagement as “to direct or control in a detailed, often meddlesome manner.” Micromanagement can lead to destructive leadership, which in turn may harm the company’s interests, create a toxic work environment, and reduce employee productivity and motivation.

When Micromanagement Makes Sense?

There are situations where it can be helpful, but only temporarily (from 1 week to 1 month):

*Onboarding a new employee to your team *

At first, even skilled professionals may need direct, hands-on guidance in certain areas to adapt to the workflow and understand the product quickly. This focused support can accelerate their integration. The key is to know when to give them space to work independently.

*Introducing a trainee or junior to a project *

For less experienced team members, close supervision helps them learn faster, avoid common pitfalls, and build confidence before taking on more autonomy.

*Managing high-risk projects *

When mistakes could have serious consequences, maintaining tight control in the early stages can protect outcomes while the team aligns on expectations.

In these cases, focused micromanagement helps ensure success while gradually transitioning to greater independence.

Micromanagement might look like a good way to make sure everything gets done correctly, but in the long run, it usually backfires. Trust, autonomy, and open communication go much further than constant oversight and help create an environment where teams thrive, innovate, and reach their full potential. Finding the right balance between freedom and control is what a good manager is really about.

How I Built 7 AI Systems to Run a Social Media App — Architecture Deep Dive

Rifat — Mon, 11 May 2026 07:15:19 +0000

When I started building Qioiper, I had one architectural constraint that shaped everything: the platform could not optimize for screen time.

This sounds simple. It isn't. Every major social platform — Instagram, TikTok, Twitter — runs on engagement-maximization algorithms. The entire infrastructure of modern social media is built to answer one question: how do we keep users on longer?

Building against this required not one AI system, but seven. Each one handles a specific part of the problem. Here's the architecture.

## The Core Problem With One Algorithm

A single engagement-optimization algorithm creates a specific failure mode. It surfaces content that provokes reaction — outrage, envy, anxiety — because those emotions drive clicks. It can't simultaneously optimize for content quality, user wellbeing, creator reach, platform safety, and meaningful connection.

You need specialized systems. Here's how I built them.

## System 1: Content Guard

Stack: Python, custom classifier, real-time inference pipeline

What it does: Screens every upload before it reaches the platform. Not after. Before.

Most platforms moderate reactively — content goes up, gets reported, eventually gets reviewed. By then the damage is done. Content Guard operates at upload speed, running parallel inference against multiple violation categories simultaneously.

The challenge: Latency. Real-time moderation at upload speed means you have milliseconds, not seconds. The solution was a tiered approach — fast lightweight classifier for obvious violations, heavier model for edge cases, human review queue for genuinely ambiguous content.

System 2: Copyright Guard

Stack: Audio fingerprinting, video hash comparison, metadata analysis

What it does: Detects copyright violations in video and audio before publishing.

This goes beyond simple hash matching. Copyright Guard analyzes audio waveforms for music detection, compares video segments against a reference database, and flags content that's been re-encoded to avoid fingerprinting.

Why it matters: Creators on Qioiper own their work. That requires protecting original content from unauthorized reproduction — and protecting users from unknowingly consuming it.

System 3: CLIP AI

Stack: OpenAI CLIP, fine-tuned for platform content categories

What it does: Understands what content actually is — not just its filename or hashtags.

CLIP (Contrastive Language-Image Pretraining) is a multimodal model that understands the relationship between images and language. On Qioiper, it serves as the content intelligence layer — reading the actual visual and semantic meaning of uploaded content.

Practical impact: Instead of distributing content based on hashtags, Qioiper distributes based on what the content actually shows. A photographer's work reaches people who genuinely appreciate photography, not just people who followed a generic tag.

Secondary function: Context-aware moderation. A word or image that's harmful in one context is neutral in another. CLIP understands the difference. This dramatically reduces false positives compared to keyword-based systems.

System 4: Feed Ranker

Stack: Collaborative filtering + content-based signals, custom ranking model

What it does: Determines what each user sees — without optimizing for engagement.

This is where most social platforms make their most consequential decision. The Feed Ranker on Qioiper optimizes for relevance, not reaction. The signals it uses:

Content-user interest alignment (via User Profiler data)
Content quality score (via CLIP AI)
Creator trust score
Temporal relevance (content lifecycle stage)

What it deliberately ignores: predicted engagement rate. A post that will get 100 genuine reactions from relevant users ranks higher than a post that will get 10,000 reactions from irrelevant users.

System 5: User Profiler

Stack: Behavioral sequence modeling, interest graph construction

What it does: Builds a behavioral model of each user over time — interests, engagement patterns, content preferences, active hours.

This isn't surveillance. It's the same kind of learning that makes any recommendation better with use. The User Profiler feeds into every other system, making each one more accurate as it learns.

Privacy approach: All profiling data stays on-platform and is used exclusively for the user's benefit — better recommendations, better timing, better content matching. It's never sold or used for advertising targeting.

System 6: Notification Generator

Stack: Multi-armed bandit optimization, user behavioral signals

What it does: Decides what's actually worth notifying you about.

Most platforms send notifications to maximize re-engagement. Qioiper's Notification Generator has a different objective function: maximize the ratio of meaningful notifications to total notifications.

In practice this means: fewer notifications, but higher signal-to-noise ratio. When Qioiper sends you a notification, something genuinely relevant has happened — not a manufactured trigger designed to pull you back.

Technical approach: The system models each user's notification tolerance and adjusts frequency dynamically. Users who respond positively to more notifications get more. Users who dismiss or ignore notifications get fewer, with higher relevance thresholds.

System 7: Timing Optimizer

Stack: Time-series behavioral analysis, audience activity modeling

What it does: Identifies the Golden Moment — the exact window when a specific creator's audience is most active and receptive.
Research consistently shows creators lose up to 70% of potential reach by posting when their audience isn't active. The Timing Optimizer solves this by building a behavioral map of each creator's audience — not a generic "best time to post" recommendation, but a specific prediction based on that creator's actual followers.

How it works:

Aggregate activity data for users who follow a given creator
Identify peak activity windows by day and hour
Cross-reference with content type (Flash vs Memory vs Forever have different optimal windows)
Surface the recommendation in the posting interface before the creator hits publish

Update frequency: The model recalculates continuously as the creator's audience grows and behavior shifts.

How the Systems Work Together

These seven systems aren't independent — they form a pipeline:

Upload → Content Guard → Copyright Guard → CLIP AI → Feed Ranker ← User Profiler → Notification Generator → Timing Optimizer

Content Guard and Copyright Guard are gates — content that doesn't pass doesn't enter the pipeline. CLIP AI enriches the content with semantic understanding. Feed Ranker uses that enrichment plus User Profiler data to make distribution decisions. Notification Generator and Timing Optimizer handle the delivery layer.

What I'd Do Differently

Latency on Content Guard. The tiered approach works but the edge case queue creates unpredictable delays for content that requires deeper analysis. A better architecture would use distillation to make the heavy model faster rather than routing to it selectively.

User Profiler cold start. New users have no behavioral history, so initial recommendations are generic. I'm exploring ways to bootstrap the profiler faster — either through explicit interest signals at onboarding or through transfer learning from aggregate patterns.

Timing Optimizer for small audiences. The model works well for creators with established audiences. For new creators with few followers, the behavioral data is sparse and predictions are less reliable. This is an active area of improvement.

Stack Summary

Mobile: Flutter
Backend: PHP (migrating to more performant stack)
AI/ML: Python, custom models + CLIP
Infrastructure: Cloudflare
Compliance: GDPR, KVKK, COPPA

If you're building something similar or have questions about any of the systems, happy to go deeper in the comments.

Qioiper is available on Android: Google Play

Every digital product seller has done some version of this calculation: "10% fee isn't bad. That's just the cost of doing business." Then you actually do the math for a year. And you realize 10% of $20,000 is $2,000 — and you could have kept most of that

Aoi Nakamura — Mon, 11 May 2026 07:13:21 +0000

Why QR Codes Expire (It's Not the Code — It's the Server)

Nacho González — Mon, 11 May 2026 07:10:12 +0000

Most explanations of QR code expiration say "your subscription expired" as if that's the full story. It's not. QR codes don't expire — the redirect infrastructure that dynamic codes depend on gets switched off, and every scan after that moment hits a dead server instead of your content.

Here's how it works at the architecture level, and why it matters if you're building anything that touches physical print.

Static vs dynamic: two completely different architectures

A static QR code encodes your destination URL directly into the pixel pattern using the ISO/IEC 18004 standard. No server, no lookup, no dependency. Scan it and the camera decodes the URL from the image itself. It will keep working as long as the physical print is readable and the destination URL is live.

A dynamic QR code encodes a short URL owned by the QR platform — something like qrtg.io/abc123. The camera sends an HTTP GET to that short URL. The platform's redirect server looks up where abc123 maps to and returns a 302 to your real destination.

Scan → GET https://qrtg.io/abc123 → 302 → https://yoursite.com/landing-page

That redirect server is what expires. The QR image never changes. The infrastructure behind it does.

The four ways the redirect stops working

1. Subscription cancellation

Payment fails or you cancel → platform downgrades your account → redirect server stops responding for your codes. On most platforms this is instant. No grace period. A billing failure at 2 AM means codes are dead before your staff shows up at 8 AM.

2. Trial end

You created codes during a 30-day evaluation. Didn't convert. Codes created during the trial deactivate on day 31. If you printed those codes before deciding not to subscribe, the materials are already broken.

3. Scan cap hit

Free tiers usually cap dynamic codes by scan count. As of April 2026:

QR Tiger free: 500 total scans per code
Flowcode free: 2 active codes, 500-scan analytics limit

Hit the cap and the redirect returns an error, even if your account is fully active. The counterintuitive part: a high-traffic QR code burns through its cap faster. Success triggers failure.

4. Platform shutdown

The redirect domain goes offline permanently. Every QR code that ever pointed at platform.io/r/... is unrecoverable. The QR code industry saw real consolidation in 2023–2024 — smaller platforms shut down or got acquired, and physical materials printed with those platforms' short URLs became permanently dead.

Why this is a harder problem than it looks

The subscription cycle and the physical materials lifecycle operate on completely different timescales.

A business prints 10,000 product boxes with a QR code. The boxes have an 18-month shelf life. Annual subscription renews fine the first year. Card gets updated, auto-renewal misses, subscription lapses six months before the last box ships.

Every box still on shelves now has a broken QR code. No one on the vendor's side knows. The platform sends no notification. The brand finds out when a customer mentions it.

Our support ticket data at QR Nova shows the average gap between a dynamic code going offline and the owner finding out via a customer report is 4 days. That's 4 days of scans hitting error pages for a product that's physically present and being handled by end users.

The silent failure mode is the real problem. When a code dies:

The scanner gets a generic 404 Not Found or a platform error page
No message saying "this QR code is deactivated"
The user assumes their phone has a bug, or the product is broken
The brand takes the hit invisibly

What actually matters when choosing a QR platform for print

If you're embedding QR codes in anything physical — packaging, signage, product inserts, printed menus — the most important question isn't "what features do you offer." It's:

What happens to my codes if I cancel tomorrow?

A platform that immediately deactivates all dynamic codes on subscription change is a liability for print use cases. A platform with a grace period or permanent code retention is not.

Other things worth checking:

Scan cap alerts — does the platform email you before you hit the cap, or after?
Custom redirect domain — if you can point your own domain at the redirect service, you can migrate platforms without reprinting anything
Export options — can you get your redirect rules out if the platform shuts down?
Operating history — a platform that's been running for several years with a clear business model is meaningfully less likely to disappear than a well-funded startup with no obvious revenue

The architectural choice that avoids the problem

For any destination that won't change, skip dynamic codes entirely. Static QR codes have no server dependency. The URL is baked into the image. There's nothing to cancel.

For destinations that need to be editable — campaign URLs, seasonal redirects — dynamic codes are necessary, but the redirect service itself doesn't have to be gated by billing state. That's an architectural choice platforms make, not a technical necessity.

At QR Nova, we built the redirect service so codes stay active regardless of billing status. The redirect lookup is not coupled to account state. It's a simpler system to operate and it removes the liability for anyone printing QR codes on anything physical.

Static codes are free with no account required. Dynamic codes keep working after you close the tab.

Originally published on QR Nova

I Built a One-Command macOS Terminal Setup — Ghostty + Zsh + 30 Modern CLI Tools

satyamsoni2211 — Mon, 11 May 2026 07:06:08 +0000

Every time I set up a new Mac, I'd spend half a day doing the same thing — installing Homebrew, picking a terminal, configuring Zsh plugins, hunting for that one tool I forgot the name of, fixing a broken .zshrc. It was tedious, error-prone, and felt like something a script could handle.

So I built dev-accelerator — a one-command macOS terminal setup that gets you from a fresh Mac to a fully productive terminal environment in minutes.

What it sets up

╭─────────────────────────────────────────────────────────────────────────╮
│  dev-accelerator  ─  Ghostty + Zsh + 30 modern CLI tools                │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  ❯ ls                                                                    │
│  󰉋 src/   󰉋 tests/   󰉋 docs/    setup.sh   install.sh   README.md      │
│                                                                          │
│  ❯ git log --oneline                                                     │
│  a3f1c2e  feat: add zoxide smart cd integration                          │
│  b89d041  fix: backup .zshrc before modification                         │
│                                                                          │
│  satyam@macbook  ~/projects/dev-accelerator  main ✓  took 0.3s          │
╰─────────────────────────────────────────────────────────────────────────╯

Here's the full picture of what gets installed and configured:

Ghostty — a GPU-accelerated terminal emulator, pre-configured with the Catppuccin theme
Zsh with zsh-autosuggestions and zsh-syntax-highlighting
Starship prompt using the gruvbox-rainbow preset
Atuin — shell history that syncs across machines and is actually searchable
Zoxide — a smarter cd that learns your most-visited directories
FZF — fuzzy finder wired into your shell for files, history, and more
Mise — a single runtime version manager replacing nvm, pyenv, and rbenv

Plus a full suite of modern CLI replacements for the outdated Unix defaults you've been living with.

Modern CLI tools: out with the old

One of the best parts of this setup is swapping out stale Unix tools for modern, faster, friendlier alternatives:

Old tool	New tool	Why it's better
`ls`	`eza`	Icons, git status, tree view
`cat`	`bat`	Syntax highlighting, line numbers, git diff
`grep`	`ripgrep`	10–100x faster, respects `.gitignore`
`find`	`fd`	Simpler syntax, faster, colorized output
`cd`	`zoxide`	Learns your habits, jump with `z proj`
`top`	`bottom` (`btm`)	Beautiful TUI with graphs
`ps`	`procs`	Human-readable, colorized, searchable
`man`	`tealdeer`	Practical examples instead of dense manpages
git CLI	`lazygit` / `gitui`	Full TUI git workflows
`tar`/`zip`	`ouch`	One tool for all archive formats

One command to rule them all

curl -fsSL https://raw.githubusercontent.com/satyamsoni2211/dev-accelerator/main/install.sh | bash

That's it. The script:

Checks if Homebrew is installed — installs it if not
Dynamically checks which packages are already installed — skips them
Configures Zsh with all plugins
Sets up the Starship prompt
Creates the Ghostty config with Catppuccin theme
Backs up your existing .zshrc before touching anything
Sets Zsh as your default shell

The "backs up your .zshrc" part matters — I've seen too many setup scripts that just overwrite your config without asking.

Two ways to install

Not everyone wants to pipe a script into bash (fair!), so there's also a manual option:

Option 1: One-click (above)

Best for getting started fast on a new machine.

Option 2: Homebrew + setup script

git clone https://github.com/satyamsoni2211/dev-accelerator.git
cd dev-accelerator
./setup.sh

Gives you an interactive prompt to choose what to install.

2025/2026 tools worth knowing

Beyond the classics, the setup also includes some newer tools that have become part of my daily workflow:

Zellij — a terminal workspace (tmux alternative) with a much friendlier UX and built-in layouts
delta — a git diff pager with syntax highlighting that makes reviewing changes actually pleasant
tokei — counts lines of code by language, blazing fast
uv — the new standard for Python package management; it's dramatically faster than pip
direnv — automatically loads .env files when you enter a directory, unloads when you leave

What's next

A few things I'm planning to add:

Linux support (Ubuntu/Debian)
Neovim pre-configuration as an optional module
A --minimal flag for the install script (just shell + core tools, no terminal emulator)
iTerm2 as an alternative to Ghostty for those who prefer it

Give it a try

The project is open source under the MIT license.

👉 github.com/satyamsoni2211/dev-accelerator

If you try it out, I'd love to hear what tools you'd add or what your current setup looks like. And if you find a bug, issues and PRs are very welcome — see CONTRIBUTING.md to get started.

What's your go-to terminal tool that most developers haven't heard of? Drop it in the comments — I'm always looking for new additions.

Every AI Agent Failure I've Debugged in 2026 was an Idempotency Problem

Sven Schuchardt — Mon, 11 May 2026 07:06:03 +0000

Five real production incidents, the 25-year-old constraint that explains them all, and the three-layer architectural fix every agent team should have shipped last quarter.

Summary

The failure pattern looks different every time, and it is the same pattern every time.

A customer gets the same onboarding email fourteen times in nine minutes. A B2B account is charged twice for one subscription renewal. An order shows up in the OMS as three orders. A support ticket is created, escalated, re-created, re-escalated, and then closed as duplicate by a human who eventually has to write the apology email.

Every one of these incidents in the last six months has landed on my desk with the same opening line in the post-mortem: "the agent acted weirdly."

The agent did not act weirdly. The agent did exactly what the framework told it to do — retry on timeout, retry on 5xx, retry on ambiguous tool response — against a tool call that was never designed to be retried. That is not an AI failure. That is a 25-year-old distributed-systems failure wearing a new costume.

The principle the agent ecosystem is currently rediscovering is idempotency: an operation is idempotent if applying it once and applying it more than once produce the same result. Roy Fielding formalized it for HTTP methods in chapter 5 of his 2000 REST dissertation, made normative in RFC 2616 §9.1.2 and restated in RFC 7231 §4.2.2. The folklore is older — RPC implementers were debating it in the 1980s.

By 2010, idempotency was a non-negotiable in any serious payments, messaging, or inventory system. The agent frameworks of 2024–2026 ship with retry semantics at the tool-call layer. The tools they call were written by humans, for humans, on the assumption that a human would not press the button fourteen times in nine minutes. The collision between those two assumptions is where the production damage lives.

Nothing really new

Tool calls now appear in 21.9% of agent traces, up from 0.5% in 2023 — a 44× expansion of the retry surface in a single year (LangChain State of AI 2024).
Gartner forecasts 40% of enterprise apps will ship task-specific agents by end of 2026, and 40%+ of agentic AI projects will be cancelled by end of 2027 — driven by reliability and governance gaps (Gartner, Gartner).
Every major delivery substrate the agent stack inherits is at-least-once: Stripe retries webhooks for 3 days, AWS SQS standard queues document duplicate delivery as the contract, HTTP retries are normative.
The fix is unchanged from 2017: every state-mutating tool requires a deterministic idempotency key + a deduplication store at the boundary. Frameworks do not enforce this by default.

Why this is happening now: the retry surface just got 44× bigger

LangChain's 2024 telemetry shows tool calls jumping from 0.5% of agent traces in 2023 to 21.9% in 2024, with average steps per trace growing from 2.8 to 7.7. Each step is a potential non-idempotent side effect.

Year	Tool calls (% of traces)	Avg steps per trace
2023	0.5%	2.8
2024	21.9%	7.7

Source: LangChain State of AI 2024.

What is new is not retry behaviour at the network layer. What is new is the volume of state-mutating calls being generated by a non-deterministic upstream component. An LLM that produces "approximately the right tool call" 95% of the time also produces "almost-but-not-quite the same tool call" the other 5% — and 5% of millions of calls a day is enough to expose every non-idempotent operation in the entire downstream stack.

51% of survey respondents in the LangChain State of AI Agents Report run agents in production. 89% of orgs in the State of Agent Engineering 2025 report have observability in place. Instrumentation is catching up. The contracts at the tool boundary are not.

Five production failures, all the same shape

Real incidents from the last six months.

1. The fourteen-email onboarding

A B2C signup agent calls a send_welcome_email tool wrapping an internal API. The internal API is eventually consistent — it returns 202 Accepted before enqueue, and under load occasionally returns a socket timeout after the message was enqueued. Framework default: retry on timeout up to 3× with backoff. The tool: no idempotency key, no de-duplication.

Three retries × four sequential retriggers from a downstream "incomplete onboarding" agent = fourteen emails to one mailbox. One enterprise customer publicly tweeted about it. Two hours of incident response. A week of churn-control outreach.

2. The double subscription charge

A self-serve renewal agent handled decline-and-retry on subscription billing. The Stripe call was idempotent — Stripe has supported Idempotency-Key headers for years, with a 24-hour deduplication window. The internal entitlement-grant call after the charge was not idempotent.

When Stripe returned a network-layer error after the card was already charged, the agent retried the whole sequence — including a second successful Stripe charge (because the framework's retry was at the agent step, not the tool step) and a second entitlement grant.

Lesson: Stripe's idempotency layer was correct, and the system still produced a duplicate charge, because the retry was orchestrated one level above where the idempotency key lived. Idempotency is not a property of one call. It is a property of every layer in the call chain.

3. The ghost order

An order-capture agent calls an OMS create_order tool. The OMS expects a client-supplied order ID and is in fact idempotent on it — but the agent, on retry, generated a new UUID for each attempt because the prompt said "generate an order ID" rather than "reuse the order ID across retries."

Every individual layer was idempotent-aware. The integration was not. The non-determinism of the LLM produced new IDs on retry, defeating the very property the OMS was designed to provide.

4. The webhook fan-out

A vendor's webhook delivery is at-least-once — they retry on any non-2xx response. Stripe's published retry schedule extends across immediate, 5-min, 30-min, 2-hr, 5-hr, 10-hr, then every-12-hour windows for up to 3 days. Duplicate delivery is the documented expectation, not the edge case.

The receiving agent's adjust_inventory tool decremented stock. A debug field in the response triggered a Pydantic error in the framework's parser, returning a 500 to the source. The vendor retried. The framework parsed correctly the second time. Inventory decremented twice. Three SKUs oversold. Wrong stock counts pushed to the e-commerce frontend before the on-call SRE caught it.

The fix was not in the agent. The fix was in the inventory tool, which should have accepted an idempotency key from the webhook source and rejected duplicates with 200 OK rather than re-executing.

5. The duplicate Jira

An incident-triage agent ingests a support email and creates a Jira ticket. Framework response timeout: 8 seconds. Jira instance under load: regularly 12 seconds. Agent retried. Jira created a second ticket. The triage agent's own dedup pass merged them — but the merge call timed out, retried, and produced a third ticket. By end of morning: six Jira tickets, two Slack threads, one customer email.

The pattern, stated clearly

In every case, the surface narrative was the agent's behaviour. The actual cause was an operation that was non-idempotent in the path of an at-least-once delivery semantic.

Non-idempotent operation. At-least-once delivery semantic. If those two facts are true at the same boundary, you do not have an AI failure. You have a distributed-systems failure that AI made cheaper to trigger.

The agent did not invent the retry. The agent did not invent the network timeout. The agent inherited an at-least-once world from every layer beneath it — the LLM provider's retry on rate-limit, the framework's retry on tool error, the SDK's retry on socket close, the webhook source's retry policy, the queue's redelivery contract — and pointed it at tools designed for a single human caller pressing a single button once.

The reason this pattern is hard to see in post-mortem is that no single component is "wrong." The framework's retry policy is correct. The webhook source's retry policy is correct. The downstream tool's response-on-error is technically correct. The failure is emergent — it lives at the seams between layers, where each layer assumes the layer beneath it is idempotent and does not check.

At-least-once is inescapable

Every major delivery substrate the agent ecosystem inherits is at-least-once. This is not a pessimistic framing. It is the documented behaviour:

AWS SQS standard queues document at-least-once delivery as a guarantee.
Apache Kafka defaults to at-least-once; exactly-once is opt-in via transactional config.
HTTP retries are normative — RFC 7231 specifies which methods are safe to retry.
Stripe's webhook docs explicitly warn: "your endpoint should be idempotent" — duplicates across a 3-day window are expected on the happy path.

Exactly-once delivery in asynchronous distributed systems with failures is impossible by formal proof — established in the 1980s, rediscovered every time a new generation tries to design around it. What you can do is build idempotent receivers and let the substrate retry as much as it wants without producing duplicate side effects.

The architectural fix

Treat every state-mutating tool call as a network call to an at-least-once delivery channel. That is the only assumption that is safe.

Three layers, in order of importance.

Layer 1 — every state-mutating tool requires an idempotency key

Not optional. Not "if the upstream service supports it." The tool's own contract enforces it.

from typing import Annotated
from pydantic import BaseModel, Field

class CreateOrderInput(BaseModel):
    idempotency_key: Annotated[str, Field(min_length=16, max_length=128)]
    customer_id: str
    line_items: list[LineItem]

@tool(state_mutating=True)
def create_order(inp: CreateOrderInput) -> Order:
    # framework rejects the call before reaching the OMS
    # if idempotency_key is missing or malformed
    return oms_client.create_order(
        client_order_id=inp.idempotency_key,
        customer_id=inp.customer_id,
        line_items=inp.line_items,
    )

If the agent calls create_order(...) without a key, the call fails fast at the tool boundary with a 400 — before reaching the OMS. The framework's tool-call validator catches this in development and prevents the integration from shipping in the first place.

Layer 2 — the idempotency key has a defined synthesis rule

The agent does not "generate" the key on retry. The key is derived from the inputs of the original call — a hash of the caller, the operation, and the semantically-meaningful inputs.

import hashlib, json

def synthesize_key(tool_name: str, caller_id: str, inputs: dict) -> str:
    canonical = json.dumps(inputs, sort_keys=True, separators=(",", ":"))
    payload = f"{tool_name}|{caller_id}|{canonical}".encode()
    return hashlib.sha256(payload).hexdigest()

On retry, the same inputs produce the same key. The key is stable across retries because it is derived, not invented. This rule directly addresses failure case 3 (the ghost order) — the LLM cannot accidentally regenerate a UUID if the UUID is a deterministic hash of the input.

Layer 3 — deduplication store at the tool boundary

A cheap key-value store keyed by (tool, idempotency_key) returns the cached response on duplicate calls.

def execute_with_dedup(tool_name: str, key: str, fn, ttl_seconds=86_400):
    cached = dedup_store.get(f"{tool_name}:{key}")
    if cached is not None:
        return cached  # replay original response, no side effect
    result = fn()
    dedup_store.set(f"{tool_name}:{key}", result, ex=ttl_seconds)
    return result

TTL is generous — Stripe's 24-hour window is the canonical reference; 7 days is fine for high-cost operations like billing or order creation. Storage is cheap. A second customer charge is not.

This is not novel architecture. Stripe published the canonical pattern for it in 2017. The reason it does not exist by default in agent frameworks is that the frameworks were optimized for prototyping, not production — and the production cost of the missing layer only becomes visible after the first incident.

The deeper reason it does not exist is that the frameworks are converging on the wrong default. They optimize for "make tool calls easy" — correct for prototyping — but the production-correct default is "make tool calls safe". Easy and safe are not the same. The frameworks that ship safe-by-default tool wrapping in the next 18 months will eat the lunch of the ones that ship easy-by-default. This pattern repeats every time a substrate matures. It happened to RPC. It happened to REST. It will happen to agents.

Three engineering rules for 2026

Three rules I am asking every team I work with to adopt. They are not new — they are what a Stripe engineer would have given you in 2018, restated for an agent context.

Rule 1 — Tools, not agents, own idempotency. The agent is non-deterministic by design. The tool is the deterministic boundary. The contract belongs there. Every state-mutating tool exposes an idempotency_key parameter; the framework synthesizes it from inputs if the agent does not supply one.

Rule 2 — Test retries explicitly. Every state-mutating tool ships with a regression test that calls it twice with the same inputs and asserts identical end state. CI catches the violation before the framework's retry policy does. The single most cost-effective test you can add to an agent codebase, and almost no team I have worked with is doing it consistently.

def test_create_order_is_idempotent():
    inputs = sample_order_input()
    first = create_order(inputs)
    second = create_order(inputs)  # same idempotency_key derived
    assert first.order_id == second.order_id
    assert oms_client.order_count(inputs.customer_id) == 1

Rule 3 — Treat idempotency as a versioned contract. When the tool's input shape changes, the key derivation changes, and old in-flight retries should fail closed, not silently re-execute against the new shape. Most teams miss this on the first refactor and discover it on the second incident.

These three rules together cost a small engineering tax — perhaps 5% on tool development time — and prevent every one of the five failure modes above. The math is not subtle.

What this costs when you skip it

Direct revenue impact when duplicate billing requires refund + concession.
Trust erosion when fourteen-email incidents hit social media.
Engineering time when reconciliation between a ledger and an entitlement system takes a week.
Audit surface when finance discovers the system of record for charges and the system of record for grants disagree.
Project survival when leadership concludes the agent platform is "not production-ready" and pulls the funding. This is the failure mode behind Gartner's 40% project-cancellation forecast — not the AI being insufficiently capable, but the integration around it being insufficiently durable.

In every post-mortem I have run on these incidents, the cost-to-fix-after is at least 10× the cost-to-design-correctly-before.

Closing

The agent ecosystem is going through the same maturation curve every distributed-systems substrate has gone through. The 1990s had it for RPC. The 2000s had it for SOAP. The 2010s had it for REST and webhooks. Each generation rediscovered idempotency the hard way, usually after a billing incident hit the press.

The 2020s have it for agents. The good news is that we know the answer. The bad news is that the framework defaults are not yet aligned to it, and the production incidents are paying for the misalignment.

If you are building anything where an agent calls a tool that mutates state, the most useful question you can ask this quarter is: what happens if this exact call is made twice? If the answer is anything other than "the same thing happens once," you have an incident in your future. The only variable is the timing.

Idempotency is not a clever pattern. It is a 25-year-old constraint that distributed-systems people stopped negotiating about a long time ago. The agent ecosystem is currently rediscovering why.

The fix is older than most of the engineers shipping the bug.

This post is part of a four-week series connecting old software-engineering principles to new AI failure modes. Originally published on biztechbridge.com.

The Factory Floor is Talking. Are You Listening?

Omkar Gaikwad — Mon, 11 May 2026 07:04:12 +0000

There’s a specific kind of hum in a manufacturing plant. It’s a rhythmic, mechanical pulse that tells you everything is moving as it should. But for anyone who has spent time in production, you know that the hum can change in an instant. A bearing starts to whine, a belt slips, or a pneumatic line hiss—and suddenly, you’re not looking at a "productive shift," you’re looking at a mountain of downtime and a massive headache for the maintenance crew.

For years, we’ve treated automation as a way to replace that "hum" with something sterile and robotic. We thought of it as a way to cut costs by cutting people. But as we move deeper into 2026, the narrative has shifted.

Automation isn't about replacing the person on the floor; it’s about giving them superpowers. It’s about moving away from "fixing what’s broken" and moving toward a world where the machines tell us what they need before they ever stop working.

Moving Beyond the "Robot in a Cage"
When most people hear "manufacturing automation," they picture a massive yellow robotic arm behind a safety fence, welding the same spot on a car frame every six seconds. That’s Automation 1.0. It’s efficient, but it’s rigid.

Today, we are looking at something much more fluid: Hyper-automation.

This isn't just about hardware; it’s about the software and the data that connect the entire building. It’s the bridge between the grease-stained reality of the factory floor (OT) and the clean, data-driven world of the front office (IT). When you look at the latest trends in manufacturing automation, you see a shift from "dumb" repetition to "intelligent" adaptation.

Why This Matters Now (More Than Ever)
If you’re a developer or an engineer, you might wonder why the urgency feels so high lately. It’s because the safety net of the "old way" has disappeared.

The Human Element & The Labor Gap
Let’s be honest: it is getting harder to find people who want to do back-breaking, repetitive, or dangerous manual labor for eight hours a day. We have a massive skills gap in the industry. Automation allows us to take the people we do have—the ones with the deep institutional knowledge—and move them into roles where they are managing systems rather than acting like parts of the machine themselves. It’s about dignity and safety as much as it is about efficiency.
The End of "Finger-Crossing" Maintenance
We’ve all been there. You have a critical order due Friday, and you’re just hoping the old lathe holds together until the weekend. Predictive maintenance—driven by AI and IIoT sensors—takes the guesswork out of the equation. It feels like magic the first time a system alerts you that a motor is vibrating 2% off-pattern, allowing you to swap a $50 part on a Tuesday instead of replacing a $50,000 engine on a frantic Thursday night.
Agility is the New Efficiency
The last few years taught us that global supply chains are fragile. A port strike or a canal blockage can wreck your production schedule. An automated system doesn’t just report the delay; it adapts to it. It can reshuffle your inventory, prioritize high-margin orders, and update your customers' expectations in real-time. That kind of agility is the difference between a business that survives a crisis and one that thrives during it.

The Developer’s Dilemma: It’s Not Just About Code
If you’re tasked with building these systems, you know the "cool stuff" (the AI, the vision systems, the sleek dashboards) is only 20% of the battle. The real work is in the plumbing.

Respecting the Legacy: You can’t just walk into a plant and tell them to throw away their 20-year-old equipment. Our job is to build the "Edge" layers—the translators that allow a legacy PLC to talk to a modern cloud API.
Breaking Down the Silos: In many companies, the people who manage the inventory don't talk to the people who manage the machines. As developers, we are the ones who create the "single source of truth." We are the ones ensuring that when a machine detects a defect, the inventory system knows immediately to order a replacement part.
Security in the Physical World: In software, a breach might mean lost data. In manufacturing, a breach could mean a machine behaving dangerously. The stakes are physical, and our security protocols have to reflect that.

How to Start Without Breaking Everything
Digital transformation is intimidating. You don't have to automate the entire plant on day one. In fact, you shouldn't.

Find the "Pain Points": Talk to the operators. Ask them what task they hate the most. Ask them which machine they trust the least. That’s where your automation journey should begin.
Focus on the "Low-Hanging Fruit": Quality control is usually a winner. An AI-powered camera that catches a scratch on a product is easier to implement than a fully autonomous warehouse, and it shows immediate value to the stakeholders.
Keep the User in Mind: If the dashboard you build is too complicated for a floor manager to use during a busy shift, it’s a failure—no matter how clean the code is.

The Rise of the "Cobot"
The future isn't a "lights out" factory where no humans are allowed. The future is collaboration. We’re seeing the rise of "Cobots"—robots designed to work right next to people. They handle the heavy lifting or the precision soldering, while the human handles the nuance, the troubleshooting, and the creative problem-solving.

When we integrate automation in manufacturing, we aren't just building a faster assembly line. We’re building a more resilient, more humane, and more intelligent way of making things.

Final Thoughts
At the end of the day, technology is just a tool. But in the hands of a forward-thinking manufacturing team, it’s the tool that turns a struggling shop into a world-class leader. We’re moving from a world where we "work for the machines" to a world where the machines finally work for us.

The "hum" of the factory isn't going away—it’s just getting a lot smarter.

Want to get into the nitty-gritty of how this actually looks in practice? Check out the full guide on Automation in Manufacturing to see how you can start your own transformation.

Doubts about what I’ve done

Orchid Files — Mon, 11 May 2026 07:04:00 +0000

I have doubts not only while making a decision, but also after I’ve made it. I publish a post, and the next day I already want to change the wording. I put an unpromising project on hold, and a month later I want to continue working on it. I come up with a cool name for a product, register the domain, and claim the social media handles, but a week later I no longer like the name. I publish an essay, and a year later I want to delete it so no one can see it anymore.

No matter how many hours I spend thinking things through and making a decision, the doubts won’t go away. I just make decisions knowing that I may no longer agree with them in the future.

Great Little Software: Papra

Valeria — Mon, 11 May 2026 07:00:00 +0000

To me, the main non-negotiable point is the ethical aspect of the project. From having everything opensource, to being selfhosting friendly and privacy-focused, no dark patterns, no shady stuff, no monetization of user data, no bullshit. It's really important for me to build a product that I can be proud of, that aligns with my values, and that make a positive impact, even if it means slower growth or less profit. I'd rather build a smaller sustainable product that treats people well than a bigger one that doesn't.
-- Corentin Thomasset

Papra came up in a research that AI agent did for me. It was a very disappointing research, small indie apps built on strong ethical foundation are very hard to find. I think partly because those who make them care more about the apps than the marketing, but mostly because of the sheer volume of yet-another-too-good-to-be-true AI SaaS platform. So when I stumbled upon Papra I got very excited to see the one that made it through the noise!

I was a bit nervous reaching out to Corentin Thomasset, but he turned out a wholesome human being and generously shared his and Papra's story, that I am so very eager to retell you.

"I've started Papra on January 2025 as a side project while still being employed full time" - he shared in his email, "I needed an archiving platform for myself, and I found existing solutions to be either too complex, or not user-friendly enough to be usable by non-technical users (family). So I decided to build something that fits my needs, and hopefully fits others' too."

I have a theory why many software projects start this way: I think there's a lot of correlation between an artist and a software developer and if you think about it this way, you wouldn't be suprised that a painter painted a sunset view from their backyard - that's what was available at the time - anything goes, because we can't resist the call of "what if it could be done better?" even if that would cost years of working after hours with no return, except for the sense of accomplishment.

Luckily, Papra gained traction and within 9 months Corentin was able to fully focus on the project.
Let me say it again, he was able to make revenue from an open-source, self-hostable, affordable project!

The Right, The Hard Way

There is a reason why the most common business advice is to solve problems for big companies and charge them exorbitant amount of money: it's easier and you only have to get a few customers to be able to cover your own salary. An even easier way is to raise money for your idea - you don't even need to build anything, "just" convince investors that your promises are worth the risk.

It's an art too, just not the style I personally aspire to. I think that business, just like any form of leadership, is about caring about the people you serve and placing their interests above the sheer profit.

And it was very obvious to me that Corentin shares the same values:
"As an open-source and self-hosting advocate, Papra is for me a way to empower people to take control of their own data instead of handing it over to corporations that monetize it. Document archives are deeply personal (tax returns, contracts, medical records, payslips, ...) and I think people deserve tools that treat that seriously.", as he put it - "And, to be honest, I also just love building software. Crafting a product from scratch, solving problems, and learning new things along the way. It's a very rewarding experience for me, and I enjoy the process as much as the result."

Guilty, I do too.

One-man-band

Building stuff is fun indeed. Corentin worked with a tech stack he liked and is deeply familiar and enjoys working with. This freedom to choose how, when and what to work on is the greatest benefit of solo development, but there's the other side of the coin too.

As Corentin put it: "...being a solo founder, you have to wear many hats (every hats to be honest), from development, to design, to marketing, to support, to infrastructure, and more. Every discord ping, every issue, every "it doesn't work" message, every PR, it's all on you to handle, and it can be overwhelming at times. But the community around the project has been amazing and supportive, it's motivating and makes it all worth it."

Naturally, one would suggest to turn to the all-powerful-LLMs to balance the load out, but I think Corentin has a good point about it:
"As a said above, I really enjoy building software, writing code, finding solutions to problems, and crafting stuff with my bare hands, so AI has never had a significant role in Papra's development. I don't want the robots doing the fun part for me, or to lose my connection with the codebase."

He mentioned the famous line by Joanna Maciejewska: "I want AI to do my laundry and dishes so that I can do art and writing, not for AI to do my art and writing so that I can do laundry and dishes.". Given that I've spent the last year trying to tackle this exact problem (never-ending laundry and dishes), I couldn't agree more.

I'm not anti-AI and my impression is that neither is Corentin. He said that he genuinely tried to make it work, but got frustrated because correcting and re-prompting LLM often takes longer and yields worse results than doing it manually. He uses it for reviews and feedback - as a second pair of eyes and a "safety net, not as a builder".

Unfortunately, not everyone shares this perspective and like many of open-source maintainers Papra and Corentin are plagued with vibe-coded low-quality contributions, from people, which took them few seconds to prompt and submit. "But on the other side, it takes a lot of time to review, correct, and give feedback on those PRs (feedback which often just gets forwarded back to their agent). It makes it hard not to get a bit sick of AI-generated code." - he shared.

With great power, comes great responsibility, as Uncle Ben taught us.
We just have to hope the latter comes sooner rather than later.

The recipe for success

As of right now, Papra has 4.4K stars on GitHub, which I find very inspiring and see it as a testament to its maker's abilities and expertise. I asked Corentin if he'd be willing to share his knowledge with us, other solo builders and solo founders, which he did and I believe it's best that I share his answers verbatim:

"The reality is that my projects are not yet profitable enough for me to fully live off them. I have the chance to have some savings, and can collect some French unemployment benefits for a while. Plus my partner is working full time which is a huge safety net. So I have the huge privilege of being in a comfortable enough position to focus on Papra without the pressure of needing it to pay the mortgage next month, but I'm clear-eyed that this window won't last forever. At some point, Papra needs to become profitable enough to sustain me, or I'll go back to a more traditional job and keep building it on the side. That's just the math.

As for tips and advice, I think the main one is to do this for the right reasons. Trying to build stuff just for the money is a recipe for burnout and disappointment, especially in the early stages when the project is not yet profitable. Building something you care about, that solves a problem you have, that aligns with your values, is what will keep you going through, and make the journey enjoyable regardless of the outcome.

As for marketing it's indeed a challenge, especially for a solo builder with limited time and resources. It's clearly not my strong suit, and I don't have a magic formula for it. But I think being authentic, and engaging with the community in a genuine way is important. It goes with the "do stuff for the right reasons" advice, people can sense when a project is built with passion and care, and that can be a powerful marketing tool in itself. I'd love to grow the team eventually and bring in people with marketing or community-building skills, but for now it's just me wearing all the hats and doing my best to get the word out while building the product.

In the end, I'd rather build something small that I'm proud of and that genuinely helps people than chase numbers I don't care about. If Papra ends up being a sustainable one-person product that pays my bills and serves a community of users who care about their data, that's a huge win. Anything beyond that is a bonus.

So if there's one thing I'd say to other solo builders: don't measure yourself against other products outcomes. A profitable, sustainable, one-person product that lets you keep doing work you care about is already a rare and valuable thing. That's the bar I'm aiming for, and I think more builders should give themselves permission to aim there too."

What do you wish you'd done differently with the knowledge you have now?

"I'd tell my past self to focus less on making things perfectly perfect from the start. I easily get caught up in the details and try to build the ideal solution, sometimes getting stuck on a problem for too long, or over-engineering things at the cost of shipping and getting feedback. There's a balance between building something good enough to be useful and obsessing over making it perfect, and I'm still learning to find it. Hard habit to break, but I'm getting better at it."

What's your wildest dream for the app?

"I'd love to see Papra become the go-to reference for document archiving, empowering millions of people to take control of their own data, and maybe even inspiring companies to go full open-source and self-hosting along the way.
And beyond that: a thriving community of contributors and self-hosters around Papra, where the project belongs to more than just me, with an open governance model. The kind of open-source project that lives beyond its creator, one that will adapt and evolve with the needs of its users. That would be the long-term win."

I encourage you to try Papra out at papra.app.
It is a great little software.

Stablecoin Payments for Marketplaces: How Platforms Can Accept Crypto in 2026.

QBitFlow — Mon, 11 May 2026 07:00:00 +0000

How platforms can accept crypto in 2026

Marketplaces have always borrowed someone else's payment rails.

Stripe Connect, PayPal for Marketplaces, Adyen for Platforms — every multi-vendor platform you have ever used is, underneath, paying another company to hold its sellers' money for a few days and then forward it on. The model works. It also costs a 0.5% markup on top of card fees, introduces multi-day payout delays, and leaves every platform exposed to the standing risk that the processor decides one category of seller is too risky to serve.

In 2026, that math finally started shifting. Meta began paying creators directly in USDC. Western Union launched USDPT on Solana for cross-border remittances. The EU's MiCA framework opened the door for euro-denominated stablecoin payments at scale. And a generation of marketplace operators started asking the obvious question: if stablecoins move dollars on rails that settle in seconds and cost cents, what are we still paying card processors 3% for?

This post is for the operators asking that question. It covers what changed, where traditional rails break for marketplaces specifically, the three architectures available today, and how on-chain fee splitting closes the gap that custodial gateways have left open.

Why marketplaces are looking at stablecoins in 2026

A few things stacked up in the last twelve months.

Meta's USDC creator payouts (April 2026). Meta started paying Instagram and Threads creators in USDC for select monetization programs, citing faster international payouts and lower friction than the bank-rails system. Whatever you think of Meta, the signal matters: the largest creator platform on Earth concluded that for a meaningful chunk of payouts, stablecoins beat correspondent banking. That moves "creator paid in crypto" from edge case to category.

Western Union's USDPT on Solana. Western Union, the most legacy player in cross-border money movement, launched USDPT (a USD-pegged stablecoin) on Solana. The pitch was the same one crypto people have been making for a decade — faster, cheaper, programmable settlement — except this time it was coming from inside the building.

MiCA in effect. The EU's Markets in Crypto-Assets regulation is fully live, with stablecoin issuers like Circle holding e-money licenses. That gives EU marketplaces a regulated path to accept and pay out in EURC without the regulatory ambiguity that used to kill these projects in compliance review.

Chargeback math for digital goods. Card chargebacks cost online marketplaces an estimated 1-3% of revenue in disputes, fraud, and operational overhead. Stablecoin transactions are final. For digital goods, services, and downloadable content, that eliminates an entire cost center.

Cross-border without correspondent banking. A platform with sellers in 40 countries pays SWIFT fees, FX spreads, and minimum-balance requirements for every corridor. Stablecoins collapse that into one settlement currency and one rail.

The result is that "should we accept crypto" stopped being a 2024-era conversation and became a 2026 product decision.

How traditional marketplace payments work — and where they break

Most marketplaces run on one of two models: Stripe Connect or PayPal for Marketplaces (Adyen for Platforms is similar). Both are custodial. The platform — Stripe, PayPal — holds the seller's funds, takes the card-network fee, takes a platform fee, and pays the seller on a delay.

For a digital marketplace with a 10% platform cut, the typical fee stack looks like this:

Stripe card processing: ~2.9% + $0.30
Stripe Connect markup: 0.5% on top
Platform's own cut: 10%
Seller take-home: ~86.6%

Then come the operational realities:

Payout delays. Standard Stripe Connect payouts arrive on T+2 to T+7. Instant payouts cost an extra 1.5%. PayPal holds new sellers' funds for up to 21 days. For sellers operating on thin margins, those delays are working-capital expensive.

Account holds and deplatforming. This is the one nobody on the platform side likes to talk about, because the platform is usually the one doing it. When the processor underneath you decides an entire category of seller is too risky, the marketplace inherits that decision. The sellers do not get a vote. Funds in flight can be held; future processing can be cut off entirely. Every marketplace operator I've talked to in the last year has at least one war story.

KYC and dispute overhead. Every seller goes through a custodial onboarding flow that the platform does not control. Disputes get arbitrated by a card network whose incentives do not match the marketplace's.

The custody itself is the root issue. The moment a third party holds the funds between buyer and seller, the marketplace is renting access to its own revenue. Most of the time that rental is fine. The risk shows up at the tail.

The smart-contract alternative

A non-custodial marketplace payment looks structurally different.

When a buyer pays a seller through a non-custodial gateway, the funds move directly from the buyer's wallet to the seller's wallet via a smart contract. There is no intermediate account. The marketplace's cut — say 10% — is split off on-chain, at the same transaction, into the platform's own wallet. The remaining 90% lands in the seller's wallet immediately. Settlement is one transaction, one block, both parties paid.

A few properties fall out of this:

No payout delay. The seller has the funds the moment the buyer signs. No T+2, no instant-payout surcharge, no rolling reserve.
No omnibus account. No third party holds the funds at any point. The platform cannot freeze a seller's revenue, because the platform never holds it. Neither does the gateway.
Automatic fee enforcement. The platform's cut is encoded in the smart contract. There is no monthly reconciliation, no manual invoicing, no risk that a seller forgets to remit.
Auditable rules. Open-source contracts mean both the platform and the seller can read the exact logic that governs every payment. The contract is the agreement.

This is what QBitFlow ships today. The marketplace creates an organization account, adds user-level accounts for its sellers, sets a fee percentage per user, and the smart contracts handle the rest. Every payment that flows through a seller's hosted checkout splits at settlement: platform takes its cut on-chain, seller receives the remainder in the exact token the customer paid with. No auto-swap, no slippage, no conversion fee.

Supported chains today are Ethereum, Solana, and Base, with full token coverage for the stablecoins marketplaces actually want — USDC, USDT, EURC, and DAI across all three. The contracts are on GitHub at github.com/QBitFlow.

Three models for marketplace stablecoin payments

If you are a marketplace operator looking at stablecoin payments seriously in 2026, you have three real options. Each has a place; the right one depends on what you optimize for.

Model 1: Custodial crypto gateways (BitPay, Coinbase Commerce, MoonPay for Business)

A custodial gateway is structurally Stripe-shaped. The gateway holds the funds, takes a fee, and pays out to the seller on a schedule. The customer pays in crypto; the merchant typically receives a payout in the chosen currency.

Pros: familiar operational model, integrations look like existing payment-processor integrations, the gateway absorbs some of the complexity.

Cons: every issue with the custodial model carries over — deplatforming risk, payout delays, account holds, opaque dispute handling. You have replaced the card network with a crypto company that can still freeze your sellers' funds. The architecture has not actually changed.

Best for: marketplaces that want a crypto on-ramp but are not ready to rethink the custody model.

Model 2: Self-hosted, self-custody (BTCPay Server)

Open-source, self-hosted, fully non-custodial. The marketplace runs its own infrastructure, accepts crypto directly, and handles fee splitting in application code.

Pros: maximum control, zero fees to a third-party gateway, no platform risk.

Cons: you are now running payment infrastructure as a side product. Hosting, uptime, key management, smart-contract development (if you want on-chain fee splits), chain support, wallet compatibility — all on you. For a marketplace whose core product is not payments, this is a lot of surface area to own.

Best for: technically deep teams who want to own every piece of the stack and have the engineering bandwidth to maintain it.

Model 3: Non-custodial gateway with smart-contract fee splits (QBitFlow)

This is the model the rest of this post has been describing. A managed service that ships the integration layer — hosted checkout, SDKs, dashboard, webhooks — but settles non-custodially via open-source smart contracts. Fees split on-chain at the transaction. The gateway never holds funds.

Pros: non-custodial settlement (no deplatforming risk, no payout delays, no held funds), but you do not run the infrastructure. Smart-contract fee splits work out of the box — no application-layer reconciliation. The platform gets ten-minute setup time, the seller gets immediate settlement.

Cons: still a managed dependency. If the gateway disappears tomorrow, the smart contracts keep running (they're open-source and on-chain), but the dashboard, hosted checkout, and SDK maintenance go with it. This is a real consideration; it is also why the contracts being open-source matters.

Best for: marketplaces that want non-custodial settlement without becoming a payments company.

The honest version: model 1 is fine if you just want a crypto button. Model 2 is right if payments are core to your product. Model 3 is the middle path — and it is the one most marketplace operators end up at once they have run the numbers.

Setting up marketplace payments with QBitFlow

The integration path for a marketplace looks roughly like this. Numbers below are accurate as of May 2026; check qbitflow.app/docs for the current state.

Create an organization account. Sign up at qbitflow.app/get-started with email and password. Connect a public wallet address — Ethereum, Solana, or Base. The wallet receives the platform's fee splits; QBitFlow never sees a private key.
Add user-level accounts for sellers. Each seller on your marketplace gets a user account inside your org. Two options here:
- Already-onboarded sellers connect their own wallet at signup. Their share of every payment routes directly to that wallet.
- New sellers without a wallet start as unclaimed accounts. Payments to them route to your org wallet, with an off-chain ledger tracking what's owed to whom and an on-chain transaction hash captured for every payment. When the seller is ready, they go through a claim flow (set password, connect wallet, you sign one transaction to release everything they have earned). After that, it's standard non-custodial settlement.

One caveat worth flagging upfront: subscriptions don't work on unclaimed accounts (subscriptions hash the recipient wallet at creation, so the wallet has to exist first). One-time payments work fine for unclaimed users.

Configure your fee percentage per user. Smart contracts enforce it. There is no manual reconciliation, no monthly remittance — your cut lands in your wallet at the same block as the seller's cut.
Integrate via SDK or REST API. Customers always pay through QBitFlow's hosted checkout — the SDK and the API are just the tools your backend uses to manage customers, products, and create checkout sessions. Each session returns a checkout URL you redirect the customer to. The hosted page handles wallet connection, chain selection, and payment confirmation, and ships with theme + logo customization plus custom success/cancel redirect URLs. QBitFlow ships SDKs for JavaScript/TypeScript, Python, and Go at feature parity if you want a typed client; if your stack isn't covered, hit the REST API directly.
Wire up webhooks for your backend. Per-payment webhooks fire on terminal status only — completed, failed, cancelled, expired. Signature verification uses HMAC headers (X-Webhook-Signature-256 + X-Webhook-Timestamp), and the SDKs expose client.webhooks.verify() to handle the check.

Typical time from signup to first live payment is around ten minutes. New merchants get automatic testnet faucet funds at account creation, so the full sandbox flow runs before you touch real money.

For platforms running WordPress, the WooCommerce plugin is available on GitHub today at WooCommerce Plugin — install it directly from there and it works end-to-end. The plugin has also been submitted to the official WordPress plugin directory and is currently under review, so one-click install from the WordPress store is coming soon. A standalone WordPress plugin (for sites not running WooCommerce) is in active development.

Who should consider this

Not every marketplace needs to accept crypto. The model fits some categories better than others.

Creator platforms — content subscriptions, digital goods, paid newsletters, fan platforms. Digital goods are the cleanest fit: no chargebacks matter most where physical fulfillment is not in the dispute path, and creators have been the most vocal about wanting cross-border payouts.

Freelancer marketplaces — design, dev, writing, consulting. International freelancers have been routing around correspondent banking with crypto for years; formalizing that flow with smart-contract escrow and instant settlement is the obvious upgrade.

Multi-vendor e-commerce — especially platforms with international sellers or sellers in categories where card processors are inconsistent.

Gaming asset marketplaces — in-game items, digital collectibles, NFT secondary markets. Stablecoin settlement with on-chain fee splits is already the dominant model here; the question is which gateway, not whether.

SaaS platforms with revenue sharing — anyone embedding payments in a product where part of the revenue routes to a third party (template marketplaces, plugin stores, API resellers).

If you are running one of these and your current payment stack costs you more than 1.5% in gateway fees, has ever held a seller's funds longer than you wanted, or has a category-risk story you would rather not repeat — the math is worth running.

FAQ

What currencies and tokens are supported?
Ethereum mainnet (ETH, WETH, USDC, EURC, USDT, LINK, WBTC, DAI), Solana (SOL, WSOL, USDC, USDT, EURC, LINK, DAI), and Base (ETH, WETH, USDC, USDT, EURC, DAI, cbBTC, AERO). For marketplaces, USDC and USDT cover the vast majority of real volume.

How do sellers receive funds?
Directly to their wallet, in the same token the buyer paid with. No auto-swap, no conversion. If a buyer pays in USDC on Base, the seller receives USDC on Base. The marketplace's fee split also lands in the same token, in the same transaction.

What are the fees?
1.5% flat, paid by the merchant out of the payment. No separate billing, no withdrawal fees, no chargeback fees. Customer pays gas. Volume discounts kick in at $50K+/month. The platform's own marketplace cut is on top of that 1.5%, and it lands in the platform's wallet on-chain.

Is this compliant with regulations?
Stablecoin payment infrastructure under MiCA, EMT/ART rules in the EU, and the relevant US frameworks is workable today — the issuers (Circle, Tether, etc.) hold the licenses; the gateway is settlement infrastructure. As always: talk to your own counsel about your specific jurisdiction and customer mix before going live.

What if QBitFlow disappears tomorrow?
The smart contracts are open-source and live on-chain. Settlement keeps working. You would lose the hosted dashboard, the SDKs, and the support, but the funds and the contract logic are not in QBitFlow's custody at any point — that's the point of non-custodial.

If you are running a marketplace and want to talk through how on-chain fee splitting would fit your stack, the QBitFlow checkout takes about ten minutes to set up and the docs at qbitflow.app/docs cover the full marketplace integration. We'd rather show you the contracts than the slide deck.