I Vibe-Coded the UCC SRC App. Here’s Why I Still Say No to $5,000 Hackathons

By Francis Pwavwe

University of Cape Coast, where student ideas do not need to remain ideas forever. Image: Wikimedia Commons / Adam Tuferu.

I vibe-coded the UCC SRC app.

That sentence sounds unserious if you do not understand what is happening in technology right now. “Vibe coding” has become the internet’s slightly chaotic name for building software with heavy assistance from AI tools: you describe what you want, iterate with the machine, test, break things, fix things, and slowly force an idea into existence. It is not magic. It is not laziness either. It is more like having a brutally fast assistant who can generate code faster than you can drink water, but still needs your judgment, taste, patience, and common sense to avoid producing a digital accident.

For me, building the UCC SRC app was not just about playing with AI. It was about asking a more serious question: what if student leadership had better digital infrastructure? What if announcements, feedback, services, representation, elections, requests, and student support were not scattered across WhatsApp groups, posters, rumors, and “please ask somebody” culture?

That is the part many people miss. The app is not the point. The point is the problem the app is trying to touch.

And that is exactly why I keep saying no to hackathons that promise “up to $5,000.”

The Prize Is Loud. The Fine Print Is Quiet.

Let me be very clear before someone starts typing with emotional damage: I am not saying all hackathons are bad. Some hackathons are genuinely useful. They can expose students to mentors, tools, datasets, teammates, new ways of thinking, and the pressure of shipping something quickly. A well-run hackathon can be a beautiful little laboratory.

But there is a type of hackathon I have become deeply allergic to. You know the kind. Big flyer. Big promise. Big prize. Big sponsor logo. “Up to $5,000.” Then you read closer and realize the money is usually for one winning team, sometimes split among members, sometimes delayed, sometimes tied to conditions, and almost never equal to the value of the ideas, code, design, energy, and free publicity extracted from dozens or hundreds of young builders.

“Up to $5,000” is doing a lot of emotional marketing. It sounds like a life-changing opportunity until you remember that most participants will leave with exhaustion, photos, a certificate, and maybe a branded T-shirt that will fade after three washes.

That does not automatically make it evil. Competition has losers; that is normal. The problem is when the event pretends to be empowerment while quietly using students as unpaid product researchers, unpaid developers, unpaid user-experience testers, unpaid community ambassadors, and unpaid content for LinkedIn posts.

Hackathons Love Ideas. Real Products Love Maintenance.

Building the UCC SRC app reminded me of something hackathon culture often hides: the first version is not the hard part. The hard part is everything after the applause.

Who updates the information? Who handles bugs? Who answers users when login fails? Who protects student data? Who explains the system to executives who did not build it? Who pays for hosting? Who fixes Firestore rules at midnight? Who makes sure the interface is usable for the ordinary student who just wants to find a deadline and move on with life?

A demo can impress judges in three minutes. A real app must survive Monday morning.

That is why I respect builders who stay with a product after the initial excitement dies. Anyone can pitch “an AI-powered platform to revolutionize student engagement.” Please. The graveyard of unfinished apps is already overcrowded. The real question is: can you make something boringly useful enough that people return to it without begging?

When I built the SRC app, I was not trying to perform innovation. I was trying to solve an institutional communication problem in a place I actually understand. That matters. Campus life is not an abstract design challenge. It has personalities, politics, network issues, sudden deadline changes, students who do not check email, executives with different priorities, and committees that somehow need “urgent” updates at the least convenient hour.

A hackathon rarely gives you enough time to understand that texture. It rewards speed, polish, novelty, and presentation. Real student technology rewards persistence, trust, reliability, and maintenance. Those are not always glamorous. They are just necessary.

Ownership Is Not a Small Matter

One of the biggest reasons I am careful with hackathons is ownership. Many participants do not read the rules properly. They see the prize and skip the legal language. That is dangerous.

Hackathon intellectual property rules vary widely. Some platforms state that makers retain ownership unless the official rules clearly require a transfer after an award is paid; Devpost’s general terms, for example, make that distinction while also granting promotional display rights to organizers and partners. You can read the relevant terms here: Devpost Terms of Service.

Legal explainers also warn that hackathon ownership can become complicated depending on event terms, sponsors, employers, team members, and public disclosure. The point is not panic. The point is literacy. Read the rules before you donate your brain to somebody’s innovation campaign. A useful overview is here: Best Practice: Hackathons and IP.

Some universities and organizers handle this well. Cornell Hackathons, for instance, states that the focus is experiential learning and that Cornell does not own the ideas generated at its hackathons. That kind of clarity is healthy. It treats participants like adults, not idea vending machines. See their terms here: Cornell Hackathons Terms and Conditions.

