DEV Community: Mihir kanzariya

Five affiliate fraud patterns I caught on Stripe (and the queries that found them)

Mihir kanzariya — Fri, 19 Jun 2026 06:48:24 +0000

Your affiliate program will attract fraud before it attracts revenue. That sounds pessimistic, but the math checks out: a 30% recurring commission on a $49/mo plan pays $14.70/mo per referred customer. Fraudsters do the arithmetic faster than you do.

I build Referralful, affiliate software for SaaS on Stripe. These are five patterns I've seen in production, with the Stripe data points and queries that catch them.

1. Self-referrals

The simplest one. An affiliate signs up, generates their own referral link, opens an incognito window, and subscribes through it. They collect commission on their own purchase.

Detection signal: The affiliate's email domain, billing name, or Stripe customer metadata overlaps with the referred customer.

SELECT a.affiliate_email, c.customer_email, c.stripe_customer_id
FROM affiliates a
JOIN referrals r ON r.affiliate_id = a.id
JOIN customers c ON c.id = r.customer_id
WHERE LOWER(a.affiliate_email) = LOWER(c.customer_email)
   OR a.billing_name = c.billing_name;

Check the Stripe payment method fingerprint too. Stripe assigns a unique fingerprint to each card. Same card on the affiliate account and the referred account? Self-referral.

# Compare card fingerprints via Stripe API
affiliate_methods = stripe.PaymentMethod.list(customer=affiliate_stripe_id, type="card")
customer_methods = stripe.PaymentMethod.list(customer=referred_stripe_id, type="card")

affiliate_fps = {pm.card.fingerprint for pm in affiliate_methods}
customer_fps = {pm.card.fingerprint for pm in customer_methods}

overlap = affiliate_fps & customer_fps
if overlap:
    flag_referral(referral_id, reason="shared_card_fingerprint")

2. Churn-and-re-sign

An affiliate refers a real customer. The customer churns. The affiliate convinces them to cancel and re-subscribe through a fresh referral link, resetting the commission window.

Detection signal: The same Stripe card fingerprint or email appears in multiple referral records, attributed to the same affiliate, with short gaps between subscriptions.

SELECT r.affiliate_id,
       c.customer_email,
       COUNT(*) AS referral_count,
       MIN(r.created_at) AS first_referral,
       MAX(r.created_at) AS latest_referral
FROM referrals r
JOIN customers c ON c.id = r.customer_id
GROUP BY r.affiliate_id, c.customer_email
HAVING COUNT(*) > 1
   AND EXTRACT(DAY FROM MAX(r.created_at) - MIN(r.created_at)) < 90;

The fix is simple: deduplicate on the customer, not the referral event. First-touch attribution, permanent. If a customer was ever referred by affiliate A, every future subscription from that customer still belongs to affiliate A's original referral, and you only pay the commission window once.

3. Cookie stuffing via redirect chains

An affiliate embeds your referral link in an iframe, image pixel, or redirect chain on a high-traffic page. Visitors never see the link or click it intentionally. The affiliate's cookie lands in their browser, and if they happen to sign up later, the affiliate gets credit.

Detection signal: Referral click volume with abnormally low conversion rates, or referral cookies set without a matching Referer header from a legitimate page.

Track these columns on every referral click:

click_timestamp | affiliate_id | ip_address | user_agent | referer_header | converted

Then flag:

SELECT affiliate_id,
       COUNT(*) AS clicks,
       SUM(CASE WHEN converted THEN 1 ELSE 0 END) AS conversions,
       ROUND(100.0 * SUM(CASE WHEN converted THEN 1 ELSE 0 END) / COUNT(*), 2) AS conv_rate
FROM referral_clicks
WHERE click_timestamp > NOW() - INTERVAL '30 days'
GROUP BY affiliate_id
HAVING COUNT(*) > 500
   AND conv_rate < 0.1;

An affiliate with 5,000 clicks and 2 conversions isn't driving real traffic.

4. Coupon code leaking

You give an affiliate a discount coupon to share with their audience. They post it on coupon aggregator sites (RetailMeNot, Honey, browser extensions). Customers who would have paid full price find the coupon, use it, and the affiliate collects commission on a discounted sale they never influenced.

