Building the Digital Gateway to Desa Krisik

Dev Diary

I didn't expect this project to start with a valley.

It was July 2024, and our team sat down with the village officials of Desa Krisik for an interview that was supposed to be a formality before the real work began. Krisik sits between two volcanoes, Mount Kelud to the west and Mount Kawi to the east, and it has the kind of scenery that makes you forget you're there to talk about websites. The village already had what it needed to draw visitors — places like Telaga Rambut Monte and Kromasan, curated and cared for by the people who lived there. What it didn't have was any way to tell the rest of the world about them. No consistent online presence, no easy way to post an announcement, nothing residents could turn to for basic information.

That gap became our project for the Mahasiswa Membangun Desa program: a village profile website with a tourism catalog (complete with 360-degree virtual tours, courtesy of our teammates who actually got to hike around and film), public announcements, administrative info, and a section for local MSMEs. Simple to describe. Less simple to build in a month, with six other people, most of whom were about to spend their days in the mountains while I stayed behind with a laptop.

This is the story of how that happened — the choices that worked, the ones that didn't, and what I understood about this kind of work only after it was over.

Choosing a Stack We Could Actually Trust

As lead developer, one of my first real responsibilities was picking the stack, and I remember feeling the pull to choose something impressive. We talked through a few options. In the end we went with a plain Laravel fullstack setup, and honestly, the reason was unglamorous: it's what we knew. We'd just come out of our fourth semester, where our core web development coursework had been built around Laravel. Choosing it meant we could move immediately instead of losing our first week to a learning curve none of us had time for. Everyone on the team agreed without much debate, which in hindsight was its own kind of relief.

We paired it with Filament for the admin backend and Blade with Tailwind CSS for the frontend — tools that let a team of student developers, working fast and without a lot of margin for error, actually ship something coherent.

Trying to Design Like We Knew What We Were Doing

None of us were designers. That was obvious the moment we opened Figma and stared at a blank canvas, unsure where to even start. So we did what a lot of people do when they don't trust their own instincts yet — we looked for a reference point we admired. We landed on Harvard's website: the restraint of it, serif headings against clean sans-serif body text, the deep red used sparingly rather than everywhere. It gave us a language to work in instead of guessing.

We gave ourselves five days for a rough prototype. It wasn't polished. Looking back at those early Figma files still makes me wince a little. But it was enough of a foundation to start writing real code with some confidence that the site wouldn't look like seven different people had built seven different pages.

Three Weeks, Mostly Alone With the Code

Once development started, the work fell unevenly. While the rest of the MMD team was out in the field — surveying tourism spots, capturing footage for the 360 tours, actually experiencing the valley we were building a website about — I was mostly at my desk. For about three weeks, that meant somewhere around twelve hours a day of writing code, breaking things, and fixing them again.

Filament genuinely made a difference here. It generates CRUD systems with so little boilerplate that it almost felt like I was skipping a step I was supposed to take. That saved time let me put more care into the parts that actually faced visitors — making sure the Blade templates held up and that Tailwind kept everything responsive across the range of devices real users would show up with.

I won't pretend those three weeks felt heroic while I was in them. Mostly they felt like a quiet, repetitive kind of focus — the sort of work that's hard to describe afterward because so much of it was just sitting with a problem until it gave way. But there was a real satisfaction in watching disconnected pieces start to behave like one system.

Deployment Was Its Own Education

If your only experience with shipping software is something like Next.js on Vercel, where a git push turns into a working deployment almost by magic, traditional PHP hosting is a genuine adjustment. We didn't know Docker, and setting up our own VPS felt like more than we could take on in the time we had left, so we went with cPanel instead.

I won't dress this part up. cPanel was frustrating in a very specific way — not hard exactly, just tedious and unforgiving. File structures on the server didn't match our local setup. Permissions broke for reasons that weren't obvious. More than once, fixing a bug in production meant manually editing files over FTP rather than pushing from a repo. It wasn't the workflow any of us wanted, but it got the site live, and there was something satisfying about that even if the path there was ugly.

What the Project Actually Taught Me

The build itself was maybe half the lesson. What happened after taught me the rest.

Some Thanks

None of this happened alone. Thank you to Azraf, Juju, Herdi, Theo, and Fajru for writing code alongside me, catching bugs I missed, and staying in it until the site was actually live. And thank you to the whole MMD KrisikAsik team for the fieldwork, the 360 tours, and for making a month of long hours feel like it was in service of something real.

If you want to see more of the valley we spent that month with, our archive is on Instagram: @mmd_filkom_krisik_18.