Ripple

Inspiration

In 2024, 4.5 million American households reported having no computer. Another 13.2 million relied on a smartphone without any other type of computer. At the same time, the world generated 62 million metric tons of electronic waste in 2022, and only 22.3 percent was formally collected and recycled. The equipment exists. The need exists. The process connecting them is incomplete. A company cannot simply hand used laptops to a school. It must confirm that it owns the equipment and has permission to release it. Company data must be erased. Every device needs inspection. Broken parts require money. Repair work requires skilled people who deserve to be paid. The devices then need quality testing, transportation, and recipient acceptance. Most donation platforms show the beginning of this process. They record that someone offered an item or gave money. They rarely show whether the equipment worked, who repaired it, what the work cost, or whether the intended recipient accepted it. We built Ripple around one strict rule: a device does not count because it was promised. It counts when the recipient accepts it.

What it does

Ripple coordinates the four participants required to complete a technology access mission. A company declares equipment it may be able to release. It provides the device type, quantity, condition, location, and availability window without exposing private serial numbers. A public school or charity records a specific need. It explains how many devices are required, who will use them, and when they are needed. A repair business publishes its capabilities. It identifies supported device types, available services, monthly capacity, and expected turnaround time. Supporters fund the activation work. Their contributions cover defined costs such as secure data erasure, diagnosis, repair labor, parts, chargers, delivery, and quality evidence. Ripple gives each participant a dedicated intake experience. An administrator receives every inquiry in one dashboard, reviews the organization, updates its status, and records what must happen next. Smart Cart helps friends fund a complete outcome together. An organizer enters the group budget, number of participants, and main priority. Ripple calculates three packages using the visible costs of a selected mission. Every option remains within the stated budget. After selecting a package, the organizer creates a public Ripple Circle. Friends receive one link, choose their own contribution, add an optional message, and see the total update. The link can be shared through WhatsApp, Facebook, or any other social platform. The Circle does not hide where the money is expected to go. It displays the repair allocation, parts cost, delivery cost, quality evidence cost, device target, remaining amount, and contribution history. Ripple also separates every claim by status. Declared equipment is not presented as verified inventory. A sandbox contribution is not presented as transferred money. A repaired device is not presented as delivered impact. The final record requires recipient acceptance. The current payment experience is a Visa style sandbox. No card is charged. No money is transferred. Card details are never stored.

How we built it

Ripple uses HTML, CSS, and vanilla JavaScript for the frontend. We designed separate experiences for companies, schools, charities, repair teams, supporters, administrators, and Circle participants while keeping the navigation and visual language consistent. The backend is a Python HTTP service with a JSON API. It handles registration, login, secure sessions, participant inquiries, administrator reviews, mission data, Smart Cart recommendations, Circle creation, contribution records, and event history. Local development uses SQLite. Production uses PostgreSQL through Neon. We wrote a database compatibility layer so the same application logic can operate against either database without maintaining two separate backends. The hosted application runs through a Python function on Vercel. GitHub is connected to the production branch, so each tested commit creates a new deployment. Authentication uses PBKDF2 password hashing with individual salts. Hosted sessions use secure cookies with HttpOnly, SameSite, and Secure protections. Write requests require CSRF tokens. The API also enforces origin checks, strict JSON schemas, request size limits, role permissions, and database backed rate limits. Mission, inquiry, Circle, and contribution activity is stored persistently. Important actions create append only event records so the system preserves what happened instead of silently replacing history. Circle contributions use transactions and remaining balance checks. If a contribution would exceed the Circle target, the server rejects it. The database stores only the fictional sandbox authorization reference. It never stores the demonstration card number. Smart Cart currently uses a transparent rules engine. It reads a mission’s visible budget, calculates possible device outcomes, and produces three packages that remain within the group limit. It does not invent a recipient, partner, price, or device supply. We created 21 integration tests covering authentication, CSRF enforcement, administrator permissions, inquiry ownership, database migration, matching, event history, Smart Cart recommendations, public Circle access, sandbox checkout, contribution limits, and session invalidation.

Challenges we ran into

