A few months ago, I didn't expect that I'd be spending my days debugging authentication flows, opening pull requests, analyzing backend architectures, and building a Bitcoin education platform during a hackathon.

Yet here we are.

What started as curiosity about Bitcoin turned into one of the most intense learning experiences I've had as a builder, and honestly, I wouldn't trade it for anything.

This is the story of how I joined Hack4Freedom Lagos 2026, helped build BitPath, contributed to open source, discovered OpenCode, and learned that software engineering is often just solving one problem after another until things somehow start working.

How I Ended Up Building in Bitcoin

My interest in Bitcoin didn't start from price charts or trading.

What attracted me was the builder ecosystem around it.

I've contributed to open source before, so I already appreciated the value of collaborative software development. But what stood out about Bitcoin was how deeply open source is woven into the culture.

In many ecosystems, open source feels like an option.

In Bitcoin, it feels like a foundation.

Everywhere I looked, people were building in public, contributing to projects, improving documentation, reviewing code, and helping newcomers find their footing.

That environment made me want to participate more deeply.

When the opportunity came to join the Hack4Freedom Lagos 2026 hackathon, I said yes.

The Project: BitPath

Our team worked on BitPath, an AI-powered learn-and-earn platform designed to make Bitcoin education more accessible.

The idea was simple:

Instead of overwhelming learners with technical concepts, BitPath uses conversational learning experiences, AI tutoring, quizzes, progress tracking, and rewards to help users learn Bitcoin and financial literacy in a more engaging way.

Our stack looked something like this:

Frontend

• Next.js
• TypeScript
• Tailwind CSS
• Zustand

Backend

• NestJS
• PostgreSQL
• Redis
• Queue processing

Additional Services

• Google OAuth
• OpenAI APIs
• Lightning Network integrations

At least that's what it looked like on paper.

In reality, there was a lot more chaos involved. 😅

Frontend Meets Backend (And Everything Breaks)

One of the biggest learning experiences during the hackathon was frontend-backend integration.

If you've never experienced it before, imagine spending hours building a beautiful UI only to discover that the API contract changed while you were working.

Now multiply that by several days.

There were moments when authentication worked perfectly.

Then suddenly it didn't.

There were API responses that looked correct until they weren't.

There were environment variables that seemed fine until they quietly caused issues.

And there were enough network errors to make me question my entire setup.

One of the most memorable moments involved Google OAuth.

Everything appeared configured correctly.

Then I started getting:

Error 401: invalid_client

At that point, I learned a valuable lesson:

When authentication breaks, the error message is rarely as helpful as you want it to be.

Eventually, after digging through environment variables, OAuth settings, callback URLs, and backend configurations, we figured it out.

But the journey there was definitely educational.

Discovering OpenCode

One unexpected highlight of this experience was OpenCode.

I started using it as a coding assistant, but quickly realized it could be much more than that.

Whenever I encountered unfamiliar repositories, backend services, API contracts, or open-source issues, I'd use OpenCode to help analyze the codebase and break down the problem.

Some examples included:

• Understanding backend API structures
• Analyzing repository architectures
• Generating implementation plans
• Reviewing issue descriptions
• Preparing pull requests
• Understanding integration requirements

The most valuable part wasn't that it wrote code.

It was that it accelerated understanding.

I could move from confusion to clarity much faster.

And as any developer knows, understanding the problem is usually half the battle.

Contributing to Open Source Along the Way

The hackathon wasn't the only thing I worked on.

During the same period, I continued contributing to open-source projects.

One thing I love about open source is that every contribution teaches you something different.

Sometimes you're fixing a bug.

Sometimes you're cleaning up technical debt.

Sometimes you're improving performance.

And sometimes you're simply helping reduce confusion for future contributors.

One issue involved removing incomplete database migration artifacts that suggested a migration was underway when the application still relied on JSON storage.

Another involved implementing in-memory caching to reduce redundant disk reads.

Each contribution required reading unfamiliar code, understanding existing architecture, and making changes without breaking functionality.

That process never gets old.

The Reality of Building

One thing I've learned is that software engineering rarely looks like the polished screenshots people share online.

Most of the time it looks more like:

• Reading documentation
• Debugging errors
• Testing assumptions
• Asking questions
• Breaking things accidentally
• Fixing what you broke
• Repeating the cycle

And honestly?

That's okay.

Because every bug fixed is knowledge gained.

Every pull request teaches something.

Every deployment reveals a new lesson.

What Bitcoin Taught Me About Open Source

If there's one thing that stood out throughout this journey, it's how much Bitcoin values contributors.

Not just experienced developers.

Contributors.

People who show up.

People who learn.

People who improve documentation.

People who fix bugs.

People who help others.

That culture is powerful.

It creates an environment where growth feels possible because participation matters more than perfection.

And that's something I deeply appreciate.

Lessons I'll Take Forward

Looking back, this experience taught me several things:

• You don't need to know everything before you start building.
• Frontend-backend integration is a skill you only learn by doing.
• Open source remains one of the best ways to grow as a developer.
• AI tools are most effective when paired with curiosity.
• Debugging is frustrating until it becomes rewarding.
• Consistency beats confidence.

Most importantly, I learned that growth often starts when you're willing to be uncomfortable.

What's Next?

This journey is far from over.

BitPath is still evolving.

There are more Bitcoin concepts to learn.

More repositories to contribute to.

More pull requests to open.

More bugs to fix.

More things to build.

And that's exactly what makes it exciting.

For now, I'll keep doing what got me here in the first place:

Showing up.

Building.

Learning.

Contributing.

And hopefully helping someone else do the same.

If you're building in Bitcoin, contributing to open source, or participating in hackathons, I'd love to hear about your experience.

What has been your biggest lesson so far?