Siap Dips

Siap Dips started from a very ordinary student frustration: campus work is not always hard, but it is often scattered.

SIAP has one thing. Kulon has another. Todoist is somewhere else. Forms repeat every week. Academic progress is hidden behind pages. Small clicks look harmless, until they become the thing you do over and over again.

So I built Siap Dips as a browser extension — not to replace the campus portal, but to sit quietly on top of it. A small companion layer for students who just want the repetitive parts of campus life to feel less annoying.

The problem

Most student systems are built like administrative dashboards. They technically work, but they rarely match how students actually move through their day.

A student does not open the browser thinking, “I want to use five different academic systems today.” They just want to check schedule, open the learning platform, remember tasks, see academic progress, fill a form, and move on.

Each task is small. The problem is the pile.

• Jadwal, IPK, tugas, form, dan portal kampus sering kepencar.
• Banyak klik kecil yang terasa receh, tapi numpuk setiap minggu.
• Mahasiswa butuh helper yang muncul di momen yang tepat, bukan dashboard baru yang harus diurus lagi.

Siap Dips tries to turn those repeated flows into something lighter.

What it does

Siap Dips brings small campus helpers into the browser, close to where students already work. The extension supports SIAP, Kulon, Todoist, schedule views, academic progress, routine forms, privacy tools, and small quality-of-life features for daily campus flow.

Some features are intentionally tiny. That is the point. The extension is not trying to be a giant student management app. It is trying to remove the small frictions that keep showing up.

• Jadwal kuliah yang lebih kebaca — takes schedule information and presents it in a cleaner way.
• IPK and academic progress helper — makes academic information easier to check without repeating the same navigation.
• Kulon / learning platform helpers — small improvements around the daily learning workflow.
• PBM auto-fill — helps with repeated forms so users do not have to type the same things again.
• Todoist integration — connects student tasks with a more familiar task management flow.
• Food Truck helper — helps with fast registration flows where timing matters.
• Theme and privacy tools — dark mode, blur sensitive data, and small comfort controls.

Usage and growth

The project started as something small for my own campus flow, but it slowly became a real extension used by students.

From the Chrome Web Store dashboard, Siap Dips reached:

• 1.87k installs
• 507 uninstalls
• 774 weekly users
• 1.2k+ peak weekly users
• 3.98k page views
• 1.79k Chrome Web Store views
• 96% weekly users from Indonesia
• 95% weekly users on Windows

The interesting part is that growth did not come from a big launch campaign. It was mostly from usefulness inside a very specific student context. The extension spread because the problem was familiar: everyone had the same repeated campus clicks.

Reading the numbers

The dashboard also made the project feel more real.

Most users came from Indonesia, which makes sense because the extension was built around campus workflows that are very local and specific. Windows dominated the usage, which also matches the average student laptop setup. For traffic sources, the extension sidebar and in-app entry points became important, showing that users were not only installing it once, but also opening it again inside their normal browser flow.

This changed how I thought about the project. It was no longer only “can I build this feature?” It became “will this feature survive real student behavior?”

A feature that looks cool in development is not automatically useful. A feature is useful when people keep coming back to it without needing to think too much.

Design principle

The best version of Siap Dips is invisible until it helps.

I did not want the extension to feel like another app students have to manage. The user should still open the campus portal like usual. Siap Dips just sits beside the page, reads the supported context, and gives a small helper when it is needed.

The flow is simple:

1. Install the extension.
2. Pin Siap Dips in the browser.
3. Turn on the helpers you actually use.
4. Open the campus portal like usual.
5. Let the extension handle the repeated parts.

That shape mattered. A browser extension can easily become noisy because it has access to many pages and many moments. Siap Dips had to stay useful without becoming another source of distraction.

Local-first by default

Siap Dips is designed around local-first defaults. Settings, cache, optional tokens, and helper configurations stay inside the browser extension storage.

There is no required backend and no forced account. External integrations, such as Todoist or AI helpers, only run when the user explicitly enables them and provides their own token.

• No required backend — the extension can work as a local browser layer.
• Optional tokens — external services are only connected when the user chooses.
• Scoped helpers — features are attached to the sites and pages that need them.
• Privacy controls — blur and comfort tools help users avoid exposing personal academic data.

This also made the project simpler to deploy and maintain. Instead of building a full backend system, I focused on making the browser layer reliable.

The hard part: shipping browser extensions

The hardest part was not only building the features. It was shipping them properly.

At first, deploying a browser extension sounds simple: build the project, zip the folder, upload it to the store. In reality, the moment I wanted proper releases, Chrome support, Firefox support, source packages, signed artifacts, and repeatable deployment, it became a small infrastructure project.

I ended up building a GitHub Actions workflow that can:

• build the extension from the main branch,
• read the version from package.json,
• package the Chrome extension as a .crx,
• upload to the Chrome Web Store,
• build a separate Firefox package,
• create a source archive for Mozilla review,
• publish to Firefox Add-ons,
• upload all release assets to GitHub Releases.

The tricky parts were mostly small details that break the whole pipeline.

Chrome needs the extension package and store credentials. Firefox needs a different build, a different manifest, an add-on GUID, a signed package flow, source code for review, and approval notes. GitHub Releases need consistent artifact names. The CRX private key cannot be committed, so it has to be injected safely from GitHub Actions secrets. The workflow also needs to behave differently depending on whether I want to publish to stores or only create release assets.

That is why the workflow uses two release modes:

• workflow_dispatch or commit message with [deploy] publishes to the stores.
• commit message with [release] only creates release assets.

It feels small, but this made the project much easier to maintain. I can push normal changes without accidentally publishing. When I am ready, I can intentionally deploy.

name: Deploy Browser Extensions

on:
  workflow_dispatch:
  push:
    branches:
      - main

permissions:
  contents: write

The full workflow handles Chrome packaging, Firefox packaging, Mozilla source archive, store upload, and GitHub Release upload in one pipeline.

This was one of the most useful lessons from the project: a real browser extension is not only the UI. It is also versioning, packaging, signing, review requirements, secrets, store-specific rules, and recovery when one of them fails.

Small product, real engineering

Siap Dips looks like a small student helper, but building it touched many layers:

• React and TypeScript for the extension UI.
• Vite for fast builds.
• Tailwind CSS for styling.
• Manifest V3 for Chrome extension behavior.
• Browser storage for local-first state.
• Content scripts for page-specific helpers.
• GitHub Actions for release automation.
• Chrome Web Store and Firefox Add-ons deployment.
• Separate packaging logic for different browser stores.

The project taught me that “small” does not mean “simple.” A small tool can still have real product decisions, real users, real deployment problems, and real maintenance cost.

What I learned

The biggest design lesson was restraint.

When building an extension, it is tempting to add every possible helper because the browser makes it technically possible. But a campus companion should not become another dashboard. It should not appear everywhere. It should not try to be the main character.

The useful thing is not more features. The useful thing is timing.

A helper feels good when it appears near the moment of friction, does one thing, and then gets out of the way.

Siap Dips became less about making a huge campus app and more about making the browser feel slightly more aware of student life.