The making of Impact Connect

One person. One question: could this be easier?

A useful opportunity is easy to miss when it is buried in a notice, a link or a conversation. Santosh Kumar started Impact Connect to help India's social sector find the right information, people and ways to act. The web app is the next chapter of that work.

An honest look at a build still in progress

Chapter 01 / The reason

It began outside the code.

Santosh has run Impact Connect as a one-person initiative. His work with nonprofits kept returning to the same practical problem: people needed to find grants, partners, services and help, but useful information was scattered across many places.

So the question became: what if those tasks could meet in one place, without asking a nonprofit to pay just to get started?

The app is not the mission. It is a way to make the mission easier to act on.

That idea grew into a web app for opportunities, organisations, shared needs and learning. AI has helped with research, writing and testing, while Santosh has set the direction and made the decisions. The work still needs human review, good sources and real tests.

Chapter 02 / The messy middle

A working page is not a working path.

Building quickly surfaced the unglamorous questions: What happens on a small phone? On a weak connection? When a source is missing, a form fails, or an update has not reached the server?

Santosh kept checking the app on his phone and sending back the things that did not work. The original register reached 114 issue entries. They are a record of what needs attention, not 114 fixes claimed complete.

114

Original issue entries

A fixed reference list, with newly discovered requirements tracked separately. An item closes only after the person-facing path is proved.

Reusable block families planned

Design foundations, feedback states, data adapters, forms, actions and more are being rebuilt as shared pieces. The Nonprofits area is the first pilot. Old active code retires only after its replacement is checked.

The aim is a cleaner app, not a bigger pile of scripts. At this stage the block work is in an isolated test tree; it is not a claim that the whole rebuild is live.

Chapter 03 / Under the surface

The technology has a job to do.

The app uses a simple static frontend for what people see, with Cloudflare Pages serving the site, Workers handling API requests, and D1 storing application data. These choices are practical, not magic: every free tier has limits, and each data-backed path still needs proof.

THE FRONT

Static pages, built for phones

HTML, CSS and JavaScript keep the public interface direct. The design starts at phone width; the 390px view is checked before a change is called ready.

THE BACK

Pages + Workers + D1

Pages delivers the site, Workers serve app requests, and D1 holds data. A healthy status page alone does not prove a database-backed journey works.

THE TOOLBOX

Open source, chosen with care

Libraries are considered only when they solve a real problem. License terms, bundle size, speed, privacy and failure cases are checked before one joins the app.

Less friction does not mean fewer safeguards.

The design avoids a conventional password login. Private actions, identity and contact sharing still need clear permission and server-side checks. Offline work needs real receipts before anyone is told that it has synced.

These are design rules and work in progress, not a claim that every planned flow has launched.

Chapter 04 / The next page

Launch is a checkpoint, not the end of the story.

As October 2 approaches, the test is simple to state and harder to pass: show real information, make actions work on a phone, handle failures honestly, and keep private details private. Features that have not passed those checks stay in progress.

Impact Connect is being built for the people who need the work done. The story is worth telling because the work is still being tested and improved.

Explore Impact Connect