How we didn’t get Ghosted: The surprisingly complicated story of our “simple” website build programme

“Can you help us build a website?” is a question we hear often enough that it feels like a recurring calendar invite. It comes from founders who have built an entire organisation: programmes, partnerships, fundraising, operations, and realise that the website became that one unfinished room. It comes from the comms manager who has inherited the website along with a zillion other things and is expected to keep the flame alive, who is thinking: surely this can be less painful.

Of course, there are already several agencies, initiatives and tools helping organisations build websites. This is not a story about discovering that nonprofits need a stronger digital presence.

Our autopsy is about why websites take work, despite appearing deceptively simple, somehow have a strange ability to expand, stretch and occupy much more brain space than anyone originally planned.

We know this because we are also that team.

We are also the people who think about website updates, broken links, content changes, hosting doubts and the dangerous phrase “can we just add one small thing?” on a fairly regular basis. (A phrase which, in website language, is rarely followed by something small.) Even having a two-member website team at T4GC feels like a luxury.

Many organisations are trying to maintain their digital homes with far fewer hands. And sometimes, despite everyone’s best intentions, website work takes the backseat.

There are certain ideas that are so logical when you first encounter them that the possibility of them becoming complicated does not register. Building websites for nonprofits was one such idea for us.

The problem appeared mathematical: social impact organisations were looking to re/build their virtual footprint, tools existed that had made website building significantly easier than it once was, and there was a growing pool of students who were eager to use their skills for something beyond classroom assignments. The missing piece seemed obvious: bring these groups together and let the work happen.

How hard could it be?

As we discovered over three cohorts of Ghosted (a program name dedicated to the open source website tool we chose to use - Ghost), this was the kind of feeling that should make you suspicious. Because, between the first conversation and the final handover, the website stopped being the central character. The pages were only the output.

The actual work was everything that happened before anyone opened the website editor: conversations about what an organisation wanted to say, debates about what represented them best, decisions about which stories mattered, attempts to locate old photographs and fading documents, and the difficult exercise of getting people to agree on what exactly they wanted someone new to understand about their work.

The technology was only one part of the puzzle.

The bigger headache was always: how do you take years of work that has grown organically in the real world and help it find a shape online without losing everything that made it meaningful in the first place? That is the hurdle Ghosted kept returning to.

And perhaps that is why, despite the name, we did not actually get ghosted.

We just discovered that building a “simple” website required a lot more people, chats, decisions, and occasionally existential discussions about homepage banners, more than anyone had originally planned. 

The website was never the website

The first thing that becomes clear when working with nonprofit websites is that they are rarely just websites. They are asked to carry an unreasonable amount of weight. It is expected to introduce an organisation, explain its work, build credibility, communicate impact, attract partnerships, support fundraising, recruit staff, and provide a reliable place where someone can understand what the organisation actually does.

It is expected to be the organisation’s first impression, memory bank, pitch deck, archive and visiting card, and all of this while loading quickly and being simple enough for someone internally to update, long after the builders have left.

Commercial websites often have the luxury of being clear about their purpose. You buy something; Book something; Subscribe. The series of actions are obvious. 

A nonprofit website has to hold complexity because the work itself is complex. For example, a community programme may have evolved over several years. An organisation may have started with one idea and grown into something larger. A grassroots effort may have decades of relationships behind it that cannot be reduced into a neat paragraph titled “Our Story.” The website has to make all of this understandable to someone encountering the organisation for the first time, while still feeling true and representative to the people who have built the work from the inside.

That translation is where things become interesting. Because doing meaningful work and explaining meaningful work are two very different skills. Most organisations know exactly what they do. The bigger barrier is: How do you help someone else understand it?

The folder called “content”

The first indication that a website project is not going to be as simple as everyone imagined usually arrives in the form of a folder. The dreaded content folder.

Inside, there might be an old brochure PDF from five years ago, a presentation made for a funder meeting, a report written for an annual review, photographs from a field visit, a document someone started but never finished, a collection of stories everyone knows are important but nobody has had the time to write down properly, and hidden between all of this, the actual story of the organisation.

The challenge is not that nonprofits do not have enough content. Usually, they have too much. The task is then figuring out which pieces belong together and arrange it into a structure where someone can understand it while scrolling between meetings.

When one reaches this stage, a website now asks an organisation: What should someone know first? What should they remember? Which programme represents the organisation today? Which story explains why this work exists? Which photograph captures something that words cannot? These are website questions on paper. But they are also really questions about identity. And identity is rarely something that fits into a hamburger menu. A statistic has to carry credibility. An insight has to have metrics and therefore an impact. So the process of building a nonprofit website becomes less like filling in a template and more like trying to fit an entire organisation into a suitcase, while also accepting that everyone has a different opinion on what cannot be left behind.

Choosing the kind of chaos we wanted

