Building in Public as an Indonesian Developer

Two years ago I started posting short updates about what I was actually building at work and on the side: a retry queue that kept failing silently, an approval workflow package I open sourced, a deployment pipeline I rebuilt from scratch after a bad rollback. No polish, no thread hooks, just what shipped and what broke. I did not expect much from it since I am based in Indonesia, several hours removed from the loudest tech conversations on the internet, and most of the accounts I was reading from felt very Bay Area and very English-first.

What actually happened surprised me. Recruiters found the posts before they found my resume. A potential client messaged me about the exact package I had complained about shipping. Other developers in Jakarta and Surabaya started replying with their own version of the same problem. Building in public did not make me famous, and it did not skip any of the slow parts of a career, but it changed who could find my work and how much context they had before we ever spoke. This post is the honest version: what worked, what felt awkward, and a schedule you can actually keep.

What building in public actually means

Building in public is the practice of making the work of building something visible as it happens, not just the finished result. It traces back to transparent startup culture and the indie hacker movement, where founders posted revenue numbers, failed launches, and half-built features instead of only polished announcements. For a software engineer, the unit of content is smaller and more frequent: a commit that fixed a real bug, a design decision you reversed, a benchmark that surprised you. The goal is not virality. It is leaving a visible trail of real engineering work that someone searching for the same problem can find later.

• Small, frequent updates beat rare, polished announcements because they compound into a searchable history of your work.
• The audience is not just your followers today. It is anyone who searches the exact error message or package name you wrote about, months from now.
• You are not performing confidence. You are documenting a real process, including the parts that did not work on the first try.

Why the Indonesia angle matters more than it seems

Most of my audience is not in Indonesia, and most of the content I read is written in a US or European time zone. That gap is not a disadvantage once you use it deliberately. Posting a build log entry at the end of a WIB workday means it lands early morning for European readers and late evening for US readers the next day, giving it two separate waves of attention instead of one. It also means the content itself is unusual: an ERP developer writing about hierarchical approval workflows from Jakarta reads differently than the same post from a generic SaaS blog, because it signals a specific, less crowded niche. Being visibly Indonesian is not something to downplay in a bio, it is a distinguishing detail recruiters and clients remember.

The realistic playbook to start this week

You do not need a content calendar, a newsletter, or a personal brand strategy document to start. You need a place to write and a habit small enough to survive a busy sprint. Here is the version I actually kept up for two years without burning out.

1. Pick one channel only. I use a public GitHub repository for build logs and a professional network post for the summary, nothing else. Two channels is already a second job.
2. Write the update as a build log entry, not a caption. Date, what changed, why, what is next. Four lines is enough.
3. Post twice a week on a fixed day and time, not whenever inspiration hits. Consistency is what makes the archive searchable and trustworthy, not frequency.
4. Every fourth or fifth entry, turn one into a longer article once it has enough detail to be useful to someone hitting the same problem.

// BUILD_LOG.md — one entry per shipped change
## 2026-07-03
- Added retry queue to the invoice sync job (WITA cron window)
- Root cause: webhook timeout under 3s, Resend retries needed backoff
- Next: write up the retry design as a short post this weekend

## 2026-06-26
- Migrated the approval workflow package to v2 API
- Broke one downstream consumer, fixed with a deprecation shim
- Opened the package as public on GitHub, linked from LinkedIn post

The awkward parts nobody tells you about

It is not all upside, and pretending otherwise sets people up to quit after two weeks. Here is what actually felt uncomfortable, especially writing in English as a second language from Indonesia.

• Silence for months. Most build log entries get almost no engagement. The value shows up later, when someone searches the exact term you used, not in real-time likes.
• Writing in English slower than you think in Indonesian. I still draft technical explanations in Indonesian first for complex ERP logic, then translate, because forcing English-first thinking made the explanations worse.
• Sharing a mistake publicly feels riskier than it is. In two years, no client or employer ever held a documented bug fix against me. If anything, it read as competence, not carelessness.

What it actually changed

The concrete outcomes were smaller and slower than the growth-hacking version of this advice promises, but they were real. A build log entry about a retry queue became the reason a client reached out, because they had the exact same webhook timeout problem and my post explained the fix better than the vendor's documentation. Two recruiters mentioned reading a specific post before ever messaging me, which meant the first call skipped the usual explaining-what-I-do phase entirely. And other developers in Indonesia started reaching out with their own version of the same bugs, which turned into informal code reviews for both sides.

A concrete 30-day plan

If you want to start this week instead of reading about it for another month, here is the exact sequence I would repeat if starting over.

1. Week 1: pick one public repository or blog you already have, and write one build log entry about something you shipped in the last seven days.
2. Week 1: post the summary in one place only, on a fixed day, at a fixed WIB time.
3. Week 2 and 3: repeat twice a week, no exceptions, even if the update feels small.
4. Week 4: take the entry that got the most questions or replies and expand it into a longer article with the full technical detail.
5. End of month: review what got read, not what got likes, and let that steer which kind of problem you document next.

None of this requires a large following, a US time zone, or native English. It requires a habit small enough to survive a bad week and consistent enough to become searchable. Two years in, that is still the entire strategy: ship something real, write it down honestly, and let the archive do the work while you keep building.