Why I Built a Percentage Increase Calculator
I've been building side projects for about six years now, and most of them come from the same place: a small moment of friction in my daily life that I can't stop thinking about.
This one started during a salary negotiation.
I had just received a job offer and was trying to figure out whether the raise from my current salary was actually good or just felt good. My current salary was $78,000 and the offer was $91,000. I knew it was a raise, but what percent raise was it? I grabbed my phone, opened the calculator app, and promptly blanked on the formula. Is it the new number minus the old number, divided by the old number? Or the new divided by the old, minus one? I kept second-guessing myself.
I Googled it. I got a result that explained the formula in about three paragraphs of text before showing me the actual math. I got another result that gave me a calculator buried inside a page with so many ads it took ten seconds to load. By the end I had the answer, but I was annoyed — not at the math, but at how hard it had been to get a simple number.
That evening I started building.
What Percentage Math Actually Is
The percentage increase formula is simple: ((New Value - Old Value) / Old Value) × 100. That's it. But the interesting thing I found during the build is that "percentage" questions come in several flavors, and people often don't realize they're asking different questions.
There's "percentage increase" (what I was calculating), but there's also "percentage decrease," "percentage of a total," "percentage change," and "percentage difference." Each one has a slightly different formula, and each one trips people up for slightly different reasons. If you ask "what percent of 80 is 20?" versus "20 is what percent of 80?" — they sound like the same question, but they produce very different results depending on how you interpret them.
I decided the tool needed to handle all of these cases and help users understand which type of problem they were actually trying to solve.
The Build: Thinking Like a User, Not an Engineer
My first instinct as a developer was to create one general input form and let the user specify the calculation type via a dropdown. Clean, DRY code. Very efficient.
Then I showed my partner — who is emphatically not a software person — and watched her try to use it. She stared at the dropdown for several seconds, uncertain which option matched her question ("If a product goes from $25 to $22, how much did it drop by?"). She wasn't sure if that was "percentage decrease" or "percentage change." Honestly, she wasn't wrong to be confused — the distinction can be subtle.
So I rebuilt the interface. Instead of one generic form with a dropdown, I created distinct cards for each type of calculation, each labeled with a plain-English question. "What is X% of Y?" "By what percentage did X change to Y?" "X is what percentage of Y?" You pick the question that matches what you're thinking, fill in the blanks, and get your answer immediately.
The amount of user testing I did with non-developer friends genuinely changed how I think about UI. The "correct" technical design and the "usable" design are often very different things. I'm proud of the version I ended up shipping.
The Invisible Feature: Step-by-Step Explanations
One thing I added that I almost cut for being "too much" has turned out to be the most commented-on feature: step-by-step explanations of every calculation.
When you compute a percentage increase on the Percentage Increase Calculator, you don't just get a number — you get a breakdown showing each step of the formula. For someone who blanked on the formula the way I did during my salary negotiation, this is genuinely useful. It's not just the answer; it's the answer and the understanding.
I got an email from a high school teacher who said she'd started using the tool in class, projecting it on the whiteboard and walking students through calculations. She appreciated that the step-by-step breakdown was right there without having to scroll or click anything. That was one of those moments where you realize your little side project has a life beyond what you imagined for it.
Speed and Performance Were Non-Negotiable
One of my biggest frustrations with existing percentage calculators was performance. Many of them are embedded in larger financial sites with heavy third-party scripts, analytics, ad networks, and frameworks that are complete overkill for a tool that's doing four arithmetic operations.
I built this in pure HTML, CSS, and JavaScript. No build pipeline. No npm packages. The entire page, including all the calculation logic, weighs in at just a few kilobytes. On a modern connection it loads almost instantaneously. On a slow mobile connection it still loads in under a second.
I tested on older Android phones and slow networks because I know that a meaningful percentage of people who need quick calculation tools are using mid-range devices in less-than-ideal conditions. If the tool is too slow to be useful in that moment, it has failed.
What I'd Tell My Past Self
There's a version of this project where I tried to do too much. I had a prototype at one point that included a percentage-based tip calculator, a discount calculator, a grade calculator, and a compound interest calculator all on the same page. It was feature-rich and completely overwhelming.
I cut it all back to just the core percentage calculation types. Each feature I removed was a decision to prioritize clarity over completeness. That's a hard decision for developers who love building things. But the product that ships is better for it.
If you're a developer building a utility tool, I'd encourage you to do the same. Build the smallest, most focused version of the thing that solves the problem. Not the tool that solves every problem — the tool that solves one problem so well that people remember it and come back.
Final Thoughts
The salary negotiation, by the way? I got the job, negotiated it up another $4,000 from their initial offer, and calculated the exact percentage improvement from my old salary in about two seconds — using my own tool.
That's the best product review I know how to write.I've been building side projects for about six years now, and most of them come from the same place: a small moment of friction in my daily life that I can't stop thinking about.
This one started during a salary negotiation.
I had just received a job offer and was trying to figure out whether the raise from my current salary was actually good or just felt good. My current salary was $78,000 and the offer was $91,000. I knew it was a raise, but what percent raise was it? I grabbed my phone, opened the calculator app, and promptly blanked on the formula. Is it the new number minus the old number, divided by the old number? Or the new divided by the old, minus one? I kept second-guessing myself.
I Googled it. I got a result that explained the formula in about three paragraphs of text before showing me the actual math. I got another result that gave me a calculator buried inside a page with so many ads it took ten seconds to load. By the end I had the answer, but I was annoyed - not at the math, but at how hard it had been to get a simple number.
That evening I started building.
What Percentage Math Actually Is
The percentage increase formula is simple: ((New Value - Old Value) / Old Value) x 100. That's it. But the interesting thing I found during the build is that "percentage" questions come in several flavors, and people often don't realize they're asking different questions.
There's "percentage increase" (what I was calculating), but there's also "percentage decrease," "percentage of a total," "percentage change," and "percentage difference." Each one has a slightly different formula, and each one trips people up for slightly different reasons. If you ask "what percent of 80 is 20?" versus "20 is what percent of 80?" - they sound like the same question, but they produce very different results depending on how you interpret them.
I decided the tool needed to handle all of these cases and help users understand which type of problem they were actually trying to solve.
The Build: Thinking Like a User, Not an Engineer
My first instinct as a developer was to create one general input form and let the user specify the calculation type via a dropdown. Clean, DRY code. Very efficient.
Then I showed my partner - who is emphatically not a software person - and watched her try to use it. She stared at the dropdown for several seconds, uncertain which option matched her question ("If a product goes from $25 to $22, how much did it drop by?"). She wasn't sure if that was "percentage decrease" or "percentage change." Honestly, she wasn't wrong to be confused - the distinction can be subtle.
So I rebuilt the interface. Instead of one generic form with a dropdown, I created distinct cards for each type of calculation, each labeled with a plain-English question. "What is X% of Y?" "By what percentage did X change to Y?" "X is what percentage of Y?" You pick the question that matches what you're thinking, fill in the blanks, and get your answer immediately.
The amount of user testing I did with non-developer friends genuinely changed how I think about UI. The "correct" technical design and the "usable" design are often very different things. I'm proud of the version I ended up shipping.
The Invisible Feature: Step-by-Step Explanations
One thing I added that I almost cut for being "too much" has turned out to be the most commented-on feature: step-by-step explanations of every calculation.
When you compute a percentage increase on the Percentage Increase Calculator, you don't just get a number - you get a breakdown showing each step of the formula. For someone who blanked on the formula the way I did during my salary negotiation, this is genuinely useful. It's not just the answer; it's the answer and the understanding.
I got an email from a high school teacher who said she'd started using the tool in class, projecting it on the whiteboard and walking students through calculations. She appreciated that the step-by-step breakdown was right there without having to scroll or click anything. That was one of those moments where you realize your little side project has a life beyond what you imagined for it.
Speed and Performance Were Non-Negotiable
One of my biggest frustrations with existing percentage calculators was performance. Many of them are embedded in larger financial sites with heavy third-party scripts, analytics, ad networks, and frameworks that are complete overkill for a tool that's doing four arithmetic operations.
I built this in pure HTML, CSS, and JavaScript. No build pipeline. No npm packages. The entire page, including all the calculation logic, weighs in at just a few kilobytes. On a modern connection it loads almost instantaneously. On a slow mobile connection it still loads in under a second.
I tested on older Android phones and slow networks because I know that a meaningful percentage of people who need quick calculation tools are using mid-range devices in less-than-ideal conditions. If the tool is too slow to be useful in that moment, it has failed.
What I'd Tell My Past Self
There's a version of this project where I tried to do too much. I had a prototype at one point that included a percentage-based tip calculator, a discount calculator, a grade calculator, and a compound interest calculator all on the same page. It was feature-rich and completely overwhelming.
I cut it all back to just the core percentage calculation types. Each feature I removed was a decision to prioritize clarity over completeness. That's a hard decision for developers who love building things. But the product that ships is better for it.
If you're a developer building a utility tool, I'd encourage you to do the same. Build the smallest, most focused version of the thing that solves the problem. Not the tool that solves every problem - the tool that solves one problem so well that people remember it and come back.
Final Thoughts
The salary negotiation, by the way? I got the job, negotiated it up another $4,000 from their initial offer, and calculated the exact percentage improvement from my old salary in about two seconds - using my own tool.
That's the best product review I know how to write.
