Team Power Rangers PHASE 2

 


Hackathons have a strange energy. Things move fast, ideas feel bigger than they are, and somehow you end up making decisions at 2 AM that you later question—but also learn the most from. This is the story of how Team Power Rangers built our project during the Devtrails Hackathon, with a mix of clarity, confusion, and a backend that refused to stay consistent.

The Idea: Solving a Real Problem

We didn’t want to build just another app. From the start, we were clear on one thing—we wanted to solve something real.

The idea came from observing gig workers, especially delivery partners. Their income depends entirely on being able to work that day. But what happens when something unexpected happens? Heavy rain, a protest, a local disruption—suddenly they can’t work, and there’s no safety net.

That didn’t sit right with us.

So we asked a simple question:
What if there was a system that could detect these disruptions and help gig workers claim compensation automatically?

On paper, it sounded clean. Almost too clean.

Phase 1: When Everything Looks Easy

Like most projects, we started with the basics. Define the user flow, set up authentication, and think through how verification would work.

We planned for:

  • User registration with basic details
  • Identifying whether the user is actually a delivery partner
  • Collecting proof in the form of screenshots or activity logs

At this stage, everything made sense. The flow was logical, the features were clear, and we felt confident.

Then we started building.

And that’s when the small gaps started showing up.



Backend Struggles (Where Reality Teaches You Fast)

We chose Django initially. It felt like the safe choice—structured, powerful, and familiar.

But hackathons have a way of exposing every unnecessary complexity.

At some point, we thought using MongoDB might give us more flexibility. It sounded like a good idea at the time. But soon enough, we realized we were spending more time figuring out integration issues than actually building features.

So we did what most teams eventually learn to do: we simplified.

We switched to SQLite.

Not because it was the best long-term choice, but because it was the right choice for the moment. It worked, it was easy to set up, and most importantly—it didn’t slow us down.

That decision alone probably saved us hours.

If there’s one thing we took away from this phase, it’s this: in a hackathon, momentum matters more than perfection.


The Hardest Question: What Makes a Problem “Real”?

Building forms and storing data is one thing. But our core problem was different.

We weren’t just building a system. We were trying to answer something deeper:

How do you prove that a disruption actually affected someone’s work?

Anyone can claim they couldn’t work. But how do you verify that at scale?

This is where things got interesting—and complicated.

We started exploring multiple signals:

  • Weather data (rain intensity, temperature, air quality)
  • News APIs to detect major events
  • Social media activity to understand what people are talking about in real time

The idea was simple in theory: combine multiple sources and look for patterns.

But in practice, it meant dealing with noise, inconsistencies, and incomplete data.

We began thinking in terms of probabilities instead of certainty.
Not “is this disruption real?” but “how likely is it that this disruption affected work in this area?”

We didn’t fully solve it during the hackathon, but this part of the project opened up the most interesting direction for future work.

Designing the User Flow

While the backend and verification logic kept evolving, we made sure the user flow stayed simple.

We didn’t want users to feel like they were dealing with a complicated system. So we designed something straightforward:

  1. User logs in
  2. Marks themselves as “working”
  3. Confirms completed orders as basic proof of activity
  4. System tracks location and time in the background
  5. At the end of the day, the user uploads a screenshot
  6. The system processes all signals and checks for disruptions
  7. If everything aligns, the claim is approved

The goal was to reduce friction. If the process feels heavy, users won’t use it—no matter how good the idea is.


Team Power Rangers: How We Actually Worked

We didn’t just call ourselves Power Rangers for fun. The name ended up describing how we worked.

Everyone had their role, but no one stayed in their lane for too long. If something was stuck, whoever understood it jumped in. If something broke, we all looked at it together.

There were a lot of small, very real moments:

  • Code working perfectly and then suddenly breaking for no clear reason
  • Fixing one bug and accidentally creating two more
  • Restarting the server more times than we could count

At one point, we spent a good amount of time debugging something, only to realize it was a very small mistake. That’s just how it goes.

But those moments are where most of the learning happens.

Devtrails Hackathon: What It Actually Felt Like

The hackathon itself pushed us to think faster than we were comfortable with.

There wasn’t time to overthink decisions. You choose, you build, and you adjust if it doesn’t work.

It forced us to:

  • Prioritize what actually matters
  • Let go of unnecessary features
  • Focus on getting a working system instead of a perfect one

And most importantly, it reminded us that building something meaningful requires constant adjustment, not rigid planning.

What We’re Still Working On

The project didn’t end with the hackathon.

There are still open questions and improvements we want to explore:

  • Making the verification system more reliable
  • Using better models to detect real-world disruptions
  • Improving backend scalability beyond quick hackathon fixes

The foundation is there. Now it’s about refining it.


Final Thoughts

Looking back, the project wasn’t clean, and it definitely wasn’t perfect.

But it was real.

We dealt with changing ideas, technical constraints, time pressure, and a lot of uncertainty. And somewhere in all that, we built something that actually tries to solve a meaningful problem.

That matters more than having a polished product.

If there’s one thing this experience reinforced, it’s this:
building is messy, and that’s exactly how it should be.

And if your database changes halfway through the project, you’re probably doing it right.

– Team Power Rangers

 

Comments

Post a Comment