Om Obsidian-vaultsjablonen te verkopen, verpak je een schone vault met je eigen notities, werkende links, benodigde bijlagen en duidelijke openingsinstructies. Laat privénotities en onnodige instellingen weg. De koper moet met het ZIP-bestand kunnen beginnen zonder een onverklaarde verzameling communityplug-ins te hoeven vertrouwen.
Deze gids is voor makers die systemen voor onderzoek, schrijven of projectplanning verkopen. De releasechecklist hieronder verbindt een overdraagbare vault met de bestandslevering van PayRequest. Het is een controle die je op je eigen product uitvoert; we beweren niet dat we jouw vault hebben geopend of getest.
Bepaal Welk Obsidian-vaultsjabloon Je Verkoopt
Kies één herkenbaar resultaat, zoals interviewonderzoek ordenen of een boekenreeks plannen. Toon een voorbeeldproject met fictieve inhoud, zodat kopers zien hoe notities samenhangen. Alleen een mappenstructuur verklaart zelden waarom iemand voor je systeem zou betalen.
Maak onderscheid tussen één herbruikbare notitie en een complete vault. De vaultdocumentatie van Obsidian beschrijft een vault als een lokale map met notities, bijlagen en configuratie. Een volledig sjabloon kan meerdere soorten notities bevatten, met een startpagina die de koper wegwijs maakt.
Vermeld wat de aankoop omvat: bestanden, instructies, licentievoorwaarden en eventuele afgebakende ondersteuning of updates. De koper verkrijgt Obsidian afzonderlijk. Suggereer niet dat Obsidian Sync, een extern abonnement of officiële goedkeuring is inbegrepen.
Een Notion-sjabloon wordt doorgaans via een online duplicatielink geleverd. Een Obsidian-koper ontvangt lokale bestanden. Leg dus vóór het afrekenen uit waar de koper ze uitpakt en welke map die opent.
Maak een Releasekopie in Plaats van Je Werkvault te Zippen
Begin met een afzonderlijke releasemap. Kopieer alleen de notities en bestanden die nodig zijn voor de demonstratie. Vervang klantnamen, vergadergegevens, ongepubliceerd onderzoek en persoonlijke opmerkingen door fictieve voorbeelden. Controleer zowel inhoud als bestandsnamen: een onschuldig ogend sjabloon kan nog een echt e-mailadres of een privélink bevatten.
Controleer bijlagen apart. Een notitie kan verwijzen naar een afbeelding of PDF elders op je computer. Voeg alleen bestanden toe die je mag verspreiden en verwijder afhankelijkheden van privélinks in de cloud. Essentieel referentiemateriaal mag geen toegang tot jouw persoonlijke account vereisen.
Beslis bewust over de configuratiemap. Obsidian bewaart vaultinstellingen in de verborgen map .obsidian. De documentatie over gegevensopslag legt het verschil tussen notities en instellingen uit. Ga er niet van uit dat je bestandsbeheerder standaard alle inhoud van het archief laat zien.
Voor een eenvoudig notitiesysteem adviseren we eigen inhoud te leveren en de weinige benodigde instellingen uit te leggen. Zijn vooraf ingestelde opties essentieel, maak die dan bewust in de releasekopie en controleer ze. Lever niet je werkconfiguratie mee om één alinea uitleg te besparen.
Maak Plug-invereisten Duidelijk Vóór de Aankoop
Een vault met verplichte communityplug-ins vraagt andere ondersteuning dan een systeem dat met kernfuncties werkt. Vermeld per vereiste plug-in het doel, de gecontroleerde versie en wat zonder die plug-in niet werkt. Houd optionele vormgeving apart van essentiële functies.
De beveiligingsrichtlijnen voor plug-ins van Obsidian leggen uit dat de beperkte modus communityplug-ins standaard niet uitvoert. Uitschakelen is een vertrouwensbeslissing. Begin de instructies van een betaald product dus niet met “schakel alles in” zonder uit te leggen wat er wordt uitgevoerd en waarom.
Verwijs bij een eenvoudige release naar de officiële installatieroute van de plug-in, in plaats van externe code of andermans instellingen te bundelen. Controleer de licentie van materiaal van derden afzonderlijk. Jouw notitielicentie geeft geen rechten op een plug-in, thema of afbeelding van een andere maker.
Bied waar mogelijk een route met alleen kernfuncties, zolang die het beloofde resultaat oplevert. Gewone gekoppelde projectnotities kunnen bijvoorbeeld bruikbaar blijven zonder dynamisch dashboard. Is dat dashboard juist de kern van het product, wees daar dan duidelijk over en presenteer de terugvaloptie niet als gelijkwaardig.
Gebruik Deze Releasechecklist voor Obsidian-vaults
Maak voor iedere verkoopbare versie een eigen controlerecord. Dit originele acceptatiesjabloon bevat voorbeeldwaarden voor een fictieve onderzoeksvault. Vervang ze door waarnemingen uit jouw release; een vinkje zonder controle is geen bewijs.
| Releasecontrole | Voorbeeldrecord | Acceptatievoorwaarde |
|---|---|---|
| Productidentiteit | Research-vault-1.0.zip | Aanbod en archief verwijzen naar dezelfde versie |
| Startpunt | Start Here.md | Koper vindt direct de eerste taak |
| Demonstratie-inhoud | Fictief interviewproject | Geen privéinterviews, klantgegevens of inloggegevens |
| Links en bijlagen | Vijf voorbeeldnotities en twee eigen afbeeldingen | Iedere beloofde lokale verwijzing opent vanuit de uitgepakte kopie |
| Afhankelijkheden | Alleen kernfuncties | Geen onvermelde plug-in nodig voor de beloofde werkwijze |
| Configuratie | Bewust voorbereide instellingen, of geen | Verborgen bestanden gecontroleerd en keuze vastgelegd |
| Compatibiliteit | Daadwerkelijk gecontroleerde appversie en besturingssysteem | Niet-gecontroleerde platforms duidelijk vermeld |
| Licentie en ondersteuning | Meegeleverde tekst met contactroute | Koper begrijpt gebruiksrechten en kan de versie doorgeven |
Pak het definitieve ZIP-bestand uit op een andere locatie en gebruik in Obsidian de optie “Open folder as vault”. Open de map met de notities, niet het ongeopende archief of een extra buitenmap. Doorloop de eerste taak, volg de voorbeeldlinks en maak met ieder aangeboden sjabloon een nieuwe notitie.
Leg resultaten en correcties vast. Herhaal de controle na wijzigingen in afhankelijkheden of bijlagen. De algemene releasediscipline lijkt op die voor Scrivener-sjablonen, maar bij Obsidian staan lokale links, verborgen configuratie en vertrouwen in plug-ins centraal.
Lever de Vault via PayRequest en Ondersteun de Juiste Stap
Gebruik digitale producten van PayRequest om het releasearchief te verkopen. In de op 12 september 2026 gecontroleerde bestandsservice is ZIP toegestaan; losse Markdown-bestanden staan niet op de lijst voor directe uploads. Een archief behoudt de mappenstructuur en geeft je één productbestand om te leveren.
De bestandslevering van PayRequest onderscheidt het openen van de downloadpagina van de daadwerkelijke downloadactie. De huidige controller controleert vervaldatum en downloadlimieten; alleen de pagina openen verbruikt geen download. Dit beschermt tegen gewone linkvoorbeelden, maar controleert de vaultinhoud niet en voorkomt niet dat een koper ontvangen bestanden kopieert.
Verdeel ondersteuning in drie stappen: toegang tot de download, uitpakken van de ZIP en openen of gebruiken van de vault. Vraag naar de releasenaam, appversie en mislukte stap. Vraag niet om de volledige persoonlijke vault als een klein voorbeeld of foutbeschrijving volstaat.
Beschrijf het updatebeleid nauwkeurig. Een vervangend archief leveren is iets anders dan wijzigingen automatisch samenvoegen met aangepaste kopersnotities. Adviseer eerst een back-up te maken en vermeld welke bestanden zijn veranderd. Beloof geen migratiesysteem dat je niet hebt gebouwd.
Bereid je gecontroleerde release voor en maak het aanbod met digitale producten van PayRequest. Bekijk de tarieven bij het bepalen van je marge: het Free-abonnement heeft geen maandbedrag en rekent 2% per geslaagde betaling, maximaal €25 per transactie. Kosten van de betaalprovider komen daar afzonderlijk bij.
Redactionele toelichting: AI hielp bij dit artikel en de illustratieve cover. Het upload- en downloadgedrag van PayRequest is in de code gecontroleerd. De releasechecklist is een origineel hulpmiddel; er wordt geen Obsidian-compatibiliteitstest of klantresultaat geclaimd.