How It Started

I graduated from METU in 2022. Two years later, my sister started studying there and became a board member of the Gastronomy Club. When she was brainstorming ways to contribute, I had an idea.

The club kept their restaurant recommendations in an Excel file. It worked, but sharing it was a pain. Someone would ask for recommendations, and they'd have to send the file or copy-paste from it. Not ideal.

So I offered to build them a proper web app. A public database where anyone could browse, search, and discover restaurants. It was a good excuse to help my sister and give something back to my alma mater.

Development Timeline

Real talk: this wasn't a straight sprint. Life gets in the way.

I started in early September and put in about 2 weeks of work on the initial version. Got the basics working, then completely stopped for 2 months. Work, other commitments, the usual.

Picked it back up in November. By then I had clearer ideas about what the final product should look like. Revamped the whole thing in about a week.

Total active development time: roughly 3 weeks spread over 3 months.

Why This Tech Stack

Every decision came down to three constraints:

1. Zero hosting cost — I'm not paying monthly fees for a side project
2. Beginner-friendly — Future maintainers might not be experienced devs
3. Easy to hand off — My sister won't be on the board forever

From day one, we planned for someone else to take over this project eventually. That shaped everything.

Vercel

Most popular hosting option in the Next.js ecosystem. Generous free tier. When the new maintainer googles "how to deploy Next.js," every tutorial will mention Vercel. That matters.

Next.js

Huge community, tons of tutorials, and here's something I didn't expect: LLMs understand it really well. If future maintainers use AI coding tools (and they probably will), the AI will know how Next.js works. That's a real advantage.

Supabase

Database, auth, and image storage all in one place. The dashboard is intuitive enough that non-devs can poke around without breaking things. Row-level security means I can give people access without worrying too much.

Tailwind CSS

Love it or hate it, it's readable. Someone can look at the code and understand what's happening without digging through CSS files. That helps with handoffs.

The Data Problem

Here's the thing nobody tells you about building a "simple" directory app: you need data.

The club had a list of restaurant names. That was it. No photos, no descriptions, no addresses, nothing. Just names in a spreadsheet.

I wasn't going to manually research 90+ restaurants. So I built a pipeline.

Step 1: SERP API for Basic Info

Used a search API to fetch publicly available information about each restaurant. Location, photos, that kind of thing. Not perfect, but good enough for a starting point.

Step 2: AI-Generated Descriptions

This is where it got interesting. I pulled the most popular reviews for each restaurant, fed them into Google AI Studio with custom instructions, and generated descriptions.

The prompt was specific: write like a friend recommending a place, not like a marketing copy. Mention what the place is known for. Be honest about any downsides mentioned in reviews.

Used structured output to keep the format consistent across all entries. Big context windows helped process multiple reviews at once.

Step 3: Electron Wrapper

Now, here's the part I'm actually proud of.

I wrapped the whole ETL pipeline into an Electron app. Added proper UI for selecting restaurants to process, stored API keys securely, and made it point-and-click simple.

Why? Because I'm not going to be around to run scripts every time they want to add a restaurant.

Now any board member can:

1. Add a restaurant name to the database
2. Click a button in the app
3. Wait for the pipeline to fetch and generate data
4. Review and publish

No terminal commands. No code changes. No calling me at midnight.

Lessons Learned

Building for Handoff Changes Everything

When you're building for yourself, clever code is fine. When you're building for handoff, every clever trick is debt.

I caught myself multiple times writing "smart" abstractions that would confuse anyone else. Had to delete and rewrite with boring, obvious code instead.

Boring is maintainable. That's the lesson.

Documentation is User Interface

Wrote way more docs than I usually would. Not because I'm organized, but because I know I won't remember this stuff in 6 months, let alone when someone else takes over.

Every non-obvious decision has a comment explaining why. Every component has usage examples. The README assumes zero context.

Scope Creep is Real

Started with "just a restaurant list." Ended up with user accounts, favorites, admin panels, and an ETL pipeline. Could have shipped something simpler in a week.

But here's the thing: the extra features actually made the handoff easier. A proper admin panel means future maintainers don't need database access. Worth the scope creep.

What's Next

The app is live and the club is using it. My sister's team adds restaurants regularly using the Electron tool.

At some point, she'll graduate and hand this off to the next board. The code is ready for that. Whether they'll actually read the docs is another question.

If you're curious, check it out here.

And if you're building something for a community you care about, my advice: plan for the handoff from day one. Future you (or future someone else) will thank you.