Built Climb after getting frustrated comparing job offers where one was RSU-heavy/backloaded and another was flat salary. Total comp numbers hide when the money actually shows up, a bigger TC number can genuinely be the worse offer if most of it doesn't vest until year 3-4.
The core idea: instead of a single TC number, you enter base/bonus/RSU grant/vesting schedule for up to 3 offers and it charts cumulative earned value year over year. You can see the cliff, not just read about it. Also shows walk-away value if you leave after year 1.
Launched on Product Hunt today, no ads, no existing audience, just posted and answered questions as they came in. A few things I didn't expect:
The single most requested feature, independently, from 3+ different commenters: modeling annual refresher grants, since real offers aren't static and the flat year-3/4 line was misleading people
People are using it for exactly the use case I built it for, someone commented they plotted two real offers and finally understood why the bigger headline number was actually worse in year 2
Comment-to-upvote ratio has been weirdly low all day, which I think is partly ad blockers eating GA4 tracking and partly just how PH's algorithm handles a first-time launch with no existing following
Free, no signup, single static HTML page: https://climb-offer-calculator.netlify.app/
Building refreshers into v2 next based on today's feedback. Curious if anyone here has dealt with monetizing a tool like this, right now leaning toward a small one-time paid tier for the more advanced modeling (refreshers, severance/acceleration scenarios, inflation-adjusted view) rather than a subscription, but open to hearing how others have approached it.
Showing when compensation becomes real is a much more useful lens than comparing headline TC numbers.
The refresher requests are especially interesting—they suggest people are starting to think of Climb as a decision tool rather than just a calculator.
That's a really useful way to put it, and honestly a more precise description than I'd landed on myself. I built it as a calculator, but you're right that the refresher requests point at something different — people aren't just asking "show me a bigger number," they're asking "help me trust this number enough to act on it." That's a decision-tool question, not a calculator one.
It's actually changing how I'm thinking about what's next, less "add more math," more "what's the next thing someone needs to trust before they'll make the call." Appreciate you naming it, this is the kind of feedback that reframes the roadmap instead of just adding to it.
Appreciate the context.
The shift from calculating an answer to helping someone trust a decision is the interesting part here.
Would be good to discuss how you're thinking about that transition in the product.
What's the best email to reach you on?
Appreciate you pushing on this, it's the question I've actually been sitting with since your last comment.
The shift I'm noticing: a calculator just needs to be correct. A decision tool needs to be trustworthy enough to act on, which is a different bar. Refresher modeling, the acceleration toggle, inflation adjustment, none of that was me trying to make the math fancier. It came from realizing that people won't trust a walk-away number if it's obviously oversimplified in ways they can spot (like a flat year-3/4 line with no refreshers modeled). So right now my filter for what goes into the product is less "can I compute this" and more "does skipping this make someone doubt the number enough not to act on it."
Where I think this goes next: probably more transparency about why a number is what it is, not just showing the number — so the tool earns trust by showing its work, not just by adding more features. Still figuring out what that looks like concretely.
Happy to keep this going by email if useful. My email is just the username plus @gmail
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.