So my problem is not competition. My problem is opacity. If a hackathon wants students to build, fine. But say clearly who owns the work, what rights sponsors get, how prizes are paid, what happens after the event, whether teams can continue their projects independently, and whether participants receive support beyond “thank you for coming.”

Students Need Pathways, Not Just Prizes

A prize is not a pathway.

A pathway looks like mentorship after the event. It looks like cloud credits that do not disappear before the app becomes usable. It looks like legal guidance. It looks like introductions to real users. It looks like pilot agreements. It looks like small maintenance grants. It looks like paid internships. It looks like honest feedback from people who actually understand the problem. It looks like a chance to deploy, measure, improve, and learn.

Too many hackathons compress all of that into one weekend and pretend the winner has been “empowered.” No. The winner has been photographed.

And the rest? They are expected to feel grateful for exposure.

Exposure is not evil. Exposure can be useful. But exposure without structure is just noise. If a student builds something promising, the next question should not be “Can you pitch it again for our social media?” It should be “What do you need to test this with real users?”

That is the difference between innovation theatre and actual innovation.

Vibe Coding Changed the Cost of Starting

Hackathons can be powerful learning spaces, but the structure matters. Image: Wikimedia Commons.

AI has changed the economics of building. That is the uncomfortable truth.

A few years ago, a student with a serious app idea needed a developer, designer, database person, documentation person, and maybe a miracle from heaven. Now, with enough patience and enough willingness to learn, one determined person can prototype things that would have required a small team before.

That does not mean everyone should ship insecure apps into the world after two prompts and one prayer. Please, let us not turn campus technology into digital potholes. But it does mean students now have more leverage. You do not have to wait forever for permission. You can sketch, prompt, code, debug, test, and learn your way into a working prototype.

This is why the old hackathon model feels weaker to me now. If I can use AI tools to build a meaningful prototype around a real student problem, why should I spend my limited time building someone else’s theme for the chance of winning a prize I may never touch?

There has to be a better bargain.

My Rule Is Simple: I Do Not Build for Hype

I build when the problem is real.

I build when users exist.

I build when ownership is clear.

I build when the work can continue after the event.

I build when the people organizing it respect builders enough to be transparent.

That is my filter. If a hackathon passes it, I can consider it. If it is just prize money, noise, sponsors, vague impact language, and a promise that sounds bigger than the structure behind it, I am out.

Because I am not trying to become a professional contestant. I am trying to become a builder.

That distinction matters. Contestants optimize for judges. Builders optimize for users. Contestants chase applause. Builders chase adoption. Contestants polish demos. Builders fix login errors, rewrite confusing buttons, protect data, and answer the same user question seventeen different ways until the product finally becomes obvious.

One path gives you a certificate. The other gives you capacity.

What I Want Instead

If universities, companies, NGOs, and tech communities genuinely want to support young builders, here is my blunt suggestion: stop using prize money as the whole strategy.

Create student product fellowships. Fund small campus pilots. Pay maintenance stipends. Offer cloud and domain support. Provide access to mentors who can actually review code, security, design, and product direction. Connect builders to departments with real problems. Let students retain ownership unless there is a proper agreement. Publish clear terms. Build an aftercare system.

Imagine a UCC innovation pathway where a student does not only pitch an idea for three minutes, but gets three months to test it with a hall, department, association, or campus office. Imagine SRC, departmental associations, alumni, and tech partners supporting tools that solve ordinary student problems: timetable confusion, accommodation stress, campus safety reports, academic reminders, association dues, event registration, anonymous feedback, project supervision, internship tracking, and student welfare requests.

That would be serious.

That would be more useful than another flyer screaming “up to $5,000” while giving no clear road after the final pitch.

I Am Not Anti-Hackathon. I Am Anti-Extraction.

Let me end where I started.

I vibe-coded the UCC SRC app because I believe students should not wait for perfect conditions before building tools for their own communities. AI gave me leverage, but the reason mattered more than the tool. I knew the environment. I understood the irritation. I could feel the communication gaps because I live inside them.

That kind of building deserves more than a weekend performance.

So yes, I say no to many hackathons, even when the prize sounds sweet. Not because I hate opportunity. Because I have learned to ask better questions.

Who owns the work? Who benefits from the work? What happens after the event? Are students being developed, or merely displayed?

If the answers are weak, I am not joining. Simple.

The future of student innovation in Ghana will not be built by prize posters alone. It will be built by students who learn fast, build boldly, protect their ownership, and stay long enough with real problems to make useful things survive.

That is the kind of technology I want to build.

Not just the kind that wins applause.

Published on The Pwavwe Papers — blogs.pwavwe.com