Formpey: 90k+ impressions on LinkedIn, 35 signups later
I'm Pankaj — a frontend engineer until May, when I got laid off along with a chunk of my team. I spent the next 2 months doing what everyone does after a layoff: applying, interviewing, waiting. But somewhere in there, I also started building.
Yesterday I launched Formpey here — my first Product Hunt launch.
The problem: In India, if you want to collect money through a form — event tickets, workshop fees, batch enrollments — there's no single tool that does it well. Google Forms can't take payments. A Razorpay payment link has no form logic. So people stitch both together with a spreadsheet, then spend hours matching UPI screenshots to figure out who actually paid.
What Formpey does: Write your form like a document, add a price, publish. Respondents pay by UPI, card, or netbanking as they submit — and the money settles straight into your own Razorpay account. Zero commission; we never touch the funds.
I built this solo — editor, form runtime, and the payment reconciliation system, which I didn't just build but verified: load-tested to ~288 requests/second, and a real payment hand-reconciled against the Razorpay dashboard with zero mismatches before I called it done.
It's live now — free to build and publish, no cap on forms or responses.
Since posting about this on LinkedIn a few days ago, it's crossed 90k+ impressions, 35 signups, and 50 forms created — all organic, no ads.
I'd love this community's eyes on it — you're one of the toughest and most useful crowds for early feedback. Try it, break it, tell me what's missing or what you'd actually pay for.
I'll be in the comments all day, happy to answer anything. 🙏
Replies
The part that stands out to me isn't the load test number, it's that you hand reconciled a real payment against the Razorpay dashboard before calling it done. Most people ship on the load test alone and never check whether the money actually landed right. Curious what your plan is for catching a mismatch once you're past the point where checking every payment by hand is realistic.
@abdullah_javaid3 Great question, and it's the part I built the second half of the system for.
The reconciliation job doesn't wait on webhooks — it polls Razorpay's own Orders API every 15 min, so the check is "what does Razorpay say happened," not "did a POST arrive." A separate health check then emails me only when something's actually wrong (stuck webhook, payment stuck past when reconciliation should've resolved it) — silent otherwise, on purpose.
That exact alert fired a couple hours before your comment, in fact — false alarm this time, but proof the loop's live, not theoretical.
@iampankajk Polling the source of truth instead of waiting on a webhook is the right instinct, that's basically the same pattern I lean on for verifying browser actions, re-read the actual state a moment later instead of trusting the success signal. The 15 minute interval is the number I'd poke at though. If a stuck webhook and a slow poll cycle ever overlap, does a customer see a false payment failed in that window, or does the UI just sit on pending until the next poll catches up?
@abdullah_javaid3 The 15-minute number only controls when a payment becomes eligible for polling, not when the system gives up on it. Reconciliation never writes "failed" just because a check still finds it uncaptured — that only happens after 24 hours of Razorpay's own API confirming nothing landed. So a slow webhook, or a poll that overlaps with one in flight, both just resolve to "still pending, ask again next cycle." Even that 24h mark isn't final — the status transitions explicitly allow failed → paid, so a webhook or poll arriving after the cutoff still self-corrects it.
The real tradeoff isn't false failure, it's disclosure lag: worst case, an owner's dashboard reads "pending" up to ~24h longer than reality if a webhook is lost right as a cycle overlaps. Deliberately asymmetric — a late "you got paid" costs nothing, a wrong "you didn't" costs a support ticket and trust.