Situation
Zeabur is a cloud deployment platform for vibe coders and engineers. As part of its growth strategy, the team provided sponsorship codes that partners could distribute at events, giving event attendees credits to use the platform.
Each week, 10+ partners approached the team through LINE, Discord and other channels. The marketing team spent 3–5 hours coordinating requests and checking information manually.
With information scattered across conversations and platforms, maintaining consistent, structured records was a challenge. The workflow relied heavily on manual input and was difficult to sustain, making it even harder to track partner performance and conversions to inform growth initiatives.
Task
The task was to turn fragmented partner requests into a self-service workflow, starting with event sponsorship codes. The scenarios and jobs-to-be-done are different for the key stakeholders:
- For partners, this meant a single place to submit event details, access their codes and see their status and performance.
- For the team, it meant capturing consistent information that matched the existing admin system, reducing repeated data entry and clarification, and linking each code to its partner so redemptions and paid conversions could be tracked.
The scope also had to be viable to build and maintain. Event codes were prioritised, while voucher purchases, deal commissions and withdrawals were deferred. The expected value was estimated from the existing partner base and acquisition performance, then weighed against the human effort required to build and support the service.
A retrospective ITIL scan of ongoing maintenance needs.
Action
Mapping the existing system
I first mapped the existing partnership mechanisms and their underlying data flows, covering referral codes, event sponsorship codes, gift cards and sales commissions. This exposed gaps between partner activity, user attribution and reward tracking, alongside steps that still depended on manual coordination.
The map helped define what the portal needed to connect: partner identities, requests, codes and performance records. It also informed the decision to focus the first prototype on the event sponsorship workflow.
Existing system and attribution gaps
Referral Code ──→ User attribution ──→ Automated commission tracking
Event Code ──→ Credit top-up ──→ Admin performance dashboard
└── Missing link to the originating partner
Gift Card ──→ Credit top-up
└── No attribution to the selling partner
Sales Commission ──→ Manual processing
└── No integrated tracking system
Building the first prototype
I translated the system map into an event sponsorship prototype, bringing partner requests and code management into a single interface. To keep the tech stack aligned, the system architecture reused Zeabur’s existing sign-in and sponsorship infrastructure rather than introducing separate authentication or a duplicate code database. The initial scope focused on event codes, keeping the first version manageable to build and support.
The current portal shown with demo data; this is not an archived screenshot of the first prototype.
Evolving the workflow prototype
As the workflow prototype was being developed, I found two additional scenarios needed amendment whilst observing my colleagues trying it out:
- We need a separate database to store the partners' information
- Isolated from our main user database, with one-way view access for verification
- Should not store any sensitive user information, only the information necessary for applications
- Edit and draft modes for applicants are needed to prevent submissions made in error (and a database to store them)
- Only valid submissions will be parsed into the main system
- Rate limits for multiple submissions should be considered
- Workarounds should be managed separately
After comparing several database options, I chose MongoDB as the final solution. The collection design of Mongo can keep the application and review history separate but still in one place.
Aligning self-service with operational oversight
After launch, the CEO and Head of Operations questioned a sponsorship request they had not been aware of. I reframed the issue by sharing the partner’s request records and the existing wiki guidelines, then clarified whether the concern was the amount requested or the visibility of the process. The discussion revealed a tension between reducing manual coordination and maintaining control over sponsorship credits.
I reviewed 6 months of requests alongside the service blueprint and user journey, then proposed an additional review step for requests above an agreed threshold and automated monthly reporting. This gave stakeholders a concrete proposal to discuss, balancing partner autonomy with internal oversight.
After aligning the proposal with stakeholders, I implemented the changes end to end and automated report delivery to Discord, giving the team regular visibility into partner activity.
Result
From a purely manual workflow, to a system prototype, and eventually a working system. The portal turned a workflow spread across conversations into a working self-service platform.
Partners could submit event details and access sponsorship codes in one place, reducing the need for repeated coordination with the marketing team. Structured application records and the internal Kanban workflow made requests easier to trace, while automated Discord reports gave the team regular visibility into partner activity.
Reflection
Building systems nowadays is way too easy. With all the vibe coding tools, it's possible to build a website in 15 minutes. Working in a tech startup and among developers especially pushes me to pick up engineering knowledge; however, one thing I've learnt a lot from not just iterating the system but also aligning things with the team is that defining the root cause is the most essential task to do beforehand.
Build systems from actual workflows, and solve the frictions step by step. Ask questions to dig out the actual need; use tools to demonstrate and align understanding. Avoid building systems out of context!