The first challenge was preventing the interface from overstating impact. A large number on a dashboard can look convincing even when it represents nothing more than a form submission. We had to define separate states for declared equipment, reviewed inquiries, approved missions, simulated funding, completed repair work, delivered devices, and recipient acceptance. The second challenge was protecting a public contribution flow without making it unusable. Circle pages need to open without an account, but contribution requests still need validation, rate limits, transaction safety, and strict payment boundaries. Preventing overfunding required more than a frontend limit. Two people could attempt to contribute at nearly the same moment. We added a transactional balance check on the server so the accepted total cannot exceed the Circle goal. The third challenge was supporting SQLite locally and PostgreSQL in production. The databases differ in placeholder syntax, transaction behavior, locking, and schema features. Our compatibility layer had to preserve the same application behavior in both environments. Vercel deployment exposed another set of problems. Nested API requests were rewritten differently from our local routes. The first production build served page content without CSS or JavaScript because those assets were excluded from the Python function bundle. We corrected the routing, included the required public assets, and added tests for the exact production paths. Public sharing also failed at first because Circle links copied the temporary Vercel preview address. Those preview pages required a Vercel account. Ripple now generates every Circle link from its public production address.

Accomplishments that we're proud of

Ripple works from the first inquiry through the final demonstration record. A participant can create an account and submit a company, recipient, or repair inquiry. The inquiry persists in PostgreSQL. An administrator can review it, change its status, add notes, and inspect its event history. A group organizer can enter a budget, compare calculated packages, create a Circle, and receive a public link. A friend can open that link without signing in, choose an amount, complete the sandbox checkout, and immediately see the group total change. Every amount shown in Smart Cart comes from a visible cost category. Every package stays inside the organizer’s budget. Every contribution is checked against the amount remaining. The interface does not present sample data as a real partnership. It does not call a sandbox payment a donation. It does not call planned devices delivered impact. We are also proud of the product experience. Each participant sees the information relevant to their role. The public Circle communicates the goal without exposing private inquiries. The administrator receives operational detail without forcing every user into the same dashboard. All 21 integration tests pass against the complete backend workflow.

What we learned

Technology donation fails when the system records intent but ignores execution. The company needs a controlled release process. The repair team needs a defined scope and payment. The recipient needs equipment that meets an actual requirement. The supporter needs proof that a contribution funded the stated work. If any one of those responsibilities is missing, the mission is incomplete. We also learned that trust must exist in the system design. Labels alone are not enough. The database must preserve status changes. The API must enforce ownership. The interface must distinguish estimates from verified records. Payment fields must remain outside stored contribution data. Social participation also depends on reducing friction. People are more likely to help when they receive one public link, understand the exact target, and can contribute their own amount without creating an account. Finally, deployment details can change the product itself. A protected preview link breaks the social experience. A missing stylesheet breaks confidence. A failed route prevents authentication. Production behavior must be tested directly.

What's next for Ripple

The next milestone is a controlled pilot with one company, one repair partner, and one school or charity. The company would submit a real equipment batch with private ownership documentation. The repair partner would inspect a sample and provide an actual work estimate. The recipient would confirm its device requirements and acceptance criteria. Ripple would then replace sample mission data with the approved scope. Each custody transfer would create a timestamped event. Repair results would record passed devices, rejected devices, parts used, and final quality checks. Rejected units would receive a documented recycling route. Real contributions would require a compliant charitable payment partner. Before enabling them, Ripple would need verified recipient organizations, restricted fund accounting, refund rules, payment dispute handling, privacy review, and accurate receipts. Future versions could integrate inventory systems used by companies and repair shops. This would allow approved batches and repair capacity to enter Ripple without repeated manual forms. After collecting real repair outcomes, Ripple could improve its recommendations using observed failure rates, repair time, parts costs, device age, and recipient acceptance. Any future model would need to show the facts behind its recommendation. The goal is not to count how many devices entered the platform. The goal is to prove how many usable devices reached the people who requested them.

Built With

• api
• css3
• git
• github
• html5
• javascript
• json
• neon
• postgresql
• python
• rest
• sql
• sqlite
• vercel