Sprout

Fund impact projects with milestone escrow and proof-based payouts.

Comment

Inspiration

We built Sprout because a lot of climate and social-impact projects have the same trust problem: people want to help, but they have no real guarantee that funds will be used as promised or released at the right time. Most donation and funding platforms are built around trust first and verification second. We wanted to flip that. The idea behind Sprout was simple: funding should move in stages, and each stage should require proof before money is released. That felt especially relevant for projects focused on sustainability, where outcomes matter just as much as intentions. We were also interested in combining real product usability with stronger accountability. Instead of building a purely theoretical Web3 demo, we wanted something that felt like an actual platform people could use.

What it does

Sprout is a milestone-based funding platform for sustainability and social-good projects. Organizers can create projects, define milestones, and request funding. Funders can browse projects and contribute funds into a project-specific escrow flow. When an organizer completes a milestone, they submit proof of progress. Funders who backed that project can review the proof and approve or reject the release. Once approved, Sprout records the approval flow with cryptographic signing and on-chain auditability, creating a more transparent record of how funds move and why. In short, the platform is designed to answer a basic question clearly: has this project actually earned the next payout?

How we built it

We built Sprout as a full-stack web app with a React frontend and a Go backend. The frontend handles the main user flows: registration, project creation, marketplace browsing, funding, proof submission, milestone review, and audit views. The backend manages authentication, project and milestone data, approval logic, and integrations with external services. For infrastructure and trust layers, we used:

  • Hedera for escrow-related flows and tamper-evident audit history
  • AWS KMS for secure signing of approval payloads
  • PostgreSQL for application data
  • Go and Gin for the API
  • React and Vite for the frontend A big part of the build was connecting product logic to accountability logic. We did not want blockchain or cryptography to feel bolted on. The goal was to make those pieces support the actual user workflow instead of distracting from it.

Challenges we ran into

One of the biggest challenges was designing a release flow that felt trustworthy without feeling heavy or confusing. The whole point of Sprout is that money should only move when progress is actually demonstrated, but if that process takes too many steps, people stop trusting the product experience too. We spent a lot of time tightening that balance so milestone creation, proof submission, and approval all felt clear and connected. Another challenge was making the technical trust layer feel real inside the product instead of just sounding impressive in a project description. It was not enough to say we used secure signing and on-chain logging. We had to wire those pieces into the actual workflow in a way that made sense for users and still held together across the frontend and backend. We also ran into the usual hackathon problem of scope. There were a lot of directions we could have taken the project, but we had to stay disciplined and focus on the core loop: create a project, fund it, submit proof, review it, and release funds. That forced us to cut extra ideas and spend our time making the main experience work end to end. Finally, we had to make the project feel like a real platform rather than just a technical demo. That meant spending time on product decisions, wording, and usability, not just implementation. In the end, that was worth it, because Sprout works better when the accountability model is easy to understand from the first screen.

Accomplishments that we're proud of

We’re proud that Sprout became more than just an idea. We built a working end-to-end prototype where organizers can create projects, funders can contribute, milestones can be reviewed, and payouts are tied to actual proof of progress. We’re also proud that we kept the core concept intact while building under hackathon time pressure. The product is not just about moving money. It creates a clearer accountability flow around funding, which is the part we cared about most from the beginning. Another thing we’re proud of is that the technical pieces support a real user workflow instead of feeling disconnected. The platform combines escrow, milestone approvals, secure signing, and audit history in a way that maps directly to how the product is supposed to be used. Most of all, we’re proud that Sprout feels like a real platform for climate and social-good funding, not just a rough concept. It shows a practical way to make impact funding more transparent and easier to trust.

What we learned

We learned that trust is not just a policy problem or a UI problem. It is a systems problem. If you want people to feel confident funding real-world work, you need more than a clean dashboard. You need a structure that makes progress visible, approvals accountable, and payouts understandable. We also learned how much effort it takes to make a technically layered product feel simple. Good workflow design mattered just as much as the integrations themselves. On the technical side, we got much more hands-on experience connecting secure signing, wallet flows, backend state transitions, and audit trails into one product experience.

What's next for Sprout

The next step for Sprout would be making the platform more production-ready. That would include stronger verification workflows, richer proof submission formats, better funder collaboration, improved admin tooling, and cleaner reporting around project outcomes. We also see room to support more types of impact projects beyond climate, while keeping the same milestone-based accountability model. At its core, Sprout is about making funding more trustworthy. That problem is much bigger than a hackathon, which is exactly why we think it is worth building.

Built With

Share this project:

Updates