The CSV imports perfectly. Then someone asks, “What happens if it stops halfway through?”
That is where this hypothetical demo gets interesting.
The tool reads a sample file, maps the columns, and saves the expected records. Its local checks pass. There is something real to build on: those cases worked in that environment.
But if the next person has to open the database to find out which rows were saved, handing over the tool also means handing over a problem.
A prototype can become the software behind a product. The harder question is what someone can reasonably depend on it to do.
Ready for what?
For this importer, the first offer could be modest: one person, one approved file format, and a preview before anything is saved. Rejected rows should be understandable. After an interruption, the person using it should be able to tell what happened and how to recover.
That is a more useful starting point than “ready for production.” It gives you something specific to investigate without committing to every spreadsheet anyone might upload.
It also changes what deserves attention next. Another supported format might be useful eventually. If an interrupted import can leave someone guessing whether a retry will create duplicates, recovery deserves attention now.
Let someone else try it
Suppose you want to find out whether the intended user can handle an import without you explaining every error.
Give them synthetic files: one valid, one with a row the tool should reject, and one for an import you deliberately interrupt. Decide beforehand what you need to see. In this case, you might want them to identify which records were saved and choose a safe next action without your help.
Then watch where they get stuck.
If they need you to translate a rejection message, you have a concrete reason to improve it. If neither of you can tell what was saved after the interruption, the problem goes deeper than wording.
And if they get through the tasks, you have learned something useful: this person could complete this workflow under the conditions you recorded. Keep the files, software version, and notes about any help you gave them. Those details make the result understandable later.
You do not need to turn that result into a claim about every user or every file for it to matter.
Getting through it is only part of the story
The importer might work exactly as intended and still offer little benefit over the person's existing workflow.
Ask what they would otherwise do with the file. Where does the rework happen? Would the importer remove it, or move it somewhere else?
“This would save me time” is useful feedback. It is also an expectation. To make a claim about time saved, you would need to compare the workflows and account for differences such as file complexity, manual cleanup, and help from you.
A short note can preserve that distinction: what you observed, what the person reported, and what you still need to find out. Then write down what you will change or test next.
That is enough structure to keep a promising conversation from becoming a success story you have not earned yet.
Someone has to own the bad day
Before someone relies on the importer for actual work, there are less visible questions to settle. Who helps when it fails? How do they find and correct affected records? When should they stop using it?
If it handles real data, you also need to decide what gets stored, who can access it, and when it gets deleted. Importing disposable personal notes and writing customer records carry different consequences. The promise should reflect that.
The prototype does not become less valuable because these questions remain. It has given you a way to investigate them.
Before adding the next feature, try finishing this sentence:
It works for ___. Before someone depends on it for ___, I need to find out ___.
For the importer, that final blank might be whether someone can recover from an interruption without making the data worse.
What belongs in the blank for yours?
Disclosure: AI helped draft and structure this article. The importer and trial are hypothetical; no technical or customer results are reported.
Top comments (0)