A useful CSV import preview shows which source columns map to which fields, which rows need attention, and what will change after confirmation. When you share the feature while building in public, demonstrate those boundaries with a fictional file. A successful upload alone does not tell a reader whether records have been created, updated, skipped, or left untouched.
For a small SaaS team, the public demonstration can serve two purposes. It explains the feature to prospective users, and it gives developers and founder peers a concrete workflow to question. The most useful feedback concerns the decisions a user must make before committing data.
You do not need a large demo database to expose those decisions. A small disposable example with a few carefully chosen rows is easier to inspect. The aim is to make the importer understandable, including what it does when the file is imperfect.
Define the import task before the preview screen
Start with a narrow task. In the fictional example used throughout this article, a founder is building a workshop-planning tool. The user wants to import a participant list into one draft workshop. The import must not send invitations, charge anyone, or change another workshop.
That task description gives the preview a boundary. “Import contacts” could imply a global address book. “Add participants to this draft workshop” tells a reviewer what to inspect. State the destination in the demo before selecting the file so the audience can judge later screens against it.
Use invented names and safe example values. Include an ordinary new row, a row matching a participant already in the demo, and a row missing a required value. Label the dataset fictional in the public post. None of these records should resemble a real customer's exported list.
Write down the question you want the demo to answer. For example: can a first-time reviewer predict which participants will appear in the draft workshop? That is more specific than asking whether the importer looks clean, and it produces feedback you can act on.
Separate parsing from business validation
The file has to be read before its contents can be judged. RFC 4180 documents a common CSV format, including optional headers and quoting rules for fields containing commas, line breaks, or quotes. It is an informational memo, not a complete specification for your application's import behavior.
A parser understanding a row does not make the row suitable for the workshop. The application still needs to decide whether a required email is present, how a date is interpreted, and what counts as the same participant. Those are separate product rules that the preview should make visible.
In the fictional file, an organization name might contain a comma inside quotes. That belongs in a parsing example. A participant without the required contact value belongs in a validation example. Showing both makes it harder to confuse a file-format problem with an application rule.
Avoid presenting a list of supported edge cases that the current importer has not passed. If the demonstration is a prototype, say so. A public explanation of intended behavior is useful, but it should not become a claim that every implementation detail is already reliable.
Show the mapping as a decision
Use source headings a reader might actually encounter. The fictional file might call a column “Attendee” while the product field is “Participant name.” The preview should show the relationship clearly enough that a person can correct it before continuing.
If the application guesses a mapping, distinguish the guess from a confirmed choice. A confident-looking arrow can conceal a bad assumption. In the public walkthrough, deliberately inspect one suggested mapping and explain why it is appropriate for this dataset.
Also show what happens to an unused column. A reviewer should not have to infer whether it is ignored, stored somewhere else, or blocking the import. The right choice depends on your product, but an unexplained column creates an avoidable gap in the demo.
Ask a peer to explain the mapping back without your narration. If they cannot tell which value becomes the participant name, polishing the success animation will not resolve the issue. Improve the field labels or sample values first, then run the same task again.
Explain each row's proposed effect
The preview needs more than a green success state. For this fictional workflow, give every row a proposed effect: add a participant, update an existing draft participant, skip an unchanged match, or block the row until the required value is supplied. These labels are design suggestions, not universal import rules.
Define the matching rule alongside the preview. If this example matches participants by email within the selected workshop, show that scope. Two rows with the same name should not silently demonstrate the same rule as two rows with the same email.
Include one visible before-and-after comparison for the matching row. Suppose the demo already contains a participant with a blank organization field. The file supplies an organization. A reviewer should be able to see whether that value will be added and whether other fields remain as they were.
For the blocked row, explain what the person can do next. They might fix the file and upload it again, edit a supported value in the preview, or exclude that row. Only show options the current product actually supports. An unavailable recovery path does not become real because the mockup looks plausible.
Make the final commit boundary unmistakable
Before confirmation, say whether the preview has changed the destination. In this example, previewing creates no participants. The final action commits the approved rows to the draft workshop. That separation should be visible in the interface as well as in the public explanation.
Choose an explicit policy for mixed valid and invalid rows. The example could block the whole batch, or permit only the valid rows after clear confirmation. Either way, explain what the user is authorizing. Do not let a generic “Continue” carry an undisclosed decision about partial imports.
After committing, show the resulting workshop list and compare it with the preview. If the demo says a row will be skipped, verify it was skipped. A completion banner confirms that an action finished; the destination is where the reader can check what actually changed.
Then demonstrate a second attempt using the same fictional file. This is a useful review question even before you have a sophisticated retry system: would the same action create duplicates, update matches, or refuse the request? Document the observed behavior rather than assuming repetition is harmless.
Turn the public demo into a focused review
Share a short sequence containing the destination, the file headings, the mapping, the row effects, and the final result. A founder community can examine that sequence without needing access to your private repository or production data. Keep the review surface small enough to finish in one sitting.
Buildside is a relevant place to share the progress and the question behind this work. Ask founder peers whether the preview gives them enough information to approve the import. If you want feedback from people who routinely move workshop lists, say that rather than treating every reaction as equivalent.
Separate three kinds of response in your notes. A developer may spot an untested parsing case. A relevant user may misunderstand the destination. A founder may suggest a different launch story. All can be useful, but they answer different questions about the feature.
Record what changed after the review and what remains untested. If a clearer label helped one reviewer predict the row effects, describe that observation at its actual scope. It is evidence from that review, not proof that the importer is ready for every dataset.
Publish the next check with the improvement
A useful build-in-public update can end with one unresolved task. Perhaps the matching rule is clear, but the recovery message after a failed commit needs work. Name that gap and show the state a reviewer would see. This gives the next conversation a concrete starting point.
Keep the fictional file with the demo notes so you can compare later versions using the same task. Change it deliberately when a new question requires a new case. If every video uses a different dataset, it becomes harder to tell whether the explanation improved.
An import preview earns confidence by making its consequences inspectable. Show what the file says, what the application proposes, and what confirmation actually changes. That gives early users a clearer decision and gives your founder peers a better way to help you build.
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.
