DEV Community: Edward Odero

Building DumpTrade a peer-to-peer waste redistribution platform

Edward Odero — Fri, 28 Aug 2026 11:23:53 +0000

The problem

Households and businesses generate waste that still has value — offcuts, e-waste, packaging, furniture, organic scraps — but most of it ends up dumped or burned simply because there's no easy channel to get it to someone who could reuse it.

At GreenTechHackathon
, my team set out to fix that with DumpTrade: a platform where anyone can post something they don't need, and anyone nearby who could use it can claim it free, fast, and dead simple.

This post walks through how we designed and built it, the trade-offs we made under a hackathon deadline, and a few implementation details I think are worth sharing.

The core idea

The loop is intentionally small:

Post → Browse → Claim → Collect

Every other feature exists to support that loop, not distract from it. We deliberately left out things like in-app chat, payments, and admin moderation for the MVP contact info is exchanged directly once something's claimed, and a report/flag button covers moderation for now.

Tech stack: why plain HTML/CSS/JS

We built the frontend in vanilla HTML, CSS, and JavaScript — no React, no build step. For a hackathon with a five person team and a tight deadline, that turned out to be the right call:

Zero tooling to configure or debug when someone's laptop acts up at 2am
Every page (index.html, browse.html, listing.html, post.html, login.html, register.html) is just... a file. Anyone on the team could open and edit any page without stepping on a bundler config.
A small shared api.js module simulates the backend for now — same function names/shapes we'll use once the real backend exists, so swapping in fetch() calls later should be mechanical rather than a rewrite.
dumptrade-frontend/
├── index.html / browse.html / listing.html / post.html / login.html / register.html
├── css/styles.css
└── js/
├── api.js # mock data layer — future home of real API calls
├── listings.js # shared rendering (cards, detail view, toast)
├── claim.js # claim / collect button logic
├── auth.js # login/register form handling
└── post.js # photo upload + post form
Claim logic: the one part that actually needed care

Everything else in the MVP is straightforward CRUD, but the claim flow has a real race condition: what happens if two people click "Claim" on the same listing at nearly the same time?

We handle it with a simple guard — check the status is still available right before flipping it:

js
function apiClaimListing(id) {
const l = apiGetListingById(id);
if (!l) return { ok: false, message: "Listing not found." };
if (l.status !== "available") {
return { ok: false, message: "Sorry — this was just claimed by someone else." };
}
l.status = "claimed";
return { ok: true, message: "Claimed!", listing: l };
}

In a real backend this becomes an atomic conditional update (UPDATE ... WHERE status = 'available', checking rows affected), but the logic is the same shape either way — check-then-set needs to be a single indivisible step, or you'll get double-claims.

Estimating environmental impact without a scale

One thing judges tend to respond well to: a number. "We helped the environment" is vague; "~340kg diverted from landfill" is a pitch. But we don't have IoT scales at a weekend hackathon.

Our answer: category-average weight estimates, applied when an item is marked collected.

Category Avg weight estimate
Furniture (large) 25kg
E-waste (large) 8kg
Textiles (per bag) 3kg
Construction offcuts 10kg
Organic waste 2kg

We're upfront about this being an estimate, not a measurement — methodology transparency mattered more to us than a falsely precise number.

Location filtering

Since "nearby" matters a lot for something people physically have to go pick up, Browse includes a location filter built from the cities already present in the listings data (parsed from a "City, Area" string) — not full geolocation yet, but enough to make results actually relevant:

js
function cityOf(location) { return location.split(",")[0].trim(); }

function apiGetListings(filters = {}) {
return _listings.filter(l => {
if (filters.city && cityOf(l.location) !== filters.city) return false;
// ...other filters
return true;
});
}

Real geolocation/maps is on the roadmap once there's a backend to store coordinates.

What's next
Wire up a real backend (Go or Node — still deciding) and a database
Real auth instead of the current mock login/register screens
Push notifications when something you'd want gets listed nearby
Recurring listings for businesses with regular byproducts (a cafe's daily coffee grounds, a workshop's weekly offcuts)
Try it / see the code
Live demo: [link]
GitHub: [link]

Built by [Name], [Name], [Name], [Name], and me at [Hackathon Name]. If you're working on something similar or have thoughts on the claim-race-condition approach, I'd love to hear them in the comments.

# Goroutines & Concurrency in Go: A Beginner's Guide

Edward Odero — Mon, 22 Jun 2026 07:12:41 +0000

By Edward Odero | Apprentice at z01 Kisumu

Introduction

One of the things that makes Go stand out from other programming languages is how it handles concurrency. If you've ever wanted your program to do multiple things at the same time — like fetching data from an API while also writing to a file — Go makes this surprisingly easy with something called goroutines.

In this article, I'll walk you through what goroutines are, how they work, and how to use them alongside channels to build concurrent programs in Go.

What is Concurrency?

Concurrency means doing multiple things at the same time (or at least, making progress on multiple tasks at once). Think of it like a chef cooking multiple dishes simultaneously — they don't finish one dish before starting another; they manage them all in parallel.

In Go, goroutines are the building blocks of concurrency.

What is a Goroutine?

