SYSTEM ANALYSISPROJECT MANAGEMENTFEATURED

Co-Founding a Campus Event & Ticketing Platform

Co-founded a campus organisation event and ticketing platform, owned requirements from idea to public launch with 600+ registered users, and learned first-hand why it stalled after MVP.

CONTEXT / PROBLEM

It didn't start with a brief. It started with a complaint we all shared.

We were students running campus organisations, and the administrative side was exhausting in a specific, repetitive way: attendance taken by hand, event payments collected through Google Forms, member communication scattered across chat groups, and the data you needed to make any decision sitting in four places at once.

Sky-Up Synergy was built as the single system for that — event and ticketing, organisation management, activity and attendance tracking, member performance, and financial withdrawal for organisation treasuries. It received funding through Brawijaya Startup Action.

My position in the founding team mattered. I was the first person to join with an IT background; the other founders came from business. That meant I wasn't handed a technical team to run — I had to work out what roles we needed, recruit them, and then lead them: four developers and one UI/UX designer, within a ten-person founding team. Backend in Golang, frontend in React and Next.js, design in Figma.

APPROACH

Find the general shape underneath a specific request, then make the stakeholder prefer it.

Refuse the narrow feature, propose the general one

The CEO wanted a feature built specifically to give competition-type events special handling. Competitions were commercially attractive and the request was reasonable on its face. I said no to the specific version: a competition-only feature would have solved one event type and left us needing a new special case for every event type after it — and on a four-developer team, that's how a product becomes unmaintainable while everyone is being helpful.

Design a container instead of a case

What I proposed instead was Series of Event: a series-as-container architecture where a series holds interchangeable modules — assignment, live session, attendance, announcement — with selective invitation so an organiser can advance only the participants who passed the previous stage. Competitions became one thing the platform could handle, alongside multi-stage training programmes and selection processes we hadn't scoped yet. The PRD specified it feature by feature with input and output contracts, constraints, and acceptance criteria, plus explicit features-out with reasons: automatic grading and automatic advancement were both deliberately excluded to keep admin control absolute in the first release.

Keep requirements traceable end to end

The SRS defines four actors with personas, then derives functional requirements from user requirements line by line — 82 user requirements for the end-user role alone, resolved into 94 requirement statements; 77 for the organisation admin, resolved into 89; plus company admin and superadmin roles. Ten-plus epics across ten-plus sprints, with all technical documentation and developer backlogs centralised in Jira and Confluence.

RESULT / IMPACT

A public launch, 600+ users — and a failure I turned into published research.

600+

Registered users at public launch

10+

Student organisations adopting the platform

82 → 94

User requirements resolved into SRS statements, end-user role alone

The platform reached public launch with 600+ registered users and adoption by 10+ student organisations across several universities. Growth came from direct outreach and business partnerships run by our business team. What I got wrong — two things, and they compounded. We had no QA function and I didn't compensate for it. Release testing happened without proper scenario coverage, which meant quality control at the end of the pipeline was weaker than the specification work at the front of it. Writing good requirements and not verifying against them is a strange way to fail, and it's the way I failed. Second, I absorbed too many small fixes requested by the business side. Individually each one took an afternoon. Collectively they beat the roadmap, fragmented the developers' focus, and produced exactly the context switching and technical debt that eventually stalled us after MVP. I didn't leave that as a regret. I made it the subject of my undergraduate thesis, built an AHP framework to solve the prioritisation failure specifically, and published it. Whether it was adopted after I left isn't something I control — I'd left the team by then. But the diagnosis was mine and so was the method. I left in July 2026, after my vision for the product and the CEO's had diverged and my closest collaborator had already gone.

HAVE SOMETHING SIMILAR?

Let's talk about the scope