Choosing a Web Hosting Plan for a Non-Profit Website
Non-profit websites carry more weight than their budgets suggest. Donors check them before giving, volunteers look for shift details, and beneficiaries sometimes use them to find help on a bad day. Yet the person choosing the hosting is often a communications officer or a trustee who has never compared a server specification. Sorting plans by what the organisation actually does online makes the decision far easier than starting from a price list.
Start from what the site must do on its worst day
Most non-profit sites fail in the same moments. A fundraising appeal lands in thousands of inboxes at once, or a news story sends strangers to a page built for a few hundred regular readers. Judge hosting plans against that peak instead of an average Tuesday. List the three or four tasks the site must complete under load, such as accepting a donation or showing a helpline number, and treat everything else as optional.
Monthly visit estimates published by a host give a rough guide. Jump.BG lists its affordable web hosting plans by expected monthly visits, from about 15,000 on the entry tier to about 120,000 on the Business plan, and it states that these figures are indicative rather than hard limits. Unlimited traffic and a free SSL certificate come with every tier. Charities with a modest audience can often start on a smaller tier and move up after a successful appeal.
Pricing traps that catch small organisations
Introductory prices cause the most grief. A plan advertised at a low monthly rate for a three-year term often renews at a much higher figure, and the renewal date arrives when the person who signed up has long since left the organisation. Ask for the renewal price in writing and set a calendar reminder for the month before it takes effect.
Add-ons come next. Backups, SSL certificates and malware scanning are sold separately by some hosts, and a plan that looks cheap on the pricing page can double once the essentials are added. A provider that includes daily backups, free certificates, and security tooling in the base price lets a trustee compare offers on a single number.
Billing deserves a look before ordering. Non-profits frequently need receipts in a specific format for auditors, tax treatment that matches their status, and the option to pay by bank transfer instead of card. Jump.BG, for instance, accepts card, PayPal, bank transfer, and Bitcoin. A billing system that cannot issue a proper invoice creates months of awkward correspondence later, so ask for a sample invoice from any provider on the shortlist.
Contract length is worth a paragraph of its own. A three-year prepayment lowers the monthly cost, yet it ties the charity to one provider while its needs may change, and refunds for unused months are rare. Many small organisations do better with an annual plan that renews at a known price and lets the trustees review the choice every year.
Speed is a fundraising issue
Visitors on phones are unforgiving. Google's research on mobile site load times found that 53 percent of mobile visits were abandoned when a page took longer than three seconds to load. A donation page that hesitates for that long loses supporters before they see the form. Page weight is a common culprit, and a donation page that carries a full-screen video from the annual campaign will struggle on a mobile connection, however good the server is.
Server-side caching, current PHP versions, and fast storage all shorten load times without any design work, and they add little to the bill. Ask a provider what technology serves the pages, and be wary of vague answers. LiteSpeed web servers with built-in caching, which Jump.BG runs on every plan, are one common answer, and images compressed before upload account for a good share of what remains. Free speed tests show where the time goes, and running one on the donation page before and after a change turns a vague hope into a measured result.
Support, backups and the volunteer problem
Non-profit sites are often maintained by a single volunteer with a day job. When that person is unavailable, support from the host becomes the organisation's technical department. Check whether help is available around the clock, how it is reached, and whether the staff answer in plain language. A phone number that connects to a person is worth more to a charity than a long feature list.
Backups matter for the same reason. A volunteer updating a plugin late in the evening can break the donation form, and a daily backup with a self-service restore tool turns a crisis into a ten-minute task. Ask where backups are stored, how long they are kept, and whether a single file or database can be restored without rolling back everything.
Mailboxes are a quiet cost. Many charities run their email on the same account as the website, so a plan with unlimited mailboxes covers addresses for every programme and volunteer coordinator without extra fees. Whether that is wise depends on the organisation, since a hosting outage then takes email down along with the site, but it keeps the arrangement simple for teams without an IT adviser.
Moving later without drama
Choose a plan with the exit in mind. Few organisations stay on their first hosting package for a decade, and growth, a rebrand or a change of administrator all prompt a move. Providers that migrate a site and its mailboxes for free make that decision painless, and some also compensate for prepaid time left at the previous host. Compare how each provider treats a request to leave, since a long notice period or a cancellation fee can turn a simple switch into an expensive one.
Keep your own copy of everything. A full backup downloaded every quarter, a note of where the domain is registered and a list of installed plugins let a new volunteer rebuild the site in an afternoon. Store that package in the organisation's shared drive instead of on a personal laptop, and mention its location in the board's handover notes. Ask the old and new providers to coordinate the switch of DNS records during a quiet week, away from campaign deadlines, so that donors never encounter an error page.
