# Digitising a yayasan: sequence, not apps The order of work for digitising an Indonesian yayasan: domain, email, permissions, then a system. Who should delay custom apps. > Reviewed 2026-08-13. Source: https://kodenirlaba.org/en/guides/digitising-a-yayasan/ [Kode Nirlaba](/en/) / [Guides](/en/guides/) / Digitising a yayasan: sequence, not apps Guides Digitising a yayasan: the right order Updated 2026-08-13 · Kaiser Khan Short answer Reviewed 2026-08-13 How should an Indonesian yayasan start digitising without buying an app first? The order is: organisation domain and email, permissioned folders, one source list, then automation. Custom apps come last, or not at all. Skip this if you want a paid “digital transformation” package. A yayasan without domain email is not ready for custom software. Who should skip this page Not an internship curriculum, not a Workspace sales pitch, not a promise that digitising will raise donations. Which first step is skipped most often? Email on the organisation domain. Many yayasans still use the chair’s personal address. When the chair changes, the archive vanishes. Buying an app before organisation email is moving the mess somewhere more expensive. A domain and two board backup accounts matter more than a logo in a system header. If money is tight, this is still step one. Organisation email hosting is cheaper than a custom project, and easier to explain to an accountant. How do you organise folders without becoming a bureaucrat? Three folders are enough: operations, finance, and beneficiary data. Write down who may download. Beneficiary data is not meeting material forwarded into a group. If field staff need to upload photos, give them an intake channel, not full archive access. Consistent file names beat artificial intelligence. “KTP-budi.jpg” in a chat is not a system. When should WhatsApp stay, and when must it stop being the database? Use WhatsApp for human coordination. Stop using it as the beneficiary list, the queue, or the identity archive. Copy status into one permissioned place daily, or design intake that writes to a locked spreadsheet. Chat may be the door; it must not be the warehouse. Forcing field staff off WhatsApp usually fails. Designing a bridge is more humane and more likely to be used. How do you measure whether digitising worked? Not by app count. Measure: how often staff ask “which version is right,” how long a board report takes, and whether a backup person can get in. If those three improve, you succeeded even on a spreadsheet. If you added apps but the same questions remain, you failed with more passwords. Kode Nirlaba uses weekly use, not demos. Digitisation that nobody opens on a Tuesday is not digitisation. When should you ask a technical partner like us? After domain, permissions and one source list exist, and staff still copy data every week. If the basics are missing, we will tell you to finish them yourselves — that is a filter, not cruelty. The eligibility tool uses the same order. Read the custom-versus-ready guide before you fill the form. Many organisations discover they do not need us, and that is a good outcome. What does a thirty-day sequence that actually works look like? Week 1: a domain and two backup accounts. Week 2: three permissioned folders and a “no identity files in chat” rule. Week 3: one source list, fed from WhatsApp, not the other way around. Week 4: measure “which version is right.” If week 4 is still a mess, do not buy an app. Repeat the folders and the list. The sequence is deliberately boring. Dramatic digitising is usually a pile of new passwords. A board that finishes these four weeks has already beaten many paid “transformation” projects. An independent person uses the same order with one human backup — a sibling, a colleague, a volunteer — who can get in if you are ill. Without a backup, any system is an archive that will vanish. Which failed digitising pattern do you decline most often? Buying three apps before domain email exists. Forcing field staff off WhatsApp in a week. Storing ID cards in a new tool with no download permissions. Measuring success by logos on a slide. We will refuse to build on top of that pattern, including for individuals. That refusal is cheaper than a system nobody opens on a Tuesday. If your slide already promises “AI for the yayasan” before a permissioned folder exists, pull the promise back. Artificial intelligence does not replace permissions and a backup. The eligibility tool uses the same order. If you land on “finish the basics,” that is not an insult. It is the thirty-day map above. 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. Is digitising mandatory for a yayasan? Not according to us. Yayasan legal duties live in yayasan law, not in software taste. We do not invent new duties. What should you read next? Continue with another decision guide, then the matching interactive tool, then apply only if the filter still passes. Do not send beneficiary data with the form. If a free tool already fits, stop here — that is a successful reading of this guide. - [Custom vs off-the-shelf for nonprofits](/en/guides/custom-vs-off-the-shelf/)- [Indonesia PDP law for NGOs](/en/guides/pdp-law-for-ngos/)- [Partner or volunteer: who should apply](/en/guides/partner-or-volunteer/) - [Custom or ready tool](/en/tools/custom-or-ready/) - [Partnership check](/en/tools/partnership-check/) - [Request a partnership](/en/contact/)