Building nonprofit websites that last
In recent years, the distance between ‘we should have a website’ and ‘here is a website’ has become remarkably small. Templates and drag-and-drop builders can produce something polished in a few hours. Open-source platforms have made sophisticated publishing systems accessible to organisations that might never have justified building one from scratch. AI has pushed this even further, moving from helping with individual pieces of code to generating layouts, connecting tools, and increasingly producing entire websites from mere prompts. All of this has radically changed the economics of getting a website built.
However, the distance between ‘here is a website’ and ‘here is technology this organisation can function with for the next five years’ often still feels insurmountable.
These gaps are particularly evident for us at Tech4Good Community, where we work with nonprofits on a range of technology needs. Websites are one part of that work, and it is often where larger questions around using, managing, and making decisions around technology first become visible. By the time organisations come to us, they have often already decided that their websites need attention. But the purpose of the website, and the decisions around it, vary enormously. This gives us a different place to begin each time, and it also changes the conversation about what happens after a website goes live.
Does the website reflect the organisation in its current form?
While working with nonprofits over the last five years, we have found that a website rebuild has an intriguing way of showing an organisation back to itself. When the time comes to decide what belongs on the updated version, organisations find that they have changed considerably from when they first set up their website. For instance, new programmes have appeared, old ones have evolved, the language around the work has shifted, teams have grown, geographies have expanded, and a few elements that once felt central have moved to the edges. The website brings all these versions into the same room, which makes the build as much an exercise in organisational clarity as it is a technical one.
At the same time, a website can feel like the least technical piece of technology an organisation has to deal with, which is precisely what makes it such an interesting place to begin. Behind the homepage lie the domain, hosting, content management system, analytics, forms, integrations, and the accounts that piece them together. Website builds therefore open up much bigger questions about who controls each layer, who can access what, and what happens when the people or vendors managing these elements change.
It can also reveal how an organisation’s work reaches people. This is the territory of search engine optimisation (SEO), or paying attention to your footprint in search results. Some platforms have this as a built-in functionality without additional cost, whereas others require you to upgrade to a premium tier to claim SEO benefits.
Locked in, locked out
Website management is often fragmented. A developer builds the website. A vendor hosts it and registers the domain through their own account. The theme is customised, a few integrations are added, the organisation gets administrator access, and everyone is happy. But admin access usually covers only what happens inside the website itself; it does not necessarily extend to the domain, hosting, third-party services, or the accounts connected to it.
Then, a few years pass. The developer moves on. The vendor changes their business model. The person who knew how a particular integration worked transitions out of the organisation. The website still works, so nobody thinks about it very much. Until something breaks. This is where lock-in becomes visible.
There should be a record of how payments, newsletters, and campaigning services are connected to the main site.
Vendor lock-in is usually understood as a situation where once an organisation is inside a particular ecosystem, moving elsewhere can become inconvenient or expensive. For nonprofits, knowledge can get locked in too. If the original builder is the only one who knows how the system works, that knowledge effectively leaves the organisation with the builder. If the technology cannot easily be moved, documented, or handed over, a decision made for convenience at the beginning can become a dependency several years later.
More than one person should know where the important pieces are located, and a trusted developer should be able to work with the organisation without becoming the only person capable of making changes.
This is why we focus on things that do not always feature in an initial website brief: documentation, access, backups, and a clear record of how the entire puzzle fits together. The domain should be in an account owned by the nonprofit, hosting should be accessible and transferable, and credentials should be stored in a shared password manager, rather than with one staff member. There should also be a record of how payments, newsletters, and campaigning services are connected to the main site—where content is stored—and how routine changes are made. These arrangements matter when a developer leaves, a vendor changes, or the team decides to take its technology to someone new.
This way the nonprofit does not have to become its own IT department. It makes sure the team can see, access, and move the dependencies seamlessly.
Managing costs while building internal capacity
Keeping a website going over several years comes down to a combination of cost and capacity. While technology budgets vary across the nonprofits we work with, the pattern is familiar. The website often gets treated as a project with a fixed cost rather than a piece of infrastructure that will require ongoing investment. A team may also secure funding for the initial upfront cost of design and development. However, hosting, domains, subscriptions, content updates, maintenance, and technical support are additional costs that emerge once the site is actually in use.
For organisations working with tight budgets, factoring in these recurring costs can matter just as much as the original build. However, these stay outside the budget or get absorbed into someone’s workload.
A cheaper initial build can become an expensive choice if every subsequent change needs a vendor.
We now encourage teams to budget for the full life of the site and not just its launch. That means looking at the upfront cost alongside three or five years of hosting, maintenance, subscriptions and support, and choosing the technology with that total in mind. A cheaper initial build can become an expensive choice if, for instance, every subsequent change needs a vendor.
This matters particularly for smaller and grassroots organisations, where technology budgets and staff bandwidth can be stretched across many competing priorities. Moreover, cost is also closely connected to capacity. An organisation with the ability to make routine changes has less recurring dependency on external support, which means additional expenditure. This does not mean every nonprofit needs a developer on staff.
Instead, this is where ownership and agency become important. Ownership might mean owning the domain, having administrator access, and being able to point to the account where everything lives. Agency means being able to add a page, update a programme, change a workflow, and having the ability to decide what can be managed internally as opposed to when it is time to bring in an expert. The technology should leave enough room for the team to manage day-to-day functions and bring in technical expertise when the work genuinely calls for it. The more ordinary work the team can manage itself, the more effectively it can use its limited technical budget for more complex needs.
Don’t build yourself into a corner
Our experience of working with nonprofits shows that deciding how to build and maintain a website requires both foresight and a level of flexibility. The organisation may want the freedom to move hosting providers if a better, more affordable or more secure option comes along. It may build enough technical capacity to bring more of its technology under one roof. A programme may need an interactive experience, a geographical overlay, or a dynamic calendar. A campaign may need something considerably more sophisticated than swapping out text and images.
AI has made some of this work much easier, moving from helping with individual chunks of code to generating layouts, connecting tools, and increasingly producing entire websites from mere prompts. This makes it easier to get something built, but it does not make the decisions around what to build any easier. If anything, it makes the work of choosing the right tools, documenting how they fit together, and making sure someone can maintain them more important.
These are the kinds of things that are hard to predict when the first website is being built. What matters is leaving enough room for the organisation to respond when these requirements show up.
—
Know more
This content is published by India Development Review and has not been created or edited by Hello Headlines. View original
