Every HR or admin person planning a company offsite hits the same wall: nobody can tell them what it actually costs until they've already spent a week collecting quotes. "Somewhere between ₹15,000 and ₹60,000 per person" isn't a budget — it's a shrug. We built a calculator to fix that, and this is what went into it.
The actual problem
Corporate offsite pricing looks simple from the outside — headcount × nights × hotel rate — but the real number depends on tier (near-city vs. domestic vs. international), group size (per-person cost doesn't scale linearly once you're past ~25 people), season, GST, and a handful of line items people forget to budget for until the invoice arrives (airport transfers, conference AV, visa fees on international trips). Getting this right meant building an actual calculation engine, not a static price list.
Stack
Next.js 16 (Turbopack) with the App Router, mixing static prerendering for content pages with dynamic routes for the interactive calculator and vendor dashboard
TypeScript throughout — the budget engine has enough moving parts (tier, destination, group size, add-ons) that untyped math felt like a liability
Tailwind for styling
better-sqlite3 for internal analytics and the vendor/lead marketplace — deliberately not a heavier DB, since the write volume is low and synchronous SQLite calls kept the code simple
Deployed on a VPS behind nginx, systemd-managed, not on a serverless platform — cost and control mattered more than autoscaling for this traffic profile
The calculation engine
The core of the site is a pure function that takes destination, tier, group size, and trip length, and returns a full line-item budget — accommodation, transport, food, activities, GST, and a contingency buffer — instead of one number. Group size scaling was the fiddly part: costs per head flatten out past a certain group size (venue and transport have fixed components), so the engine models a diminishing curve rather than linear multiplication. Every content page on the site — there are dozens covering different destinations and use cases — pulls its numbers from this same engine, so the prose and the tables can never disagree with each other.
Not inventing flight prices
A lot of "budget" content online just makes up round numbers for flights and hotels. We didn't want to do that. Fares in the dataset come from actually checking Google Flights per route, and every entry carries the date it was checked. Visa rules are read directly from official embassy and immigration sites, not aggregator blogs, and re-verified periodically since they change (Thailand's visa-free window, for instance, shortened from 60 to 30 days partway through this year — a stale number like that is exactly the kind of thing that erodes trust in a budgeting tool).
**
The marketplace layer, and a deliberate anti-pattern**
Once someone has a budget, the next step is real quotes. The site routes requests to vetted destination management companies and shows every quote side by side — no ranking by who pays for placement. The one piece of logic worth mentioning: quotes aren't sorted cheapest-first. Any quote that comes in more than ~20% below the computed estimate gets flagged as suspiciouslyLow rather than surfaced as the best deal, because a quote that far under a reasonably-modeled estimate usually means something got left out (transfers, a meal, AV), not that someone found a genuine discount. Cheapest-wins sorting optimizes for the wrong thing in a market where the real risk is an incomplete quote, not an expensive one.
**
SEO as a side effect of correctness, not a separate task**
Because every page's numbers come from the same engine, structured data (FAQ schema, Article schema, dataset exports) could just be generated from the same source of truth instead of hand-maintained separately — which also means there's no way for the schema markup to drift out of sync with what's actually on the page, a common failure mode when SEO metadata is written by hand.
Where this goes next
The calculator is live with — 45 destinations, three tiers, and the full line-item breakdown, free to use. Happy to go deeper on any piece of this (the group-size curve, the quote-flagging heuristic, the live-API plans) in the comments if it's useful.
Top comments (0)