Overview
HariTools is a Sri Lanka-focused calculator and knowledge platform built to make common decisions easier: estimating an electricity bill, checking APIT deductions, planning a loan, calculating university GPA, comparing EPF and ETF outcomes, or working out a freelance rate.
The repository currently contains 23 available calculators across finance, student, health, business, and everyday utility categories. Seven long-form guides support the tools with explanations, worked examples, tables, and mathematical notation.
The important engineering idea is that HariTools is not implemented as 23 unrelated pages. Definitions, formulas, UI components, metadata, navigation, related content, and sitemap entries are connected through registries. Adding a calculator is therefore a controlled extension of the platform instead of another hand-built route.
Product structure
Each calculator is represented by a typed definition containing its URL slug, category membership, component key, availability, headings, metadata, keywords, introduction, and FAQ content.
Typed calculator definition
|
+-> category directories and discovery cards
+-> static /calculator/[slug] route
+-> canonical and Open Graph metadata
+-> related calculators and articles
+-> FAQ structured data
+-> sitemap entry
+-> dynamically imported calculator component
This registry is the source of truth for both product discovery and SEO. It prevents the common failure mode where a new tool exists but is missing from navigation, related links, metadata, or the sitemap.
Formula-first design
Calculation rules live under utils/formulas instead of being buried inside React event handlers. The repository separates formulas for areas such as:
- loan and lease repayment;
- Sri Lankan income tax;
- CEB electricity tariffs;
- EPF and ETF projections;
- GPA, attendance, and target-grade planning;
- VAT and SSCL invoice calculations;
- retail margin, markup, and discounts;
- fuel, freelancer-rate, fixed-deposit, BMI, age, and date calculations.
That separation keeps domain logic independently understandable and reduces the risk of presentation changes modifying a financial result. The React calculator components concentrate on input state, validation, result presentation, and explanatory context.
For policy-driven calculators, this boundary is especially important. Tax bands and electricity tariffs can change over time, so the formula module becomes the obvious place to review and update the rules without searching through the interface.
Static routes with isolated client bundles
Next.js generates a static parameter for every available calculator. The route resolves the typed definition, builds page metadata, selects the calculator component, and renders it through a shared shell.
The component registry uses next/dynamic for every calculator implementation. A visitor opening the GPA calculator does not need to download the UI code for pregnancy dates, retail margins, electricity tariffs, and every other tool.
/calculator/gpa-calculator-sri-lanka
|
definition lookup + static metadata
|
shared calculator shell
|
dynamically loaded GPA component only
This lets the platform grow its tool count without turning every page into one large client bundle.
Localized discovery and SEO
HariTools targets queries where local context matters. Calculator definitions include specific titles, descriptions, keywords, FAQs, and introductions rather than relying on one generic template. Category pages group related tools, while each calculator page provides breadcrumbs, related calculators, and linked articles.
The platform generates canonical URLs and Open Graph fields per tool. FAQ data is emitted as FAQPage JSON-LD when a calculator has questions, and the sitemap combines static pages, five category routes, all available calculators, and every article.
The result is an SEO pipeline driven by the same records that render the product. A title, slug, category, or availability change propagates through the relevant discovery surfaces.
Markdown knowledge layer
The blog is also content-driven. Markdown files are parsed with Gray Matter and converted into dated article records with category, author, reading time, keywords, cover information, and an optional related-calculator URL.
The custom article renderer supports:
- headings and paragraphs;
- ordered and unordered lists;
- blockquotes;
- tables and fenced code;
- safe internal and external links;
- inline and block LaTeX through KaTeX.
If a post does not provide a usable cover asset, the application can generate a cover through a route handler. Linking an article to a calculator makes it appear in that calculator's related-reading section.
This creates a useful product-content loop: the calculator answers “what is the result?” while the guide explains “why does the formula work, what assumptions does it make, and how should I interpret it?”
Privacy-aware usage telemetry
HariTools records aggregate visits and calculator uses with Upstash Redis. The endpoint validates same-origin requests, accepts only known event types and calculator slugs, and applies an hourly request limit.
Rather than storing a raw IP address, it hashes the IP, user agent, session ID, and event scope. Redis deduplication keys prevent repeated page activity from inflating counters within a defined window.
same-origin event
-> payload and calculator validation
-> hashed request fingerprint
-> hourly rate limit
-> expiring deduplication key
-> aggregate counter increment
When Redis is not configured, public reads fall back to zero and event writes return an unavailable response. The calculators themselves remain usable.
Interface and accessibility
The interface uses reusable shells, cards, category pages, shadcn-style primitives, and responsive layouts. Theme support is handled with next-themes, and calculator results are designed to update without navigating away from the page.
Shared formatting utilities keep currency, percentages, dates, and numeric output consistent. The site also includes privacy, terms, about, and contact pages so the utility experience is supported by the basic information architecture expected of a public product.
Engineering challenges
Keeping formulas and content synchronized
Local financial rules are not timeless. A calculator can be technically correct and still become misleading when a tariff or tax threshold changes. Central formula modules, dated articles, and calculator-specific metadata make those assumptions easier to audit, but they still require an explicit review process.
Scaling without duplicating routes
The platform needed to add tools without repeating metadata generation, navigation, FAQ markup, and related-content logic. The typed registry and shared page renderer solve that by treating calculators as structured product data.
Balancing explanation with speed
A calculator must produce an answer quickly, but finance and education results need enough context to be trustworthy. HariTools pairs compact interactive components with introductions, FAQs, related tools, and deeper Markdown guides rather than forcing every explanation into the calculator card.
Outcome and next steps
HariTools has evolved into a coherent platform with 23 calculators, five discovery categories, a seven-article knowledge layer, generated SEO surfaces, isolated client bundles, and privacy-conscious aggregate counters.
The next engineering priority is not simply adding more calculators. It is strengthening rule provenance and verification: recording the effective date and source for policy-based formulas, adding focused tests around threshold boundaries, and establishing a repeatable review workflow when Sri Lankan tax or utility rules change.
What I learned
This project reinforced that small tools benefit from platform thinking. The difficult work is not rendering an input and a number; it is maintaining consistent formulas, discoverability, metadata, explanations, performance, and update paths as the catalogue grows.
A typed registry, formula-first modules, dynamic component loading, and a connected article pipeline turned a collection of calculators into a maintainable product system.