I had worked with Go before.
I had also worked with Bitcoin.
What I had not worked with was a Go web framework.
Then came a 48-hour GreenTech hackathon at Zone01 Kisumu.
Naturally, I decided to change that.
Not because I had carefully compared every Go framework and found the perfect one. Not because I had years of experience building production applications with Go. I simply researched some of the popular Go backend frameworks for beginners, came across Buffalo, and thought:
"Well, Buffalo it is."
That decision would come back to haunt me a little.
But first, we had a problem to solve.
From BSF farming to organic waste
The hackathon was organized around broad problem tracks. Teams would choose a track and then narrow it down to a specific problem.
Our group settled on the waste management track.
The initial idea came from BSF — Black Soldier Fly farming. BSF farming uses organic waste as part of the process, and somewhere in our discussions, the idea clicked:
What if organic waste could be treated as a resource rather than simply waste?
But then we asked ourselves whether we should build the entire idea specifically around BSF farming.
We eventually decided against narrowing it that much.
Instead, we would build something broader around organic waste recycling, while still using the BSF farming cycle in our pitch because it was a relevant and familiar use case.
That became the foundation for RegenFeed.
The idea was fairly simple.
There are businesses and other large producers generating organic waste. There are farmers and other people who can make use of that waste.
Why not create a platform that connects the two?
Dividing the work
Once we had the direction, we divided the work and started researching our individual responsibilities.
I was part of the backend team, which had three people.
My responsibility was the backend core — broadly covering the database, authentication, and core migrations.
That was also when I started researching which framework I should use.
I already knew Go, but I had never used a framework for building a Go web application.
So I searched.
And Buffalo appeared.
I knew there were other options. I just hadn't used any of them before. At that point, Buffalo looked like a reasonable starting point for someone new to the concept of Go frameworks.
So I committed to it.
Looking back, it was definitely a premature judgment.
But it made sense at the time.
"You've chosen Buffalo? Then you guide us."
There was one small problem.
I was learning Buffalo.
My teammates didn't necessarily know that.
I remember pushing my first commit. Somewhere in the project they saw buffalo, and that was enough for them to realize what framework I had chosen.
Then came something along the lines of:
"You've settled on Buffalo? Buffalo it is. You guide us through it."
That sent shivers down my spine.
Guide you?
I had just started learning it myself.
But that was the situation.
So I started figuring it out.
And honestly, my first impression of Buffalo was magical.
You run a command — sometimes one that doesn't seem directly related to what you're trying to accomplish — and suddenly something has happened.
A model appears.
A migration is generated.
Some project structure is created.
Something is wired up.
And you're sitting there thinking:
"Wait. What just happened?"
That's one of the strange things about frameworks.
They can make development incredibly fast, but they can also hide a lot of what is actually happening underneath.
At times I felt like some of the commands were so shortened or abstracted that I could get something working without necessarily knowing the underlying SQL, module creation, or all the individual steps that would have been required without the framework.
That was both exciting and slightly terrifying.
The framework makes things easier — until it doesn't
This hackathon taught me something I hadn't really understood about frameworks.
Frameworks do make work easier.
But only if you know what to do with them.
If you don't understand the framework, you can end up in a much worse situation than if you had simply used the standard library.
And I experienced that firsthand.
As the backend started taking shape, the frontend team was already moving.
They kept reminding us that the backend was supposed to come first so that they could build against the endpoints.
They waited.
And waited.
Eventually, they decided to start anyway.
The agreement became: we'll sort out the endpoint issues later.
That "later" eventually arrived.
And it arrived with very little sleep.
When Buffalo met Svelte
The integration between the backend and the Svelte frontend was probably one of the hardest parts of the hackathon for me.
I pushed my work to the remote repository, expecting that we'd bring everything together and continue.
Instead, we got conflicts.
Things weren't communicating properly.
Work that had made sense in isolation suddenly had to work with everyone else's work.
And by then, I was exhausted.
It was almost morning.
At that point, I honestly can't give you a perfectly technical explanation of everything that went wrong. My brain was already running on fumes.
What I remember is debugging.
And needing help.
And eventually putting lunch on the line.
One of my teammates and I had developed a little system during the hackathon: whenever I got stuck and needed her help, we'd put sweets — and sometimes lunch — at stake.
I'd owe her one.
This was one of those moments.
And somehow, we got through it.
That's another thing I learned during the hackathon:
Group work is magical.
I would advocate for it any day.
Someone gets tired. Someone gets stuck. Someone's brain simply stops cooperating.
And somehow, the work continues because somebody else is still going.
What RegenFeed actually did
The MVP revolved around two main types of users:
Waste producers and farmers.
A waste producer could list organic waste on the platform.
The listing could contain information such as:
- the type of waste or its composition, such as carbohydrates, protein, or vitamins
- the weight available
- the price
- a picture
- the producer's locality
A farmer could then log into the platform, browse or search through available waste, find something useful, and place an order.
We also incorporated Bitcoin Lightning into the concept.
The producer could price the waste in satoshis, and when a farmer initiated an order, the platform could initiate a Lightning invoice for payment.
The physical exchange between the farmer and producer, however, happened outside the platform.
That distinction mattered.
We weren't trying to become a logistics company in 48 hours.
We were trying to create the digital marketplace connecting the two sides.
The part we didn't solve
And this is where being honest about hackathons matters.
We had an MVP.
But it wasn't a finished product.
The payment implementation was about as basic as we could make it within the time available. Questions around security, platform sustainability, and exactly how the business would make money weren't fully demonstrated.
There were also features that weren't completely implemented on the backend.
Every time we solved one issue, another unfinished piece seemed to appear.
So when I say we built RegenFeed, I don't mean we built a production-ready marketplace.
We built a proof of concept under a 48-hour constraint.
There was still a lot pending.
And that's okay.
Three minutes
Eventually, we had to present.
We had an MVP, and we had a story to tell.
Then we discovered another challenge:
Three minutes is not a lot of time.
Our idea had to be compressed into those three minutes, while still explaining the problem, the solution, the marketplace, the organic waste cycle, and the role of Bitcoin Lightning.
The competition was stiff.
The first three teams received prizes and recognition.
We weren't among them.
But the judges did give us something valuable: they acknowledged that the underlying idea was sound.
For me, that was enough to make the experience worthwhile.
What I would do differently
If I were starting that hackathon again, I'd change one major thing.
I would get comfortable with the backend framework and the core endpoint setup as quickly as possible.
The frontend team needed endpoints to move, and I took too long getting there.
A lot of the integration pressure later came from that delay.
I'd also establish the API contract much earlier.
Instead of waiting until everyone had built their pieces and then trying to make them communicate, I'd want the frontend and backend teams to agree early on:
- what endpoints exist
- what requests look like
- what responses look like
- what authentication looks like
- what data structures we're sharing
That would have saved us a lot of pain later.
What Buffalo taught me
I still haven't mastered Buffalo.
And I don't think I need to pretend that I did.
What the hackathon gave me was something more useful: I became less afraid of unfamiliar frameworks.
Before this experience, I might have looked at a new framework and thought:
"I don't know this. I'll stick with what I know."
Now my reaction is closer to:
"I don't know this yet. Let's figure it out."
That's progress.
I'm still more comfortable with Go's standard library at the moment. And I suspect that will continue to change as I explore more frameworks and build more applications.
But now I know something I didn't know before:
A framework isn't magic.
It is a collection of decisions and abstractions designed to make certain things easier.
The trick is understanding enough of those abstractions that they work for you rather than becoming another problem you have to fight.
And sometimes, the fastest way to learn that is to choose a framework on a questionable assumption, tell your teammates you'll guide them through it, and then spend the next 48 hours figuring out how to actually do it.
That's pretty much what happened to me.
I chose Buffalo.
Then Buffalo chose me.
Top comments (0)