A public SaaS export demo should finish with someone using the exported information outside your app. Show the selected records, explain what the file includes, and ask a reader to complete a small task from it. A successful download is one checkpoint; it doesn't show that the exported information keeps its meaning.
This is a useful build-in-public topic because the result can be inspected. Instead of announcing that export support has shipped, share a safe sample and a specific question about what a person can understand from it. Keep the example separate from customer data and avoid presenting one file as proof that every export works.
Define the outside task before recording the demo
Choose a task that explains why the file exists. In a fictional maintenance-log SaaS, a workshop manager wants to review completed repairs for a selected month without opening the original app. That task requires more than a list of record identifiers.
Write a short acceptance note: the reader should identify each completed repair, understand its completion date, and connect it to the correct sample machine. The example doesn't need billing, contact information or internal staff comments. Name those exclusions before the walkthrough so the missing fields don't look accidental.
This is a demonstration plan, not a claim about a real product. The task, records and observations in this article are hypothetical. Apply the method to your own product only after checking what its current exporter actually does.
Build a sample that can reveal a mismatch
Use invented records with a small known set of expected results. Give two machines clearly different names. Include a completed repair, an unfinished repair, and a repair outside the selected month. Add a note with punctuation that someone would reasonably enter.
The point is not to create a spectacular edge-case collection. It is to make the selection boundary visible. If the filter says completed repairs in April, you should be able to explain why each included row belongs and why the other rows don't.
Keep a private expected-record list before you export. Otherwise, you may look at the file and accept whatever it contains because you no longer remember the starting state. Record identifiers can help compare the app and the file, but they don't replace readable descriptions.
State what one row represents
An export needs a clear unit. Does one row represent a repair, a machine, or an individual maintenance action? A reader cannot safely count repairs when one repair can occupy several rows and the file doesn't explain that relationship.
For the fictional demo, choose one row per repair. Include a stable repair identifier, a machine identifier, a readable machine name, a repair description, status and completion date. Explain whether an empty completion date means unfinished, unknown or unavailable. Don't leave the reader to infer that meaning from a blank cell.
A short accompanying field note can do this work. Keep the note close to the file and version it with the sample. If you later rename a field, an older public file should still be understandable from the explanation that accompanied it.
Check the file format without confusing it with correctness
For CSV, RFC 4180 documents common formatting conventions, including consistent field counts and quoting fields containing commas, line breaks or double quotes. It is an informational RFC, not a guarantee that every spreadsheet interprets every value the same way.
Use those conventions as one part of the inspection. Check a description containing a comma, a quoted phrase and a line break. Confirm that the description stays in the intended field when the file is read. A visually neat table can still hide a shifted column if you only inspect the easiest row.
Then return to meaning. Correct CSV quoting won't tell you whether the right repair was exported, whether a displayed date has the intended meaning, or whether a status code is understandable. Formatting and product correctness need separate notes.
Show the selection before showing the download
Record the product state that determines the export: selected dates, status filter, scope and any relevant options. Use your safe sample account. Explain whether the export follows the visible selection or uses another rule.
In the hypothetical walkthrough, the founder selects April and completed repairs, then exports. The expected-record list says which repair should appear. The recording follows that record into the file and checks that the unfinished repair is absent.
Don't crop out the selection just to make the download button larger. Readers need the starting context to evaluate the result. If a screen contains material you cannot safely share, recreate the task in a deliberately prepared sample environment rather than trying to hide a live customer workspace during recording.
Ask a peer to read the file without narrating the answer
Give a reviewer the safe file, its field note and the outside task. Ask them to identify which machine had the completed repair and when it was completed. Let them explain where they found the answer.
If you guide them to every column, you are checking whether they can follow your directions. You are learning less about whether the file stands on its own. Save explanations until after their first attempt, then note which missing context required help.
Buildside describes its community as a place for SaaS founders to share work and seek help with concrete problems. It is built and run by Uriel Bitton, this article's publisher. An export sample gives a relevant peer something specific to inspect. It doesn't make that peer representative of your customers or turn a review into a security assessment.
Keep a mismatch note that leads to an action
Write down expected behavior, observed behavior and the smallest useful follow-up. For example: the reader should identify the machine; the file contains only an internal code; add a readable machine name beside the identifier and repeat the task.
Another hypothetical mismatch might involve the date field. The reviewer interprets it as the date the repair was reported, while the exporter intended completion. Renaming a vague date column and documenting its meaning is a more direct response than adding a general help paragraph about exports.
If the sample passes, say exactly what passed. The reader completed this task with this file and these instructions. Don't extend that statement to other time zones, large exports, permissions, attachments, restore behavior or every destination tool. Those require their own checks.
Publish the learning and preserve the sample's limits
A useful public update can show the initial selection, the safe file, one mismatch and the revised field explanation. State the sample size plainly and identify any manual steps. If you haven't tested a second reader or a different file, leave that boundary visible.
The next public artifact should answer the same outside task after the change. Keep the original question and the result together so readers can see why the revision matters. A screenshot of a download success message doesn't explain that reasoning.
You should also decide who will keep the shared sample current. When the real exporter changes, an outdated example can send readers toward behavior that no longer exists. Add a dated note or replace the sample with a clearly identified revision. The purpose of building in public is useful inspection of the work, and that depends on readers knowing which work they are seeing.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
Top comments (0)