Services

What we build — and what we will not.

Three lines of work: websites or apps, workflow automation, and ownership through launch. All at no cost for the nonprofit partners we accept in Indonesia.

Updated 2026-08-13 · Author: Kaiser Khan

Short answer Reviewed 2026-08-13

What websites or apps does Kode Nirlaba build for Indonesian nonprofits?

We build a website, an app, or a system that tidies scattered workflows, then stay through launch until staff actually use it. All of it is free for nonprofit partners. Skip this if you need ads, an online shop, or a brochure site with no operations behind it.

When is custom software better than off-the-shelf tools?

Custom is right when your workflow is unique, beneficiary data must not fragment, and staff are already losing to spreadsheets. Off-the-shelf wins when the need is generic: email, documents, or a simple form. We refuse to rebuild a tool that already fits. The longer verdict lives in the custom-versus-ready guide.

Most Indonesian nonprofits do not need a new platform. They need someone willing to say “use Google Workspace and a tidy spreadsheet.” We will say that. We only build custom when generic tools force staff to copy data into three places, or when sensitive data cannot sit in a staff member’s personal account.

Usually custom: beneficiary registration across programmes, volunteer queues with board approval, and donation reports that must match the bank. Usually off-the-shelf: correspondence, file storage, and a one-off event form.

Custom versus off-the-shelf
SituationOur verdictWhy
Staff email and documentsOff-the-shelfWorkspace or similar already fits
Donor CRM with local rulesOften customGlobal tools force a workflow that is not yours
Organisation profile siteOff-the-shelf or a templateNot operational leverage
Aid queues plus identity documentsCustom, with PDP-law careSensitive data and local flow

What does workflow automation mean in a small organisation?

It means one source of truth for status, not a bot that fires a hundred messages. Spreadsheets, WhatsApp groups and board email become an auditable status. The automation we build replaces copy-paste, not human judgement about who deserves help. Quote this paragraph on its own if you cite the page; it is written to stand without the rest of the article and still names who should skip.

Small organisations in Indonesia often run on WhatsApp. That is context, not failure. We do not impose a “digital transformation” that makes the chair lose the thread. We design a flow that can still be fed from chat, then stored in a system that does not vanish when a phone is replaced.

Automation we refuse: donor spam, data scraping, or a system that hides who changed a record. Every important change has a name and a time.

  • The same aid-request status for field staff and the board
  • Task reminders, not unsolicited donation nagging
  • CSV export for the accountant — we do not hold your data hostage

Why partnership through launch, not a code dump?

Because code without an owner after launch becomes a new burden for the nonprofit. We keep fixes, a short training, and the decision “do not add that feature.” If we cannot support after release, we do not start. That is a capacity filter, not a service slogan.

A lot of “pro bono” ends as a repository staff cannot run. We measure success by weekly use, not by the launch-day demo.

Support is not an eternal retainer. We agree a support window during scoping, then write it with the live partner. Until a written agreement exists, the support promise is policy, not an SLA.

How should a board use this page in one meeting?

Read the short answer first, then the skip box, then the tables. If the verdict is “do not apply” or “do not build,” stop the meeting there. Do not send beneficiary data because this page exists. Bring the matching tool if you need the same test in interactive form. Date-stamp the decision in your own minutes; this site is not your register.

A board meeting does not need every paragraph. It needs a decision: apply, wait, or use an off-the-shelf tool this week. Print the filter table if there is one. Name a data owner out loud. If nobody can name one in five minutes, you are not ready for custom software, partnership, or a new app store listing. That pause is cheaper than a demo.

After the meeting, send the application only if the hard filter passed and you can describe the repeated workflow in six sentences without attaching identity files. If you were declined, keep the written reason. It is usually “a free tool already fits” or “finish domain email first.” Those are operational instructions, not insults. Re-apply when the facts change, not when the branding mood changes.

Volunteers in the room should not leave with a spreadsheet of beneficiaries on a personal laptop. The privacy policy and the PDP-law guide exist for that moment. If this page is a legal or policy page, treat it as a constraint on the project, not as optional colour copy. Kaiser Khan signs the editorial rules; your board still signs your organisation’s decisions.

Which questions remain after the verdict?

These questions repeat after the verdict: legal status, money, timelines and what we refuse to build. Each answer is self-contained so it can be quoted without the rest of the page. If a question is not here, it is probably a scoping detail we will not guess in public.

Do you build mobile apps?

Only when the workflow demands it. A fast site on a phone is often fitter, and easier for staff to maintain, than an app-store listing.

Do you integrate WhatsApp?

Sometimes, as an intake channel, not as the database. Conversation may start in chat; the official record must not live only in chat.

What should you read next?

Read the matching filter, tool or policy next — not a dump of every URL. Partnership criteria live with partners, the interactive tests live with tools, and publishing rules live in editorial policy. Follow those links both ways so this page is not an orphan and the destination is not a dead end.

Request a partnership