Chapter 8: Packaging and Marketplace Submission — Sharing Your Domain with the World
"You built something that solves a real problem for real people in a specific industry. This chapter is about getting it into their hands."
The Last Mile
Every chapter in this book has been about building — designing, coding, writing, testing. This chapter is about releasing. It is the last mile between the domain on your development machine and the domain in the hands of the attorneys, co-op administrators, property managers, HR professionals, and nonprofit coordinators who need exactly what you built.
The last mile requires a different kind of attention than the build phases. Building rewards depth — the more carefully you think through each decision, the better the domain becomes. Releasing rewards clarity — the more clearly you present what you built and who it is for, the more people will find it, understand it, and use it.
This chapter covers four things: finalizing your release package, writing your marketplace listing, submitting for verification, and the lifecycle of a published domain — updates, versioning, responding to user feedback, and building a sustainable business around what you have created.
By the end of this chapter, your domain will be live. Real people will be using it. And you will understand how to keep it growing.
Part One: Finalizing the Release Package
The Pre-Submission Pass
Before you create your submission package, do one final pass through every file in your domain folder. Not a deep review — you completed that in Chapter 7. This is a surface pass that catches the last category of problems: the ones so obvious that you stopped seeing them weeks ago.
The domain-config.json final check
Open domain-config.json and read the top section — domain ID, name, description, category, version — as if you are reading it for the first time. Is the description accurate? Is it written for a buyer browsing the marketplace, not for you who built it? Is the version number set to 1.0.0? Is the category correct?
Then scan the documentTypes array. Read every template name and description. Are there any you copied from SchoolCoop and forgot to update? Any descriptions that reference homeschool co-ops in a legal services domain? These embarrassments are caught by a fresh read and missed by a tired one.
The CSV files final check
Open each CSV file and scan the first three records. Are there any test records you added during edge case testing that should not be in the published version? Any records named "Test Client 1" or "Edge Case Matter"? Any placeholder data that crept in during development?
The sample data in your published domain is permanent marketing material. It needs to be as clean and professional as the document templates it generates.
The README final check
Read the README Quick Start from start to finish, following each step literally as if you have never loaded the domain before. Does each step produce exactly the result described? Are the specific record references — the matter numbers, the invoice IDs, the firm names — consistent with what is actually in your CSV files?
Read the Troubleshooting section. Are the solutions accurate for the current version of the domain? Have any of the issues described been resolved by changes you made during development, making the troubleshooting entry outdated?
The word-templates final check
Open three generated templates at random in Word. Confirm the letterhead renders correctly. Confirm there are no unreplaced placeholders visible. Confirm the page numbers appear in the footer. Confirm the document looks like something a professional would be proud to send.
If any of these checks reveals a problem, fix it, regenerate if necessary, and run the check again before proceeding.
Cleaning the Generator Script
Your generator script has been through development iterations. Before publishing, clean it up.
Remove any commented-out code blocks from failed experiments. Remove any debug console.log statements that were useful during development but add noise to the published script. Update the header comment at the top of the file to reflect the final domain version:
/**
* Legal Services Domain — Template Generator
* Data Publisher for Word
*
* Version: 1.0.0
* Generated templates: 20
* Tables referenced: 10
*
* Usage: node scripts/generate-legal-services-templates.js
*
* This script programmatically generates all 20 Word templates for the
* Legal Services domain. To modify any template, edit the corresponding
* function in this file and re-run the script.
*
* Part of the Data Publisher Domain Template ecosystem.
* https://datapublisher.app
*/
A clean, well-commented generator script is a professional artifact. It signals to anyone who downloads and studies your domain that you built it with care and that it is safe to build on.
Creating the Release Package
Your release package is a compressed archive of the complete domain folder. The folder name should match your domain ID exactly:
legal-services/
Not legal-services-v1, not LegalServices, not legal_services. The folder name becomes the domain ID that the platform uses internally. Inconsistency here causes loading failures.
Compress it:
# macOS / Linux
zip -r legal-services-1.0.0.zip legal-services/
# Windows (PowerShell)
Compress-Archive -Path legal-services -DestinationPath legal-services-1.0.0.zip
Include the version number in the archive filename. When you release version 1.1.0 next month, you want to be able to distinguish the archives. The domain folder inside the archive keeps its clean name — only the archive filename carries the version number.
Before submitting, verify the archive contents:
# macOS / Linux
unzip -l legal-services-1.0.0.zip
# Windows (PowerShell)
Expand-Archive -Path legal-services-1.0.0.zip -DestinationPath ./verify-contents
Confirm the unzipped structure matches the required folder layout from Chapter 1. Every required file should be present. No extra files, no hidden system files (.DS_Store on macOS, Thumbs.db on Windows), no development artifacts.
Part Two: Writing Your Marketplace Listing
The marketplace listing is separate from the README. The README lives inside your domain package and serves users who have already downloaded it. The marketplace listing lives on the platform and serves potential buyers who are deciding whether to download at all.
Think of the README as the user manual. Think of the marketplace listing as the back of the box.
The Five Elements of a Marketplace Listing
Element 1: The Headline Ten words or fewer. Describes the domain, names the target user, implies the value.
Good: "Complete Document Automation for Law Firms of All Sizes" Too generic: "Legal Document Templates" Too technical: "Relational CSV Domain Package for Legal Services Workflows"
The headline appears in search results and category listings alongside every other domain in the marketplace. It must distinguish your domain immediately and specifically.
Element 2: The Short Description Two to three sentences. Expands the headline into a value proposition. Written for a buyer who is scanning, not reading.
The Legal Services domain automates the 20 documents that law firms generate
most often — from engagement letters and client invoices to hearing preparation
sheets and deadline calendars. Connect your firm's data once and generate any
document in seconds, branded to your firm and addressed to your client.
Built for solo practitioners to mid-size general practices. No template design
required. No configuration. Just your data, and the professional documents
it should be producing automatically.
Element 3: The Feature List Five to eight bullet points covering what makes this domain valuable and distinctive. These are scanned, not read — keep each point to one line.
• 20 professional templates across 5 practice categories
• Handles 3 billing types: Hourly, Flat Fee, and Contingency automatically
• Individual and entity client support — letters address correctly for both
• Court preparation documents: Hearing Prep Sheets, Deposition Outlines, Checklists
• Complete financial tracking: Invoices, Payment Receipts, Monthly Billing Summary
• Full schema reference and OAuth2 data sources integration guide included
• Generator script included — fork, customize, and publish your own version
• OAuth2-secured live connections: Google Sheets, Microsoft Excel Online, SQL Server
Element 4: The Target User Statement One sentence. Names who this domain is for with enough specificity that the right people recognize themselves and the wrong people understand it is not for them.
Ideal for law firm administrators, paralegals, and attorneys at solo
practices and general practice firms who need professional document output
without custom template development.
Element 5: The Screenshot / Demo Every marketplace listing should include at least one screenshot of a generated document. The Engagement Letter is the recommended showcase — it demonstrates letterhead, professional formatting, and multi-table data resolution in a single image.
If your platform listing allows a short demo video, record a 60-second screencast: load the domain, select the Invoice template, choose a matter, click Run, and let the viewer watch a professional invoice appear. Sixty seconds of demonstration is worth a thousand words of description.
Pricing Your Domain
You decide your price. The platform takes nothing from your earnings — your subscribers pay you directly, and you pay the platform's $10/month user fee. This means your pricing decisions are yours alone, guided entirely by the value you provide.
Here is a framework for thinking about pricing:
What is your domain worth to the user? A legal services domain that saves a paralegal two hours of document creation per week saves approximately 100 hours per year. At a paralegal billing rate of $65 per hour, that is $6,500 in recovered time annually. A domain priced at $299 per year delivers a 20x return on investment. That is an easy purchase decision.
Work through this math for your domain. What time does it save? What is that time worth to the user? Price at a fraction of the value delivered — not at what it cost you to build, but at what it is worth to the person using it.
Pricing tiers to consider:
Free / Open Source — You want maximum adoption and community engagement more than revenue. This is appropriate for the SchoolCoop vanilla domain, which serves as the platform's reference implementation and community foundation. Free domains build your reputation and generate forks that credit your original work.
One-time purchase ($49–$149) — Lower barrier to entry, no ongoing commitment. Appropriate for domains that are relatively stable and do not require regular updates. The buyer owns it once and uses it indefinitely.
Annual subscription ($99–$499/year) — Ongoing revenue in exchange for ongoing value: new templates added over time, updates when the underlying platform evolves, responsive support when users have questions. The subscription model is appropriate when you intend to maintain and improve the domain actively.
Tiered pricing — A free tier with 5 templates, a paid tier with all 20. This is a powerful acquisition model — users experience real value before committing to purchase, and the free tier drives word-of-mouth among the community.
The legal services domain at $249/year is conservative and defensible — less than $21/month for a tool that saves hours of attorney and paralegal time every week. At that price, a single satisfied subscriber refers two colleagues, and those referrals each generate $249 in annual recurring revenue without any additional sales effort.
Part Three: The Submission and Verification Process
What Verification Checks
When you submit your domain to the marketplace, the platform runs an automated verification process followed by a human review. Understanding what each check looks for helps you pass on first submission.
Automated checks (run immediately on submission):
Structure validation — Confirms the required folder structure is present: domain-config.json, csv-data/ with at least one CSV, word-templates/ with at least one .docx, README.md.
Config validation — Parses domain-config.json and confirms it is valid JSON, contains required top-level fields (domainId, domainName, version, tables, documentTypes), and that every foreign key references a table defined in the same config.
Template count validation — Confirms that the number of .docx files in word-templates/ matches the templateCount in domain-config.json and equals exactly 20.
CSV integrity validation — Loads every CSV file and confirms that primary key columns contain valid integers with no duplicates, that foreign key values reference valid primary keys in the referenced tables, and that date fields conform to ISO format.
Placeholder syntax validation — Scans every .docx file for placeholder syntax and confirms that every <<table.column>> reference names a table and column that exist in the domain's CSV data.
Human review (completed within 48 hours):
README quality check — A human reviewer reads the README and confirms it has a functional Quick Start, documents all 20 templates, explains the data structure, and includes a troubleshooting section. READMEs that are minimal or copied directly from another domain without customization are returned for revision.
Sample data quality check — A reviewer loads the domain and generates three documents from the sample data. Documents must look professional and be clearly realistic — not test data, not placeholder names, not generic content. This is the check that "Test Client 1" fails.
Generator script check — Confirms the generator script is present, is valid JavaScript, and references the correct output directory and template definitions.
Content appropriateness check — Confirms the domain does not contain inappropriate content, does not misrepresent its capabilities, and does not infringe on trademarks or copyrighted material.
Common First-Submission Failures and How to Avoid Them
"Template count mismatch" — Your domain-config.json says 20 templates but your word-templates/ folder contains 19 or 21. This happens when a generator script fails on one template and you did not notice. Fix: count the files in your word-templates/ folder before submitting. ls DataPublisher_DomainTemplates/legal-services/word-templates/*.docx | wc -l should output 20.
"Invalid foreign key reference" — A foreign key in domain-config.json references a table or field that does not exist as specified. Fix: every foreign key definition must exactly match the table name and primary key column name as they appear in both the CSV header and the config.
"Unreplaced placeholders found in templates" — The placeholder validator found << sequences in generated documents that were not recognized as valid field references. Fix: run the Phase 2 placeholder check from Chapter 7 before submitting.
"README does not meet quality standard" — The human reviewer found the README insufficient. The most common reasons: Quick Start is too vague, template descriptions are copied from domain-config.json without expansion, troubleshooting section is absent or minimal. Fix: follow the structure in Chapter 6 exactly.
"Sample data is not realistic" — The human reviewer generated sample documents and found test-flavored data. Fix: replace all test data with realistic records following the guidance in Chapter 4.
After Approval
When your domain passes verification, you receive a notification with your live marketplace URL. Your domain is now discoverable by every Data Publisher user.
Do three things immediately:
First: Generate your own documents with the live version. Download your published domain from the marketplace exactly as a user would. Load it fresh. Follow your own Quick Start. Generate the Engagement Letter, the Invoice, the Hearing Preparation Sheet. Confirm that the experience from the marketplace to the first generated document is exactly what you designed it to be. You will often find small things to improve that only become visible when you approach your own domain as a stranger.
Second: Share it with your professional network. The attorneys, paralegals, legal administrators, and law firm operations professionals in your network are your first potential subscribers. A personal message explaining what you built and who it is for — not a mass marketing blast, but a direct note to specific people who would genuinely benefit — converts more reliably than any advertising.
Third: Monitor your first user experiences. The platform provides basic analytics — downloads, active subscribers, template generation counts. Watch these in the first two weeks. A domain that gets downloads but no repeat template generations signals that users are not getting past the Quick Start. A domain with high generation counts on some templates and zero on others signals that certain templates are not being discovered or are generating unexpected results.
Part Four: The Life of a Published Domain
Publishing is not the end of the story. It is the beginning of a different kind of work — maintaining, improving, and growing a domain that serves a real community of users.
Listening to Users
Users will find problems you did not. They will attempt scenarios your sample data did not cover. They will use your domain in ways you did not anticipate. Some will email you. Some will leave marketplace reviews. Some will say nothing at all and simply stop using the domain.
The ones who contact you are gold. Respond to every one personally, within 24 hours if possible. The question they ask tells you something about your documentation, your template design, or your sample data that you could not have known from building in isolation. Fix the underlying issue, not just their specific problem. Update the README troubleshooting section. Release a patch version.
The ones who leave reviews are public. A one-star review that says "the invoice template shows blank billing entries" is a gift — it tells every potential buyer that you are responsive to problems, and it tells you exactly what to fix. Respond to negative reviews professionally, acknowledge the issue, describe the fix you have made, and invite the reviewer to update their rating after trying the updated version. Nothing signals marketplace credibility more clearly than a domain creator who responds to criticism constructively.
The ones who say nothing are the majority. Watch the analytics. A sudden drop in generations from a template that was previously popular may mean a platform update broke something. A steady increase in generations from a specific template tells you which template is delivering the most value — lean into it in your marketing.
Releasing Updates
Every update to your domain follows the same release cycle you used for the initial release: make the change, run the generator if templates were affected, run the validation checklist from Chapter 7, update the version number in domain-config.json, update the README changelog section, and submit the new package.
Minor updates — fixing a spelling error in a template, adding a new field to a CSV, updating the README troubleshooting section — do not require full revalidation. A patch release (1.0.0 → 1.0.1) can be submitted with a note explaining the specific fix.
Minor feature releases — adding new templates, adding new tables, adding new data fields — require full revalidation. A minor release (1.0.0 → 1.1.0) goes through the complete submission process because new templates and new data fields may introduce new issues that the automated checks need to catch.
Growing the Domain Over Time
The domain you publish on day one is not the domain you will be maintaining a year from now. The best domain creators treat their domains as living products, not finished artifacts.
Add templates based on user requests. Your subscribers know their industry better than you do. When multiple users ask for the same template — "I really need a Settlement Agreement template" — that is a validated request. Add it in version 1.1.0 and announce it to your subscribers.
Add data source integrations as the platform supports them. When Data Publisher adds a new OAuth2 connector — a Clio integration for legal practice management, a QuickBooks integration for financial data, additional Microsoft Graph API capabilities — update your domain's data sources integration guide to document the authorization flow step-by-step. Include screenshots of the new OAuth consent screens. Document the specific scopes requested. Add troubleshooting for common authorization issues. Your subscribers will upgrade their usage from CSV files to live connected data, and their document generation will become more powerful and more accurate. OAuth2-secured live connections are a major competitive advantage — keep your documentation current.
Add vertical specializations. A general legal services domain serves most law firms. A personal injury specialization with medical record templates, treatment summary documents, and expert witness sheets serves personal injury firms better. Build the specialization as a separate domain that extends the general one — your existing subscribers become the target market for the upgrade.
Build the community. The Data Publisher marketplace is not just a distribution mechanism — it is a community of domain creators. The person who builds a legal services domain and the person who builds a healthcare domain are building complementary knowledge. A law firm that serves healthcare clients benefits from both. Connect with other domain creators. Collaborate on cross-domain standards. Refer users between domains that complement each other.
What You Have Built
Step back for a moment before you submit.
You began this book with a design document and a blank CSV file. You now have a production-ready domain package containing ten tables of realistic sample data, twenty professionally formatted document templates, a complete domain configuration, a generator script that can recreate all twenty templates in under thirty seconds, and documentation that guides a complete stranger from download to first generated document in five minutes.
You built this in approximately fifteen hours. Without the patterns, the generator script, and the architecture this book describes, the same domain would have taken fifty to one hundred hours — if it got built at all.
The first organization that downloads your domain and generates their first Engagement Letter, their first Invoice, their first Hearing Preparation Sheet — they get back time. Time that was previously spent on document formatting, data re-entry, and template maintenance. They spend that time on the work that actually requires them: the legal judgment, the client relationship, the strategic thinking. That is the value of what you built. Not the code, not the CSV, not the JSON. The time given back.
Now multiply that by every subscriber. Every law firm that uses your legal services domain. Every homeschool co-op that uses the SchoolCoop domain. Every nonprofit, every real estate office, every HR department that finds a domain in the marketplace built by someone who understood their industry and cared enough to build it well.
That is the platform. That is the marketplace. That is what "be fruitful and multiply" means when applied to document automation and the organizations that depend on it.
The Release Checklist
This is the final checklist. Every item confirmed, and you are ready to submit.
PACKAGE PREPARATION
[ ] domain-config.json reviewed and version set to 1.0.0
[ ] CSV files cleaned of all test and development records
[ ] README Quick Start verified end-to-end
[ ] Generator script cleaned of debug code and header comment updated
[ ] All 20 .docx templates present in word-templates/
[ ] All 20 .json metadata files present in word-templates/
[ ] TEMPLATE_INDEX.json present in word-templates/
[ ] docs/ folder contains SCHEMA_REFERENCE.md and DATA_SOURCES_INTEGRATION.md
[ ] No hidden system files (.DS_Store, Thumbs.db) in the package
[ ] Archive created with domain folder name matching domain ID exactly
[ ] Archive contents verified by unzipping and inspecting
MARKETPLACE LISTING
[ ] Headline written (10 words or fewer, specific to target user)
[ ] Short description written (2-3 sentences, value-proposition focused)
[ ] Feature list written (5-8 bullet points, scan-friendly)
[ ] Target user statement written (1 sentence, specific)
[ ] Screenshot of best generated document prepared
[ ] Pricing decision made and rationale documented
SUBMISSION READINESS
[ ] All Phase 1-5 validation tests from Chapter 7 confirmed PASS
[ ] Beta user test completed successfully
[ ] Generation log shows all 20 templates with status READY
[ ] Known issues documented and either resolved or deferred to v1.1.0
POST-SUBMISSION PLAN
[ ] Personal network outreach message drafted
[ ] Analytics monitoring schedule established (check weekly for first month)
[ ] Support response time commitment established (24 hours recommended)
[ ] Version 1.1.0 feature wishlist started
A Final Word
The Organizational Intelligence Series — all five volumes — exists because of a belief that the organizations doing the most important work in the world should not spend their best hours on document formatting. Homeschool co-ops building communities of learners. Law firms defending people who need defending. Nonprofits serving people who have been overlooked. Healthcare practices caring for people who are sick or frightened. HR teams building workplaces where people can thrive.
Every one of these organizations runs on documents. Every one of them is capable of running those documents better, faster, and with less administrative burden than they currently do. Data Publisher for Word exists to make that possible. The marketplace of domains exists to make it accessible. The 600,000 words of the Organizational Intelligence Series exist to give domain builders the intellectual foundation to build solutions that are not just technically correct but genuinely useful.
You are now one of those builders.
The domain you publish is the beginning. The second domain takes half the time. The third takes half again. The patterns become fluent, the design decisions become instinctive, the testing becomes efficient. At some point you stop thinking of yourself as someone who builds document templates and start thinking of yourself as someone who builds organizational intelligence systems — which is exactly what you are.
The SchoolCoop domain is waiting in the marketplace. Fork it. Study it. Learn from it. Build the next one.
The world has no shortage of industries that deserve better document automation. You have the tools, the patterns, and the knowledge to build it for them.
Go build it.
Volume 5 — Building Intelligent Systems: Building Organizational Knowledge Systems on Data Publisher for Word
Part of the Building Intelligent Systems Series
Volume 1: Domain-Specific Document Automation Volume 2: Organizational Intelligence Platforms Volume 3: Human-System Collaboration Volume 4: The Consultant's Handbook Volume 5: Building Intelligent Systems: Building Organizational Knowledge Systems on Data Publisher for Word
"Be fruitful and multiply."