feat: add interactive cost calculator to the hosting costs page

[jkuester]

Description

This is a little present for @mrjones-plip when he returns from the holidays! 🎄

It is a first draft of an interactive Hosting Cost estimation tool (forum thread).

It turns out it is pretty easy to add interactive HTML to your Hugo site via a custom shortcode. And, the modern CSS functionality provide very nice layout and visualization so I did not have to resort to any dependencies.

I am pretty happy with the features/layout/functionality of the whole thing, but the tuning of it could use more eyes.

One simplification that I have started with (but which could be easily refactored) is that I have only factored in the costs of 5 example EC2 instances and I try to pick one of those based on load (users * workflows). This approach has obvious limitations, but it was simple enough to let me get started with real world numbers. Definitely open to suggestions on the best way to improve this.

The other things that need more tuning are the various constant value that are used in down-stream computations:

  DISK_COST_PER_GB: 1,
  CONTACTS_PER_PLACE: 5,
  WORKFLOW_YEARLY_DOCS_PER_CONTACT: 12,
  DOCS_PER_GB: 12000,

DISK_COST_PER_GB is a rounded-up estimate from EBS. CONTACTS_PER_PLACE is roughly the "household size", but it gets used to estimate how many ancestor contacts are in the hierarchy tree (given the user input of the population size). Currently the logic assumes a completely even distribution and density of contacts throughout the tree. WORKFLOW_YEARLY_DOCS_PER_CONTACT is by far the most hand-wavy. Basically I need some way to connect how many workflows are being supported by the instance with an estimate of how many reports will be generated per year. So, in this case 12 means that I think we will have an average of 1 report created per month per workflow per contact. This may be way off. DOCS_PER_GB is a rough estimate that I made based on Watchdog data from a large production instance.

Most of this code was written (or heavily influenced) by Claude, but I have carefully reviewed and edited it for maximum maintainability.

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

[jkuester]

@sugat009 can I get a review of the code implementation? 🙏 This has largely been implemented with Claude, but I have gone through line-by-line to cleanup/review the code and am happy with the quality of the result!

The main focus was to stick to vanilla js/html/css without requiring additional libs.

[jkuester]

@eljhkrr, when you get the chance, can you help me with two things?

1. The calculator is currently based on values which I calculated from an uninformed sampling of instance data from https://watchdog.app.medicmobile.org (specifically from instances where we had Node Exporter data). Could you recommend to me (maybe in Slack) a more informed list of production instances (~10) that I could use to base the averages off of? A range of big and small instances would be great, but I think the most important thing would be that they are on 5.x and that we have access to Node Exporter data. (Also, I think a number of MOH instances might be located on the same host. It is okay to include those as long as you can tell me which ones map to which host (so I can properly account for it when mapping to the Node Exporter data for the host...)
2. Can you spin up the calculator and just give it a sanity check. Is the provided data useful? Are there any missing parameters that are essential to include? Does the reported estimates pass the "smell test"? (Because of the variability between CHT instances it is going to be hard to exactly match what we see for a particular production instance, but I am trying to get as close as reasonably possible...)

[sugat009]

A few nits! Nothing major.

[sugat009]

LGTM! All previously flagged issues have been addressed. Just a couple of minor suggestions for quality of life improvements.

[eljhkrr]

Thanks for the great work!

1. For sampling instances, I'd recommend:

   • Small - Elgeyo Marakwet, Mandera (cluster 1 - shared hosting on echistanariver node), Kitui, Kirinyaga (cluster 1 - shared hosting on echistharakanithi node) & Mombasa (cluster 1 - shared hosting on echistanariver node)
   • Large - Homa Bay, Bungoma, Trans Nzoia, Makueni & Meru

   Most of the instances are sitting on individual VMs apart from the ones on shared hosting

2. The calculator looks good and I have opinions on possible useful additions:

   • Use more direct language by switching 'users' for 'health workers' or CHWs
   • A time series of cost vs deployment age would be useful for visualizing expected cost changes over time

[mrjones-plip]

switching 'users' for 'health workers' or CHWs

really like this input!

[jkuester]

Okay, thank you everyone again for your helpful input! I have updated things based on Elijah's comments (and with new data from the recommended instances):

• MEDIC_DOCS_PER_GB: 76111 > 186089
• USERS_PER_CPU: 211 > 288

The improvement here was largely expected because my previous numbers were assuming the tharakanithi and tanariver nodes were only serving a single CHT instance each. I balanced out these gains by increasing the default DB over-provision factor from 3 > 5 (based on the latest 5.x upgrade numbers we have seen). So in the end for our default specs, the price-per-user-per-month went from $0.11 > $0.09 (which is better than our current "estimated cost" of $0.10). 👍

@mrjones-plip could you give this one final smoke test early next week just to be sure (got me all cautious here after the discussion in the TCO squad). Otherwise, I think this is ready to rock and roll! 🕺 '

[mrjones-plip]

The updates are looking visually really good! The applicability and warm fuzzies in seeing "Health Workers" vs "Users" is pretty amazing - I literally feel better about the numbers! I'm not just supporting rando users, I'm supporting super important health workers!

I should be able to do a smoke test (if not a semi-deep dive) this afternoon. Stay tuned!

[mrjones-plip]

Yeeeessss. Feels so good to see this all come together - excellent work! Approving with one optional change and one easy CSS tweak.

Congrats @jkuester - this is HUGE

1. Maybe do a People -> Patients change? This sounds better to me - this is entirely optional! And likely if Elijah et al. didn't flag it it's not an issue:

   People per Health Worker -> Patients per Health Worker

2. there's line break that happens in FF when docs responsive design is widest so left nav, center content and right nav are all showing. I believe a lil' CSS white-space: pre; added to .inline-cost-yearly class fixes it but only tested on FF in all the responsive modes:

    .cht-cost-calculator {
      & .inline-cost-yearly {
    	font-size: 1.5rem;
    	font-weight: bold;
    	color: var(--calc-link);
    	white-space: pre;
      }
    }

   
   Screencast.From.2026-03-27.17-32-04.mp4

[jkuester]

Thank you @mrjones-plip for the final review! 🎉

Maybe do a People -> Patients change? This sounds better to me - this is entirely optional! And likely if Elijah et al. didn't flag it it's not an issue:

So, I do agree that the "people" wording feels a bit awkward. However, maybe I am just mis-remembering things, but I thought we tended to avoid the word "patient" when referring to the population served by CHWs (the idea being that the CHWs (and by extension the CHT) serve "the community" in a holistic sense and are not just "treating patients" (not in the way that you might think of health workers in a clinic/hospital that just treat patients who are presenting with ailments).

So, happy to go with different wording here, but not sure we would really consider the all population served by CHWs as their "patients". I will leave this as "People" for now and we can update in a future iteration. 👍

there's line break that happens in FF when docs responsive design is widest so left nav, center content and right nav are all showing.

Woah, good catch! This def is a FF vs Chrome thing (as I could not repo this in Chrome, but was easily about to see it in FF). 100% agree that a bit of white-space css is all we need here. Done!

[mrjones-plip]

excellent work here! Agree with patient vs people take - thanks for the thoughtful response.