Detection signal: High coupon redemption volume with referral source = coupon site, not the affiliate's actual content.

On the Stripe side, listen to customer.subscription.created and check subscription.discount.coupon.id against your affiliate coupon map. Then compare the customer.created timestamp with the referral click timestamp:

# If the customer existed BEFORE clicking the affiliate link,
# they probably found the coupon independently
if customer.created < referral_click.timestamp:
    flag_referral(referral_id, reason="customer_predates_click")

The structural fix: stop tying coupons to affiliates. Use the referral link for attribution and a separate, non-affiliate discount for promotions. Or accept that coupon leaking is the cost of running discounts and price it into your commission structure.

5. Disposable card churn

Affiliates (or bots they run) create accounts using virtual/disposable cards, subscribe at the lowest tier, collect the first commission payout, then let the subscription lapse. Stripe processes the initial charge successfully, your system records a valid referral, and the commission enters your payout queue.

Detection signal: Multiple referred customers with the same IP, the same card BIN range, or subscriptions that cancel within the first billing cycle.

SELECT r.affiliate_id,
       COUNT(*) AS total_referrals,
       SUM(CASE WHEN s.canceled_at IS NOT NULL
                AND s.canceled_at < s.current_period_end THEN 1 ELSE 0 END) AS early_cancels,
       ROUND(100.0 * SUM(CASE WHEN s.canceled_at IS NOT NULL
                AND s.canceled_at < s.current_period_end THEN 1 ELSE 0 END) / COUNT(*), 2) AS cancel_rate
FROM referrals r
JOIN subscriptions s ON s.id = r.subscription_id
WHERE r.created_at > NOW() - INTERVAL '60 days'
GROUP BY r.affiliate_id
HAVING COUNT(*) > 5
   AND cancel_rate > 60;

An affiliate with a 70% first-cycle cancellation rate across 20 referrals isn't sending real customers.

The structural defense: hold commissions for a pending period (30, 60, or 90 days) before they become payable. If the referred customer cancels or the charge gets refunded during that window, the commission never pays out. I wrote about the ledger design for this in my previous article on clawbacks.

Run the checks before the first payout

The worst time to discover fraud is after you've paid the commission. Wire these queries into a pre-payout review step:

Before any payout batch, run the self-referral and shared-fingerprint checks.
Flag any affiliate whose referrals have a first-cycle cancel rate above 50%.
Flag conversion rates below 0.1% on high-click affiliates.
Deduplicate referrals by customer email + card fingerprint.

You don't need ML or a fraud vendor for this. A few SQL queries and a manual review queue handle it until you're processing hundreds of affiliates. Start there.

I'm building Referralful, affiliate software for SaaS startups on Stripe. Free until your first affiliate signs up.

Clawing back affiliate commissions when a customer refunds: design the ledger first

Mihir kanzariya — Thu, 18 Jun 2026 08:42:12 +0000

You pay an affiliate 30% for referring a customer. Three weeks later that customer refunds. Now the affiliate is holding a commission on a sale that no longer exists, and you have to decide what happens to that money. If you only thought about this after it happened, you have already lost the clean version of the fix.

I build affiliate software on Stripe, and the clawback case is the one teams skip until it bites. Here is how to design for it before it does.

Earned is not the same as payable

The first mistake is treating a commission as money the moment the sale clears. It isn't. A commission is a claim against a sale that might still reverse. Stripe makes that gap concrete: a customer can refund whenever they want, and a card dispute can land up to 120 days after the charge. Your payout schedule (say, monthly) runs on a completely different clock.

So you have two timelines that don't line up: how long a sale can still reverse, and how soon you pay out. Pay before the first window closes and you are paying real money on revenue you may have to give back.

Hold commissions pending before they become payable

The fix is a holdback period. A commission lands in a "pending" state when the sale clears, and it only becomes "available" for payout after N days with no refund or dispute. Set N from your own refund data, not a guess. If most refunds happen in the first 30 days, a 30 to 45 day hold covers the bulk of them without making affiliates wait forever.

This one decision removes most clawbacks entirely, because the commission never reaches an affiliate's wallet until the risky window has passed.

Store a ledger, not a balance

