Freelancers in Mexico often start with a tempting formula: take the monthly income they want, divide it by the number of hours they expect to work, and publish that number as an hourly rate. The result is usually too low because it treats every working hour as billable and ignores operating costs, time off, and uncertainty.
This article shows how I built a small, privacy-first freelance rate calculator in plain HTML and JavaScript. It makes the assumptions visible without an account, upload, framework, or server-side database.
The model
A practical starting point is:
billable hours = working hours × billable ratio
required revenue = target income + monthly expenses + contingency
hourly rate = required revenue ÷ billable hours
The billable ratio matters. Administration, proposals, learning, breaks, and unpaid client communication all consume time. A freelancer who works 160 hours in a month may only be able to invoice 80–110 of them.
The contingency can be a fixed amount or a percentage. A percentage is useful when expenses or income vary. For example, with a 10% buffer, calculate the base as target income plus monthly expenses, calculate 10% of that base, and add the result before dividing by billable hours.
The implementation should handle invalid inputs before calculating. Zero or negative billable hours must not produce a misleading result, and a missing field should be visible to the user instead of silently becoming zero.
Why plain JavaScript is a good fit
For a personal pricing calculator, a static page has useful properties:
- It loads quickly and can work without a framework or build step.
- The formula is visible and auditable in the browser.
- There is no account or server-side database to maintain.
- The inputs can stay in the browser, which is appropriate for private financial planning.
- The same calculation can be reused in a quote or receipt workflow.
The trade-off is that a static page does not replace professional tax or accounting advice. It is a planning aid, not a promise of income or a legal calculation.
A small UX detail that improves the result
Show the intermediate values, not only the final rate. A useful result panel can display estimated billable hours, monthly revenue required, contingency amount, suggested hourly rate, and a short explanation of which assumptions drove the result.
This gives the freelancer something they can challenge. If the rate is unexpectedly high, they can decide whether to change expenses, capacity, target income, or the billable ratio. That is more useful than hiding the assumptions behind a single number.
Keep the tool portable
If the calculator is used offline, avoid external fonts, analytics scripts, and runtime dependencies. Use semantic HTML, labels connected to inputs, keyboard-friendly controls, and a clear focus state. Test the page with JavaScript disabled so that the explanatory content still makes sense even when the calculation is unavailable.
For a tool that eventually grows into quotes, receipts, or tracking, keep the calculation function separate from the DOM code. A pure function can receive target income, monthly expenses, working hours, billable ratio, and contingency ratio; it can validate billable hours, calculate the revenue requirement, and return the intermediate values and final rate. The page can then format the result without mixing business logic and presentation.
The pure function is easy to test with a few known examples. Test a normal case, zero billable hours, an empty field, and a very low billable ratio. These tests catch more useful mistakes than checking only whether a button appears to work.
What I learned from making a small version
The most important design decision was keeping the free calculation useful on its own. A visitor should be able to understand the formula and get a result without creating an account or uploading financial data. Optional offline templates can help with the next step, but they should not be required to evaluate the basic idea.
That separation also makes the project easier to maintain. The calculator can remain a small static page, while quote, receipt, and tracking workflows can evolve independently. Each one can be downloaded, inspected, and used without depending on a backend service.
Try the working example
I built a small free browser-based example for freelancers in Mexico. It runs in the browser, explains the assumptions, and links to optional offline quote and receipt templates for people who want a reusable workflow:
Open Finanzas Freelance MX: https://finanzas-freelance-mx.jfpadilla1101.chatgpt.site/freelance-rate-calculator.html
For a reusable offline workflow after testing the calculator, the Kit Freelance MX bundle includes a quote template, receipt, financial tracker, and guide: https://payhip.com/b/P8zJa?utm_source=dev&utm_medium=article&utm_campaign=freelance-rate-calculator
The important part is the method: make capacity visible, price the work against the revenue requirement, and revisit the assumptions when reality changes.
Disclosure: this article was prepared with AI assistance, and the linked tool and templates are my own project. The article is intended to be useful independently of the link.
Top comments (0)