A live coaching and quiz portal layered onto an existing online course platform.

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.

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.

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, and a booking UI that did not feel like a 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 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 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 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).

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.

The product is retired. 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 habits sharpened during this engagement.