Here is the part that saves you later: never store an affiliate's earnings as a single number you edit. Store immutable ledger entries and compute the balance from them.

commission_entries
  id
  affiliate_id
  charge_id            -- the Stripe charge this relates to
  type                 -- earned | reversed | paid_out
  amount_cents         -- signed: + for earned, - for reversed/paid
  status               -- pending | available
  created_at

A refund does not edit the original row. It writes a new reversed entry that points at the same charge. The affiliate's balance is just SUM(amount_cents) over their entries. You get an audit trail for free, every reversal is explainable, and you never lose the history of why a number changed. When an affiliate emails asking why their balance dropped, you can show them the exact charge and the exact reversal.

When the refund lands after you already paid

Sometimes a refund or a dispute arrives after the commission went out the door, usually because a chargeback showed up 60 days later. Now the affiliate's balance goes negative. You have three honest options:

Carry the negative forward against future earnings. This is the common one and the fairest: the next commissions they earn pay down the deficit before anything becomes payable again.
Reverse the transfer. If you pay through Stripe Connect, you can reverse a past transfer, but it is aggressive and it will surprise people. Reserve it for fraud or for affiliates who have gone silent with a large negative.
Write it off below a threshold. Chasing back a 4 dollar commission costs more in goodwill than it returns. Pick a floor and absorb anything under it.

Whatever you choose, decide it once and apply it the same way every time. Inconsistent clawbacks are how you lose good affiliates.

The Stripe wiring

Two webhooks drive this: charge.refunded and charge.dispute.created. Each one looks up the commission entries tied to that charge and writes a reversed entry for the matching amount. For a partial refund, reverse the same proportion of the commission, not the whole thing.

