I wanted a simple way to compare rent listings that are billed on different schedules (weekly, every 4 weeks, monthly, annual). A lot of tools online convert between these using shortcuts that work “well enough,” but break down when you compare values across multiple periods.
This started as a small personal utility, but it surfaced a few design and math issues that are easy to miss when building micro-calculators.
Choosing a Consistent Conversion Model
The biggest decision was how to handle time periods consistently.
Instead of chaining conversions (for example, weekly → monthly → annual), everything goes through a per-day rate:
- 1 week = 7 days
- Biweekly = 14 days
- Every 4 weeks = 28 days
- 1 year = 365 days
- Average month = 365 ÷ 12
- Hourly values derived from days × 24
This avoids small drift errors and makes conversions reversible. Weekly and 28-day rent can land on the same monthly equivalent if they imply the same daily rate, which is expected behavior when you normalize through a single base unit.
Input Handling and Rounding
Two things that took more time than expected:
Input parsing
People paste values with commas, currency symbols, and decimals. It’s easy to accidentally misread values or silently “fix” them in a way that changes the number. I ended up being strict about what’s accepted and surfacing errors instead of guessing.
Rounding
Rounding happens only at display time. All calculations keep full precision internally. This avoids small compounding errors when converting across multiple periods.
UX Decisions That Mattered
The tool is intentionally simple visually. The important part is that assumptions are visible:
- How long a “month” is in the model
- How 4-week periods differ from monthly billing
- How the daily rate is derived
For anything dealing with money, hiding these details makes the numbers hard to trust.
The Result
The tool is live here:
https://www.rentconverter.com
It converts between daily, weekly, biweekly, every-4-weeks, monthly, hourly, and annual using a consistent day-based model and shows a full breakdown so listings billed on different schedules can be compared directly.
Takeaways for Small Utility Apps
A few things I’d carry into the next build:
- Pick one canonical unit and normalize everything through it
- Make assumptions visible in the UI
- Keep rounding out of the calculation layer
- Treat input parsing as a real feature, not a footnote
- Add reversibility checks to tests (A → B → A should be stable)
Top comments (0)