Why Developers Should Stop Chasing Commission and Start Building for Product-Market Fit

Andy McCall's advice to early-career salespeople—stop optimizing for commission and find great products—applies directly to developers building payment and fintech systems. The parallel is real: many engineers chase the highest-paying contract or the most feature-rich API without asking whether they're building on a foundation that actually solves a problem at scale.

The Developer Equivalent of Chasing Commission

When you're integrating ACH payouts, Visa Direct, or RTP into a platform, it's tempting to pick the rail with the lowest per-transaction cost or the fastest settlement time. A 0.5% savings on 10,000 monthly transactions looks good on a spreadsheet. But if you're routing transactions to a system that has a 12% return rate, or one where your error handling is brittle, you've optimized for the wrong metric.

McCall's insight—that the product itself matters more than the payout structure—translates to: pick the payment rail and integration pattern that fits your actual use case, not the one that looks best in isolation.

What Actually Matters: Product-Market Fit for Payments

For developers, this means:

1. Understand your return profile first. Before you optimize cost, know what percentage of transactions will fail. ACH has return codes (R01 for insufficient funds, R10 for unauthorized, R29 for corporate account closed). If 8% of your payouts are returning as R01, you need retry logic and dunning workflows—not cheaper per-transaction rates. The cost of handling returns often exceeds marginal savings on the base fee.

2. Build for the rail that matches your settlement requirements. Same-day ACH costs more than standard ACH (typically 2–5 cents vs. negligible fees), but if your product requires next-day settlement for user trust, standard ACH breaks your value proposition. RTP (Real-Time Payments) settles in seconds but has per-transaction costs of 25–50 cents. Visa Direct is reversible within 45 days but costs $1–2 per transaction. Pick based on what your users actually need, not what's cheapest.

3. Invest in observability early. The real cost of a payment integration isn't the per-transaction fee—it's the operational overhead of handling exceptions. Build logging and alerting for return codes, settlement delays, and reconciliation gaps before you're in production. A developer who can decode an R03 return (no account) and route it to a secondary rail programmatically saves more money than any rate negotiation.

Concrete Example: ACH Return Handling

Here's what good looks like:

if return_code == "R01":  # Insufficient funds
    # Retry in 2 days (funds may arrive)
    schedule_retry(payout_id, days=2)
    notify_user("Payment delayed, will retry")

elif return_code == "R10":  # Unauthorized
    # Don't retry; route to Visa Direct or manual review
    route_to_alternate_rail(payout_id, rail="visa_direct")

elif return_code == "R29":  # Corporate account closed
    # Permanent failure; ask for new account
    flag_for_user_action(payout_id, reason="account_closed")

This logic—not the transaction fee—is what scales your product.

The Hiring Parallel

McCall also mentions that founders wait too long to hire great sales leaders. For engineering teams, the equivalent is waiting too long to hire someone who understands payment operations end-to-end. A developer who can reason about return codes, settlement timing, and multi-rail routing is worth more than three engineers who can only integrate a single API.

The Bottom Line

Optimize for the product that works, not the one that looks cheapest. For payment systems, that means understanding your failure modes, building robust error handling, and picking the rail that serves your actual use case—not the one with the lowest per-transaction cost. The commission (or savings) will follow.

Decoding ACH return codes programmatically? The ACH Return Codes API returns the full Nacha R01–R85 set with plain-language descriptions and handling guidance.

DEV Community