A detail worth stating: process these as triggers to re-read state, not as the final word. A refund webhook can arrive while the original commission is still settling on your side. Look up the current state of the charge and the existing entries, then write the reversal against what you actually find. (Idempotency matters here too: key the reversal on the refund ID so a redelivered webhook doesn't reverse twice.)

Show pending and available separately

This is a product decision as much as an accounting one. Affiliates hate surprise clawbacks more than they like fast payouts. If your dashboard shows one big "earnings" number that quietly drops when a refund lands, every reversal feels like you took their money. Show pending and available as two separate numbers, with the date each pending commission becomes available. Then nobody counts money that isn't theirs yet, and a reversal during the pending window is a non-event instead of a support ticket.

We keep payout fees at zero and we run this exact pending-then-available model, because the trust cost of getting it wrong is higher than any fee. (Disclosure: I work on Referralful, https://referralful.com/?utm_source=dev.to&utm_medium=content&utm_campaign=article , affiliate software built on Stripe.)

Design the ledger and the holdback before you write your first commission. Retrofitting an immutable ledger onto a system that stored a single balance is a migration you do not want to run while affiliates are watching their numbers.

Paying SaaS affiliates on Stripe: the part teams forget to build

Mihir kanzariya — Tue, 16 Jun 2026 07:32:09 +0000

I build affiliate software for SaaS, so I spend most of my time in the part of an affiliate program people forget about: paying the affiliates. Attribution gets the attention. Payouts are where programs break.

A few things bite once the first commissions come due. How I handle each on Stripe.

A commission is not a payout

The first mistake is treating "this referral converted" as "we owe this person money now." You don't, yet. A Stripe payment can be refunded, disputed, or fail on the next renewal. Pay the affiliate the moment the charge succeeds and you end up clawing money back, which is awkward and sometimes impossible.

So I keep two states. A commission is earned when the payment clears, and payable only after a hold period. I use 30 days, to cover the refund window. During the hold I listen to charge.refunded and charge.dispute.created and reverse the commission before it becomes payable. The affiliate sees "pending" until then. That is honest, and it saves you the clawback email.

Recurring commissions need a stop date

If you pay 30% for 12 months on a subscription, you count months, not payments. A customer who pauses and resumes, or downgrades mid-term, throws off invoice.paid events that no longer map to "month 4 of 12."

Anchor the schedule to the subscription's start. On each invoice.paid, compute how many months have passed since the referral converted. Past month 12 the commission is zero, even though the invoice still fires. Storing the referral date and doing the math each time beats a running counter that drifts every time a subscription changes.

Payout rails: Connect or manual

You have two honest ways to get money to affiliates.

Stripe Connect with Express accounts. The affiliate onboards once, Stripe handles KYC and bank details, and you send transfers. Good at volume. It adds onboarding friction and puts you inside Stripe's payout timing.
Manual payouts through PayPal, Wise, or bank transfer, tracked in your own ledger. Less friction to start, more bookkeeping for you.

The ledger matters more than the rail. Every commission needs a row with its state (earned, payable, paid, reversed) and a payout reference. If your "who do we owe" number lives only in a Stripe dashboard view, you cannot answer an affiliate's "where's my money" email.

The boring failures that cost trust

Minimum thresholds. Pay out at $50 instead of $4.20 and you cut transfer fees and noise. Show the threshold so nobody is surprised.
Failed payouts. Bank details go stale. Catch transfer.failed and payout.failed, mark the commission payable again, and email the affiliate. A silent failure is how you lose a good promoter.
Currency. Your affiliate in another country thinks in their currency. Decide up front whether you pay in your settlement currency or theirs, and put it in the terms.
Tax forms. US payouts over the reporting threshold mean a 1099. Collect tax info at onboarding, not in December.

Why I keep payout fees at zero

Some affiliate platforms take a cut of every payout on top of their monthly fee. That charges you twice: once to run the program, again to pay the people growing it. When I built Referralful (disclosure: my product, affiliate software for SaaS built on Stripe), I kept payout fees at 0%. The commission belongs to the affiliate.

Attribution tells you who earned the money. The payout pipeline tells you whether they trust you enough to keep selling for you. The second one is where I would spend the time.

Recurring affiliate commissions on Stripe: the edge cases nobody warns you about

Mihir kanzariya — Sun, 14 Jun 2026 06:55:35 +0000

Every tutorial on building affiliate tracking with Stripe covers the happy path: user clicks a referral link, signs up, pays, affiliate gets a commission. Done.

But if you are building recurring commissions for a SaaS product, the happy path is maybe 60% of what actually happens. The other 40% is edge cases that will either cost you money, break affiliate trust, or both.

Here is what I ran into building commission logic on top of Stripe's billing API, and how I handled each case.

1. Plan changes mid-cycle

A customer upgrades from $20/mo to $50/mo halfway through their billing cycle. The affiliate was earning 30% on the $20 plan. Do they now earn 30% on $50? On the prorated amount for this cycle? On the full $50 starting next cycle?

The answer depends on how you listen to Stripe events. If you use invoice.paid (which you should for recurring), you will get the prorated amount for this cycle. The affiliate's commission naturally adjusts because it is always a percentage of what was actually charged.

The mistake I see: using customer.subscription.updated to recalculate commissions. That event fires before payment, so you end up crediting commissions on amounts that might fail to charge.

// Good: commission based on what was actually paid
stripe.webhookEndpoints.create({
  enabled_events: ['invoice.paid'],
});

// Inside your webhook handler
const amountPaid = invoice.amount_paid; // actual charged amount
const commission = Math.round(amountPaid * commissionRate);

2. Failed payments and dunning

Stripe retries failed payments over a configurable window (Smart Retries or your own schedule). During that window, the subscription is past_due but not cancelled.

Should the affiliate earn commission on a payment that fails three times and then succeeds on the fourth retry? Yes, because the customer paid. Should they earn commission if the payment never succeeds and the subscription cancels? Obviously not.

The key insight: if you only listen to invoice.paid, this handles itself. You never credit a commission until money actually moves. The problem comes when you try to get clever with invoice.payment_failed and preemptively clawback. Do not do that. Wait for the final outcome.

3. Refunds inside vs outside the attribution window

You offer a 14-day refund policy. A customer gets a refund on day 10. The affiliate already earned commission on that payment. You need to clawback.

But what about a refund on day 45? Or day 90? At some point, the refund is a customer service decision that should not penalize the affiliate who brought a real, paying customer.

I use a simple rule: clawback commissions on refunds within the first 30 days of the specific payment. After that, the commission stands. This is fair to affiliates and prevents the situation where a 6-month customer gets a partial refund and the affiliate loses their commission retroactively.

// On charge.refunded event
const charge = event.data.object;
const paymentDate = new Date(charge.created * 1000);
const refundDate = new Date();
const daysSincePayment = (refundDate - paymentDate) / (1000 * 60 * 60 * 24);

if (daysSincePayment <= 30) {
  // Clawback the commission
  await clawbackCommission(charge.id);
} else {
  // Commission stands, log for transparency
  await logRefundNoClawback(charge.id, daysSincePayment);
}

4. Annual vs monthly: same rate or different?

A customer pays $200/year instead of $20/month. The annual plan is a discount ($240 annualized vs $200 paid). If the affiliate rate is 30%, do they earn $60 upfront or $6/month?

Most programs pay the commission on what was actually charged. So the affiliate gets 30% of $200 = $60 as a single commission when the annual invoice pays. This is simpler to implement and aligns incentives: the affiliate helped close a higher-commitment customer.

The trap: if you pay $60 upfront on annual and the customer refunds at month 3, you need to clawback $60, not $15. Annual commissions carry more clawback risk, so your refund window matters more.

5. The free trial attribution gap

Customer clicks an affiliate link, starts a 14-day free trial, and converts to paid on day 15. If your attribution only fires on checkout.session.completed, you captured the affiliate at trial start. Good.

But what if the trial does not require a payment method? Then checkout.session.completed might not fire at all during the trial. The customer adds their card later through the billing portal. If you are not careful, that second step has no affiliate context attached.

The fix: store the affiliate attribution in your own database at signup time (not in Stripe metadata alone). When the subscription transitions from trialing to active, look up the affiliate from your records, not from the Stripe event.

6. Multi-currency edge cases

Your product charges in USD, EUR, and GBP. An affiliate in the US refers a customer who pays in EUR. The commission is calculated as 30% of the EUR amount. But when you pay the affiliate, you pay in USD.

Do you convert at the exchange rate when the customer paid, or when you run payouts? If you batch payouts monthly, the exchange rate can shift 2-3% in either direction.

Pick one: convert at payment time and store the USD-equivalent commission immediately, or convert at payout time and accept the variance. I convert at payment time because it makes the affiliate's dashboard accurate in real-time. They see exactly what they earned without waiting for payout-day exchange rates.

None of these problems are hard individually. But if you do not think about them upfront, you end up with affiliate disputes, incorrect payouts, and patching logic months after launch.

The general principle: always base commissions on invoice.paid (real money moved), store attribution in your own database (not just Stripe metadata), and define your clawback rules before your first affiliate asks about them.

I build affiliate tracking for SaaS products on Stripe. If you are working on something similar, I wrote about cookie-less affiliate attribution on Stripe previously.

Tracking affiliate referrals on Stripe without third-party cookies

Mihir kanzariya — Fri, 12 Jun 2026 10:13:52 +0000

Third-party cookies are mostly gone. Safari blocks them, Firefox blocks them, and Chrome is finishing the job. If your affiliate attribution leans on a third-party cookie set on the advertiser's domain, a large share of your referrals vanish before checkout.

I build Referralful, a Stripe-native affiliate tool, so I spend most of my week on this exact problem. Here is the approach that survives cookie blocking, with the Stripe-specific parts that trip people up.

The attribution chain

A referral has to survive four hops:

Someone clicks an affiliate link.
They land on your site, browse, maybe leave and come back days later.
They start a Stripe Checkout session.
They pay, sometimes on a different device.

Each hop is a place to lose the referral. Cookies handle hop 2 badly across browsers and not at all across devices.

Step 1: capture the referral first-party

When the affiliate link hits your domain (?ref=jane), read the code and store it in two places, not one: a first-party cookie on your domain, plus localStorage as a backup. First-party cookies on your own domain are not the ones browsers are killing. The 60-day window most programs advertise is just a cookie max-age.

// on landing, if ?ref= is present
const ref = new URL(location.href).searchParams.get('ref')
if (ref) {
  document.cookie = `rf_ref=${ref}; Max-Age=${60*24*60*60}; Path=/; SameSite=Lax`
  localStorage.setItem('rf_ref', ref)
}

Step 2: hand the referral to Stripe at checkout

This is the step people miss. Do not rely on the cookie still being readable when the webhook fires. Pass the referral into the Checkout Session as client_reference_id (or metadata) when you create it:

const session = await stripe.checkout.sessions.create({
  mode: 'subscription',
  line_items: [{ price: priceId, quantity: 1 }],
  client_reference_id: readRef(),        // 'jane'
  metadata: { affiliate_ref: readRef() },
  success_url: '...', cancel_url: '...',
})

Now the referral lives inside the Stripe object. It no longer depends on a cookie, a device, or how many days pass before payment.

Step 3: attribute on the webhook, not the browser

Listen for checkout.session.completed and read the reference back. That is your attribution. Server-side, deterministic, and device-independent.

// webhook
if (event.type === 'checkout.session.completed') {
  const s = event.data.object
  const ref = s.client_reference_id || s.metadata?.affiliate_ref
  if (ref) await creditAffiliate(ref, s.customer, s.amount_total)
}

Step 4: recurring commissions follow renewals

The hard part with SaaS is that the first payment is not the only one. Store the affiliate against the Stripe customer at first attribution, then listen to invoice.paid for that customer and credit the commission again on each renewal, for as long as your terms allow (we use the first 12 months of payments).

if (event.type === 'invoice.paid') {
  const inv = event.data.object
  const ref = await affiliateForCustomer(inv.customer)
  if (ref && withinCommissionWindow(inv.customer)) {
    await creditAffiliate(ref, inv.customer, inv.amount_paid)
  }
}

Three things we learned the hard way

Refunds claw back commissions. Listen to charge.refunded and reverse the credit, or your payouts slowly drift above your revenue.
Self-referrals are most of your fraud. Block a conversion when the affiliate's email or card fingerprint matches the buyer.
Coupon codes are a second attribution path. If an affiliate shares a code instead of a link, attribute on the discount in the session.

None of this needs a third-party cookie. The trick is to stop treating the browser as the source of truth and let Stripe carry the referral through to the webhook.

Disclosure: I build Referralful, which does the above for Stripe SaaS. The pattern is the same whether you build it yourself or buy it.

I replaced 4 SaaS tools with one workspace. Here's what actually happened.

Mihir kanzariya — Fri, 13 Mar 2026 21:38:38 +0000

So about 8 months ago I got fed up.

Our team of 6 was paying for Jira, Notion, Slack (premium), and some random bug tracker I can't even remember the name of. Total monthly bill was somewhere around $380. Not insane money, but the real cost wasn't the subscriptions.

The real cost was context switching.

The tab hell problem

Here's what a typical morning looked like: open Jira to check sprint status, switch to Notion to read the spec, hop to Slack because someone pinged about a blocker, back to Jira to update the ticket, then realize the spec in Notion is outdated because someone updated it in a Google Doc instead.

Sound familiar? Yeah.

I counted one day and I had 23 tabs open across 4 different tools, all for the same project. My brain was spending more energy remembering where stuff lived than actually doing the work.

What I actually wanted

I wrote down what our team actually needed:

Kanban boards (not the overly complex Jira kind, just cards in columns)
A wiki/docs space that lives next to the tasks
Real-time editing so we stop stepping on each other's work
Some kind of notifications that aren't as noisy as Slack

That's it. We didn't need 400 Jira fields. We didn't need Notion's infinite nesting rabbit hole. We just needed stuff to be in one place.

The switch

We moved everything into a single workspace tool. Tasks, docs, discussions, all in one app. The first week was rough honestly, people kept going back to old habits. But by week 3 something clicked.

Meetings got shorter because everyone could see the same board and the same docs without sharing links. Standup went from 25 minutes to 12 because nobody was digging through three apps to find their update.

What actually improved

The biggest win was fewer "where is this?" questions. When your tasks and docs live in the same space, you don't lose context. You click from a task directly into the related doc. No more copying Notion links into Jira tickets.

Onboarding got way faster too. New devs had one app to learn instead of four. One login, one search bar, one place to look.

And the notification noise dropped dramatically. Instead of Slack pings for every little thing, we use inline comments on the actual work. Way less distracting.

What I miss (being honest)

Jira's reporting was solid if you actually used it. The burndown charts and velocity tracking were nice for sprint retros. Most unified tools don't go that deep on analytics yet.

And Notion's database views were genuinely powerful for non-dev use cases. Our marketing team loved those.

But for our dev team? The tradeoff was worth it. Less context switching > fancier features we barely used.

The numbers

Before: ~$380/month across 4 tools, 23+ tabs open, 25 min standups
After: way less per month, usually 4-6 tabs total, 12 min standups

The time savings compound. When you're not hunting for information across apps, you just... build stuff faster. Novel concept I know.

tl;dr

If your team is small-to-mid size and you're juggling Jira + Notion + Slack + whatever, seriously consider consolidating. The fancy features you think you need? You probably don't. What you need is less friction between thinking about what to build and actually building it.

Why your bug reports are useless (and how to fix them)

Mihir kanzariya — Fri, 13 Mar 2026 21:38:05 +0000

I've spent the last year building dev tools and honestly, the thing that frustrates me most isn't the code. It's the bug reports.

You know the ones. "It's broken." "The page doesn't work." "Something is wrong with the login." Cool. Super helpful. Let me just fix "something" real quick.

The problem isn't laziness

Most people genuinely want to help when they report a bug. They just don't know what information matters. And honestly, why would they? They're not developers. They don't know that the difference between Chrome 120 and Safari 17 might be the entire reason things are broken.

So they do their best. They write "the button doesn't work" and move on with their day.

What actually makes a bug report useful

After triaging hundreds of reports across multiple projects, here's what I actually need to reproduce a bug fast:

1. What were you trying to do?
Not "I was on the website." Tell me the specific action. "I clicked the save button after editing the project name." That's gold.

2. What happened vs what you expected?
"I clicked save and nothing happened. I expected it to save and show a success message." Now I know exactly what to look for.

3. The boring technical stuff
Browser, OS, screen size, whether you're on mobile or desktop. I know, nobody wants to write this down. But it matters so much. Half the bugs I've seen in the last 6 months were viewport or browser specific.

4. Steps to reproduce
If you can tell me 1, 2, 3 what you did before things broke, I can probably fix it in 20 minutes instead of 2 days.

The real solution: don't make users think about it

Here's the thing I've realized. Asking users to provide all this context is fighting human nature. People won't do it consistently no matter how many times you ask.

The better approach is capturing this stuff automatically. There are tools now that grab the browser info, the page URL, even let users click on the exact element that's broken. The technical context gets attached without the user doing anything extra.

I've been experimenting with element-level bug reporting where users literally just click on what's broken, add a quick note, and the tool captures everything else. CSS selectors, viewport size, browser version, the URL, a screenshot. All automatic.

The difference in triage time is honestly wild. What used to take 30 minutes of back-and-forth DMs now takes like 2 minutes to understand and start fixing.

tl;dr

Bad bug reports aren't a people problem, they're a tooling problem. Stop asking users to be better reporters and start giving them tools that capture context automatically. Your future self debugging at 2am will thank you.

Why I stopped juggling Notion and Jira (and what I use now)

Mihir kanzariya — Sat, 07 Mar 2026 14:44:32 +0000

I've been building software for about 4 years now. And for most of that time, my workflow looked like this:

Jira for task tracking
Notion for docs, wikis, meeting notes
Slack for everything else

Three tabs minimum, always open. Context switching all day.

The problem nobody talks about

Everyone debates Jira vs Linear or Notion vs Obsidian. But the real productivity killer isn't which tool you pick — it's having too many of them.

I'd create a task in Jira, write the spec in Notion, then paste the link back into the Jira ticket. When someone asked "where's the doc for X?" the answer was always "let me find it." Half my day was just navigating between tabs.

And syncing? Forget about it. Notion docs would get stale because nobody remembered to update them after the sprint changed. Jira tickets referenced Notion pages that no longer existed.

What I tried first

I went through the usual suspects:

Linear — great for tasks, but still needed something for docs
ClickUp — tried to do everything, felt bloated
Monday.com — too much drag-and-drop, not enough keyboard shortcuts for my taste

None of them solved the core problem: I still needed multiple tools.

What actually worked

About 8 months ago I started using Blocpad — basically a workspace that combines kanban boards, a slash-command editor (like Notion), and wiki pages all in one app. Everything syncs in real time.

The thing that sold me honestly wasn't some killer feature. It was just... not having to switch tabs anymore. I create a task, write the spec right there in the same place, and my team can see both without asking "where's the link?"

Some things I actually like:

Tasks and docs live together. No more pasting links between tools
Real-time presence — I can see who's looking at what, which sounds small but actually reduces a lot of "hey are you working on this?" messages
The editor feels snappy. Not Notion-level polish yet but honestly I care more about speed than animations

Things that are still rough:

No mobile app yet (they're working on it apparently)
The onboarding could be better — took me a bit to figure out the slash commands
Missing some integrations I want (GitHub is there, but I want better Slack integration)

The actual lesson

Look, I'm not saying everyone should use what I use. The point is: if you're spending 20+ minutes a day just navigating between your tools, that's a workflow problem worth solving.

Before you add another tool to your stack, ask yourself if you can remove one first. The best productivity hack I found this year wasn't a new app — it was having fewer apps.

Currently building a SaaS and sharing the journey. If you're into #buildinpublic stuff, I post updates on Twitter too.

Why I stopped juggling Notion and Jira (and what I use now)

Mihir kanzariya — Fri, 06 Mar 2026 17:42:34 +0000

I've been building SaaS tools for about two years now and honestly the biggest productivity killer wasn't bad code or missing features. It was switching between apps.

The setup that drove me crazy

For the longest time my workflow looked like this: Jira for tickets, Notion for docs and wikis, Slack for... well everything else. Three tabs minimum open at all times, three different search bars, three sets of notifications.

And look, these are great tools individually. I'm not here to trash them. But the constant context switching was killing my focus. I'd be writing a spec in Notion, need to reference a ticket in Jira, then someone pings me on Slack about that same ticket, and suddenly I've lost 15 minutes just navigating between windows.

The breaking point

The real moment was when I realized my team was duplicating info everywhere. We had the same feature described in a Notion doc AND a Jira epic AND a Slack thread. When something changed, maybe one of those got updated. Maybe.

I spent a whole Friday afternoon just syncing information across tools. That's when I knew something had to change.

What I actually wanted

Pretty simple honestly:

Tasks and docs in the same place so I don't copy-paste between them
Real-time collab so I'm not waiting for someone to "finish editing"
Something that doesn't take 3 months to set up (looking at you, Jira)
A slash command editor because I've been spoiled by Notion's UX

What I ended up building

So I ended up building Blocpad because nothing quite fit. It's basically kanban boards + a Notion-style editor + real-time presence all in one app. Built it with Next.js and Supabase.

The biggest win? When someone creates a task, the context is RIGHT THERE. The doc, the discussion, the status — same page. No more "let me find that Notion link" or "check the Jira ticket for details."

Stuff I learned along the way

You don't need every feature on day one. We started with just tasks and docs. Added the wiki later. Added integrations even later. Shipped fast, iterated based on what people actually asked for.

Real-time is harder than you think. Supabase Realtime handles a lot but conflict resolution in collaborative editing is a whole rabbit hole. Worth it though — seeing cursors move in real time makes remote work feel less lonely lol.

All-in-one doesn't mean bloated. The temptation is to add everything. We actively resist adding features that don't serve the core workflow. If you need advanced Gantt charts, use a dedicated tool. We're not trying to replace everything, just the daily stuff.

Is it for everyone?

Nah probably not. Big enterprises with 500+ person teams and complex ITSM needs should stick with Jira tbh. But if you're a startup, a small dev team, or a solo founder who's tired of paying for 4 different tools that don't talk to each other... might be worth a look.

We're still early and building in public. Would love to hear how other people handle the multi-tool chaos — or if you've just accepted it as part of life at this point lol.

What's your current stack for project management + docs? Genuinely curious if anyone's found a setup that doesn't involve 5 browser tabs.

Simple Search componentReactJS

Mihir kanzariya — Thu, 14 Nov 2019 09:23:20 +0000

https://gist.github.com/mihir-kanzariya/f11377a28badb4471cfc033572d7c862