09 · Online Learning
A live coaching and quiz portal layered onto an existing online course platform.
Two new modules, live coaching and a role-based quiz portal, shipped on top of an existing online course platform in late 2022. Sikrits was a UK-based online learning platform for creative and technical skills. I worked on it as a junior developer at Infex Biztech, where our team added live coaching with Zoom + Google Calendar booking, a role-based quiz portal, and a second Stripe subscription model on top of the existing pre-recorded course module.
Working on Sikrits as a junior developer at Infex
Sikrits was a UK-based online learning platform aimed at creative and technical skills (Photoshop, JavaScript, Python, and similar), with live coaching from UK-based coaches layered on top. The product lived at app.sikrits.com. The project is retired now. I worked on it in late 2022 as a junior developer at Infex Biztech Pvt Ltd.
The project came to our team at Infex (“Infex Biztech Pvt Ltd” for the formal name). Dixit Patel led the engineering. I was a junior on the team. The work was real, the lessons were mine, and the team carried me through the parts of Bubble.io I was still growing into.
The Sikrits marketing page. UK-based coaches, online courses for creative and technical skills, with live coaching as a paid layer on top.
What was already there, and what we added
When the project was handed to our team, the pre-recorded course module already worked. A coach could upload Vimeo links to lessons through an admin screen, students could browse course cards by category and tag, and the course playback flow ran end to end. That was the existing surface.
What our team built on top of it:
- Live coaching booking flow. A way for coaches to expose their availability and for students to book a one-on-one session against it. Custom calendar in Bubble.io (no off-the-shelf plugin handled the shape we needed), Google Calendar for the underlying availability source, and Zoom integration so every booked session created a real Zoom meeting with a join link the student received.
- Quiz portal with role-based functionality. Admins set up the quiz categories. Coaches added quizzes to their coaching topics. Users took the quizzes and saw their score. The same database read different content depending on who was logged in, which sounds simple but required careful thinking about the data model and the role-based visibility logic.
- Custom packages and a second Stripe subscription model. The platform sold pre-recorded courses on a subscription. It also sold live coaching as one-off slots and monthly subscriptions. Two different Stripe configurations running side by side, both integrated cleanly with the existing course module's billing.
- Admin dashboard with business analytics. Registered users, paid subscriptions, course visibility counters, an action log of every enrollment with email. The kind of operational visibility a coach needs to run the platform without asking the development team for SQL exports every week.
The course catalog the team inherited. Coaches uploaded Vimeo links through admin; students browsed by category and tag. The base on which the live coaching and quiz layers sat.
The custom booking calendar that took weeks.
The hardest part of the live coaching module, at least for me at the time, was the calendar. There was no Bubble.io plugin in late 2022 that handled the exact shape we needed: a coach’s recurring availability windows, blackout dates, buffer times between sessions, timezone math between a UK coach and a global student base, and a clean booking UI that did not feel like a Bubble plugin afterthought. We built it ourselves.
Looking back now, I can describe the right shape of a booking calendar in a few sentences. At the time I could not. Each piece (the availability data model, the per-coach view, the per-day slot rendering, the timezone conversion at display time, the prevention of double-bookings under concurrent requests) was a thing I had to learn by trying, breaking, and re-trying. Weeks of work, much of it slower than it would be now, all of it educational.
The calendar that shipped did what it needed to do: a coach saw their week with bookings, a student saw available slots in their local timezone, and a booking action wrote a row that became a real Zoom meeting and a real calendar event.
The shipped booking calendar. Three steps for the student (coach, date, slot), under it the timezone math, double-booking prevention, and the write that becomes a real Zoom meeting.
Zoom: a complex third-party API integration on a junior-dev timeline.
The Zoom integration was the second hard part for honest reasons. The Zoom API in 2022 had its own auth handshake (the JWT app type at the time), its own meeting-creation payload shape, its own response structure, and its own webhook events for when sessions started or ended.
Wiring it inside Bubble.io’s API Connector meant learning where every field belonged, how Bubble parsed the response, how to store the meeting ID and join URL on the booking record, and how to handle the cases where Zoom returned an error instead of a meeting. The first version was clunky. The version that shipped was cleaner because Dixit and I iterated on it through code reviews that taught me what good API integration hygiene looks like in Bubble.
The thing I would not have appreciated as a junior was how generously the senior engineer on a project subsidizes the learning curve of the junior. The Zoom integration shipped because Dixit caught the mistakes I would not have caught on my own.
The backend workflows the live coaching, billing, and enrollment paths all wrote through. Most of what makes a Bubble.io app feel reliable lives in this panel, not in the UI.
The quiz portal: three roles, one data model.
The quiz portal had three role-based views of the same underlying data. Admins set up the high-level categories that a quiz could belong to. Coaches created quizzes inside their categories and authored the questions and answer keys. Students browsed the quizzes for the topics they were studying, took them, and saw their score with a per-question breakdown.
The interesting work was the database design under that role-based UI. Quizzes belong to categories belong to admins. Questions belong to quizzes. Attempts belong to students belong to questions. A clean schema makes every read query straightforward and every write trivial; a tangled schema makes the entire portal feel slow and brittle. We spent meaningful time on the schema before any UI got built, and the rest of the module came together once the data model was right.
This is the project where the data model is the architecture crystallized for me as a working principle in Bubble.io. The UI is a thin layer over the schema. Get the schema right and the rest is straightforward.
The schema under the role-based views. Admin, Booking, Category, Course, CourseQuestions, Enrolment. Get this right and the UI is straightforward.
The quiz portal that fell out of the schema work. Three roles (admin, coach, student) reading the same data model through different views.
Two Stripe subscription models, side by side.
The platform had two distinct billing surfaces. The pre-recorded course module sold subscriptions to course access. The live coaching module sold packages: one-off consultations charged per hour, an ongoing coaching subscription billed monthly, and a higher-tier mentoring subscription billed monthly as well. Both ran on Stripe; both needed to coexist without one customer’s coaching subscription accidentally entitling them to course access (or the other way around).
The team set up two configurations on Stripe’s side with separate price IDs and entitlement logic on the Bubble side that read the customer’s active subscriptions and rendered the right access. The integration was tested on live transactions before delivery (which sounds obvious but for a junior in 2022 was the first time I saw the testing-on-live discipline applied rigorously).
The live coaching billing surface. Three packages on Stripe, running alongside the pre-recorded course module’s own subscription without entitlement crosstalk.
The admin dashboard the team built. Registered users, paid subscriptions, course visibility, enrollment action log, user growth chart. Operational visibility for the platform owner.
What the project taught me
Sikrits is the project where several Bubble.io habits clicked into place for me. The custom booking calendar taught me that the right time to build an in-house component is when the off-the-shelf plugins do not fit your exact shape, and to budget extra weeks when you go that route. The Zoom integration taught me what a complex third-party API integration looks like end to end. The quiz portal taught me that the data model is the architecture. The dual-subscription billing taught me that two Stripe surfaces can coexist if each one’s entitlements are calculated cleanly from the customer’s active subscriptions.
None of those lessons feel novel to me today. All of them were sharpened during this engagement. The reason I can write the way I write about Bubble.io now is that Infex put me on this project, Dixit led the engineering carefully enough that the parts I broke got fixed before they shipped, and Sikrits as a product ran on what we shipped.
What changed
The Sikrits product is retired. The team that built the live coaching module, the quiz portal, the custom calendar, the Zoom integration, the dual Stripe billing, and the admin analytics dashboard was Infex’s, with Dixit Patel as the lead and me as the junior who learned Bubble.io on the work.
The pattern of doing the work this way, on a team that gives a junior room to grow, is the part I would do again. Every Bubble.io project I have shipped since carries patterns and habits sharpened during my time on this engagement.