Before any student wrote code, before any design discussion began, before anyone opened Ghost, there was another piece we had to answer: Which organisations become part of this experiment?

Find nonprofits that need websites. Match them with students. Build.

But like most simple answers, this one became complicated almost immediately.

Some organisations came without websites altogether. That initially seemed like the clearest case. If the problem is “no website,” the solution appears obvious: build one. Except a missing website is not only a technical gap. It means the organisation has no digital introduction. There is no easy place for someone unfamiliar to understand their work, who they are, what they do, or why they exist. Creating the first website is never just about adding pages. This is the point where one gets to decide how their organisation enters the digital world.

Other candidates came with existing websites that needed a refresh. This sounded easier until we realised that existing websites come with history. There are pages people are attached to. There are stories that no longer fully represent the organisation but still capture an important moment in its journey. There are sections that nobody visits but nobody wants removed because someone, somewhere, remembers why it mattered.

And then comes the sentence that has probably expanded the complexity of website projects more than any other sentence in existence: “While we are at it, can we also add….”. It’s a harmless sentence. A sentence that begins with one small addition and somehow opens the door to nine new threads.

"Could we add a volunteer section? Could we add our research work? Could we add all our programmes separately? Could we make it an interactive experience? Could we add this one feature that would completely change how the website is structured? "

Suddenly, the simple website has opinions, ambitions and a growing backlog.

So the selection process became less about finding “ideal” organisations and more about finding a mix of contexts, challenges and stories that could teach everyone involved something. Which was probably the closest thing to strategy we had. Because there is no such thing as a perfect cohort. Every organisation arrives with its own history. And every history brings its own dilemma.

Why Ghost, and where Ghost pushed back

When we first started exploring tools that could be useful for nonprofits, Ghost stood out for a fairly nonchalant reason: it did not try to do everything. And that was actually the point. A lot of technology products arrive promising to solve several possible problems in one shot. They come with dashboards, integrations, automation, analytics, workflows and approximately seventeen different things that someone somewhere believes are essential. Which is great, until the person actually using the tool is a nonprofit team member who simply wants to update a story, add a programme update, or change an image without wondering whether they have to raise a support ticket first.

Ghost felt different. It was clean. It was open-source. It allowed organisations to own their content and build a digital presence without needing a developer hovering nearby every time a sentence needed changing.

For nonprofits, that ownership matters. A website that cannot be maintained after the original builders leave is not really a website. It is a happily designed moment frozen in time.

And the internet already has enough forgotten websites sitting in muted corners, displaying outdated team pages and event announcements from three years ago.

The promise of Ghost was: give organisations a tool they could actually continue using. But, as we discovered, every tool comes with its own personality. Ghost’s personality is very much: “I will give you a structured, clean publishing platform. I will not pretend to be a completely custom website development agency hiding inside a template.” Which is fair. Even websites are allowed to know their boundaries.

The things that make Ghost elegant are also the things that create boundaries. At the beginning, Ghost appeared straightforward. Choose a theme. Customise it. Add content. Publish. The kind of process that makes you believe the website will be ready somewhere between a productive afternoon and a few cups of coffee. Then you actually start building. And, the battles arrive.

What happens when the organisation’s story does not fit into the available layouts? What happens when a programme needs a slightly different structure? What happens when a nonprofit wants to highlight something that the template didn’t imagine? The answer we came up with is: you start negotiating.

Some of the free templates worked well for organisations looking for a direct publishing experience. But nonprofits often needed their websites not just as blogs or newsletters. They wanted richer vision flows, programme pages, monitoring and evaluation sections, team information, ways to showcase communities they work with, and enough flexibility to explain work that hardly fits into any standard format. This meant that what looked like a simple customisation exercise often became an exchange about code, custom templates, configurations and trade-offs.

The other surprise was around maintenance and future. The students were not simply creating websites and handing over files. It was a point in the programme where they were creating systems that someone else had to inherit.

That meant thinking about documentation, configurable elements, integrations, hosting (this word meanwhile, opened up an entirely different rabbit hole. Because before a website can exist, there are several non-glamorous questions waiting in line: Where does it live? How does one buy a domain? What does hosting actually cost? Who gets the login details? And most importantly, who remembers where those login details are six months later?), training and all the small invisible details that nobody notices when everything works but become glaringly obvious when something breaks. 

The final website was only one part of the handover. The bigger handover was confidence.

Could the organisation actually take ownership of this thing? 

The part where students stopped being builders and became translators 