A goroutine is a lightweight thread managed by the Go runtime. Unlike threads in other languages, goroutines are incredibly cheap — you can run thousands (even millions) of them without breaking a sweat.

You start a goroutine simply by using the go keyword before a function call:

package main

import (
    "fmt"
    "time"
)

func sayHello() {
    fmt.Println("Hello from a goroutine!")
}

func main() {
    go sayHello() // This runs concurrently
    time.Sleep(1 * time.Second) // Wait for the goroutine to finish
    fmt.Println("Main function done")
}

Output:

Hello from a goroutine!
Main function done

Note: Notice the time.Sleep? Without it, the main function might finish and exit before the goroutine gets a chance to run. We'll see a better way to handle this shortly.

The Problem: Goroutines Don't Wait

When the main function exits, all goroutines are killed — even if they haven't finished. This is why we need a way to synchronize goroutines.

Solution 1: `sync.WaitGroup`

A WaitGroup lets you wait for a collection of goroutines to finish:

package main

import (
    "fmt"
    "sync"
)

func printMessage(msg string, wg *sync.WaitGroup) {
    defer wg.Done() // Signal that this goroutine is done
    fmt.Println(msg)
}

func main() {
    var wg sync.WaitGroup

    messages := []string{"Hello", "from", "goroutines!"}

    for _, msg := range messages {
        wg.Add(1) // Tell WaitGroup to expect one more goroutine
        go printMessage(msg, &wg)
    }

    wg.Wait() // Block until all goroutines are done
    fmt.Println("All goroutines finished!")
}

Output (order may vary):

from
Hello
goroutines!
All goroutines finished!

Notice the order may vary! That's concurrency in action — goroutines don't always finish in the order they were started.

Channels: Goroutines Talking to Each Other

Goroutines are great, but what if you want them to share data safely? That's where channels come in.

A channel is like a pipe — one goroutine puts data in, another takes it out.

package main

import "fmt"

func sum(nums []int, ch chan int) {
    total := 0
    for _, n := range nums {
        total += n
    }
    ch <- total // Send result to channel
}

func main() {
    nums := []int{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
    ch := make(chan int)

    // Split the work between two goroutines
    go sum(nums[:5], ch)
    go sum(nums[5:], ch)

    part1, part2 := <-ch, <-ch // Receive both results
    fmt.Println("Total:", part1+part2)
}

Output:

Total: 55

Here, two goroutines each sum half the slice, then send their results back through the channel. Clean, safe, and concurrent.

Buffered vs Unbuffered Channels

By default, channels are unbuffered — a sender blocks until a receiver is ready (and vice versa).

You can create a buffered channel that holds a limited number of values without a receiver being ready:

ch := make(chan int, 3) // Buffered channel with capacity 3

ch <- 1 // Doesn't block
ch <- 2 // Doesn't block
ch <- 3 // Doesn't block
// ch <- 4 // This would block! Buffer is full

fmt.Println(<-ch) // 1
fmt.Println(<-ch) // 2
fmt.Println(<-ch) // 3

The `select` Statement

The select statement lets a goroutine wait on multiple channels at once — like a switch statement, but for channels:

package main

import (
    "fmt"
    "time"
)

func main() {
    ch1 := make(chan string)
    ch2 := make(chan string)

    go func() {
        time.Sleep(1 * time.Second)
        ch1 <- "one"
    }()

    go func() {
        time.Sleep(2 * time.Second)
        ch2 <- "two"
    }()

    for i := 0; i < 2; i++ {
        select {
        case msg1 := <-ch1:
            fmt.Println("Received:", msg1)
        case msg2 := <-ch2:
            fmt.Println("Received:", msg2)
        }
    }
}

Output:

Received: one
Received: two

select picks whichever channel is ready first — perfect for handling timeouts or multiple data sources.

Key Takeaways

Concept	What it Does
`go func()`	Starts a goroutine
`sync.WaitGroup`	Waits for goroutines to finish
`chan`	Creates a channel for safe communication
Buffered channels	Allow sending without an immediate receiver
`select`	Listens on multiple channels at once

Wrapping Up

Goroutines and channels are at the heart of what makes Go so powerful for building concurrent and scalable programs. The syntax is clean, the mental model is simple, and the performance is excellent.

As a beginner learning Go at z01 Kisumu, this was one of those topics that really made me appreciate the language. The fact that you can spin up thousands of goroutines with just the go keyword is honestly mind-blowing compared to threading in other languages.

If you're just starting with Go, I encourage you to experiment with goroutines — try building a small program that fetches data concurrently or processes a list in parallel. You'll be amazed at how approachable it is!

Feel free to drop a comment if you have questions or want to share your own experience with Go concurrency.

DEV Community: Edward Odero

Building DumpTrade a peer-to-peer waste redistribution platform

# Goroutines & Concurrency in Go: A Beginner's Guide

Introduction

What is Concurrency?

What is a Goroutine?

The Problem: Goroutines Don't Wait

Solution 1: sync.WaitGroup

Channels: Goroutines Talking to Each Other

Buffered vs Unbuffered Channels

The select Statement

Key Takeaways

Wrapping Up

Solution 1: `sync.WaitGroup`

The `select` Statement