One of the biggest surprises of Ghosted was watching what students actually ended up doing without us being involved. They originally joined expecting to build websites. Which they did. Building for nonprofits is not the same as building a website from a technical brief because there usually is no technical brief. There is some orientation. Then there are dreams. The students had to move between different worlds. They had to understand what the organisation was trying to communicate. They had to absorb what it meant to do social sector work. They had to imagine what was technically possible. They had to negotiate with the nonprofit what could realistically be built within the timeline. And then they had to bring all of these things together without making anyone feel like their idea had disappeared in the process. This is a most difficult skill. Because the gap between “what someone wants” and “what can be built” is where most technology projects spend their full lives. A person could probably put it all into one very tight slide. And everyone would nod. The slide would suggest a nice linear journey. 

Step one. Step two. Step three. Website. Boom. 

Except real life does not respect slides. The onboarding session often became a storytelling workshop because organisations realised they needed to rethink how they described their work. The website was becoming a mirror. And mirrors are useful. But they are also slightly uncomfortable. Because they show you what is there.

For students, this meant the learning went far beyond writing code. They learnt that technology rarely exists separately from people. A technically perfect solution can still fail if it does not match how someone actually works. A nice looking design can still fail if nobody knows how to update it. A fast build can still fail if the organisation does not feel represented by what was created. The students were learning  how to ask better questions. How to explain limitations without shutting down possibilities. How to build something with someone rather than simply for someone.

Essentially, the students had a peek into getting a crash course in the world of social entrepreneurs, where every problem has context, every decision has consequences, and nobody has a perfectly updated spreadsheet. 

Across three cohorts in February, April and May, Ghosted brought together twelve nonprofits and twelve student teams who came into the programme carrying very different things. The nonprofits brought years of work and occasionally a folder with a name like “final_final_latest_content_v2” that suggested the content journey had already lived several lives. The students brought curiosity, technical skills, patience, toggling coursework, examinations, and the willingness to discover that building for the social sector comes with a slightly different instruction manual.

The humans who refused to ghost

The organisations that became part of this journey were: Nature Classrooms, Trustin, Sankalp Learning Solutions, Canopy Commons, Voice Of Needy, Dalai Lama Foundation, Khojbeen Mandali, Umang Welfare, Seva Bharathi, Sarvoprayas Sansthaan, Moregaon Mahila Mehfil and READ. The student teams joined from institutions including Dayanand Sagar, Tatyasaheb Kore Institute of Engineering and Technology, Warananagar, College of Engineering Attingal, College of Engineering Kallooppara, Rajiv Gandhi Institute of Technology, Kottayam, Sacred Heart College, Tirupattur and others.

This is also where IdliStack entered the picture. A website is not "done" because someone clicked “Publish”. It still needs a space to live, someone to maintain it, someone to renew the domain before it expires on a random Tuesday 10 months later.

Hosting sounds wonderfully boring until you don't have it. Then it becomes the entire energy. 

Between the first conversation and the final website, students stopped being “the technical team” and nonprofits stopped being “the clients”. They became “collaborators” trying to figure out one shared goal. The collabs even got some founders to feature the kids who built the sites as a form of a heartfelt shoutout, that too under the”team” section: https://canopy-commons.org/team/

And every good collaboration needs someone who can step in when things get stuck. For Ghosted, that person is Sakthi, our resident Tech4Good Fellow, or, as the student community knows him, the Shifu of the fellowship. Sakthi is usually nearby when these build days refuse to behave, a layout decides to develop its own character arc, or someone has reached the stage of saying, “I have tried everything.” The thing about Sakthi is that he helps people find their own magic in their wands. His spells are unique. You can see this spirit in builds like: https://khojbeenmandali.in/. That is probably the most open-source thing about him. His goal  is to help someone become the kind of builder who can solve the next one too.

Of course, Ghosted also leaned on people who kept the programme from becoming one giant spreadsheet of good intentions. Vishal from FOSS United was one of those people who seemed to keep growing extra limbs for student selection, review rubrics, process checks, figuring out how to make the programme slightly more watertight.

And then there was the Samagata Foundation, who did something that often gets forgotten whenever people describe student programmes as "volunteer-driven." Young people are contributing real skill, real time and real effort. That work deserves to be valued as work. Ghosted only became possible because Samagata backed the programme with resources, making sure the labour, care and thinking that students poured into every website was recognised instead of the usually expected for free format. That mattered to us. It still does. And always will.

Ghosted has osmosis-ed into a people programme. We were slowly finding people who wanted to build for the people already busy building communities. And that, perhaps, is the thrill of what we keep testing through Ghosted. The websites are what eventually makes it to the internet, like: https://www.natureclassrooms.org

The process we decided to put ourselves through is the story. And knowing us, there will be plenty more chapters. Every website in this cohort will eventually be redesigned. Colours will change. Teams will grow. Programmes will evolve. Someone will inevitably decide that the homepage needs "just one small tweak." That is the nature of the internet. But if Ghosted leaves behind a community of builders who now understand what it means to build for good, with patience, context and care, that infrastructure lasts much longer than any website ever will.