Duplicate form submission testing should check the result your SaaS saves, as well as the behavior of its submit button. Repeat the same intended action through a double click, an Enter keypress and an uncertain retry. Then inspect whether the product created the expected single result and explained its status accurately.
When you build in public, this makes a useful demo question. A peer can assess whether a task remains understandable when the first response is slow or missing. A polished recording of one successful click leaves that part of the product unexamined.
The walkthrough below uses a fictional project-creation form with disposable sample data. It describes a test you can adapt, not a test of Buildside or Uriel's products. Keep the exercise inside an environment and account you are authorized to use, where repeated actions cannot trigger real messages, charges or other external effects.
Define one intended operation
Start by writing down what one submission means. In the fictional app, the user enters a project name, selects a sample template and chooses Create project. The expected result is one new project containing the template's starter items.
The name alone is not enough to identify the result. Two legitimate projects might have the same name. For a controlled rehearsal, record a test marker and inspect whatever stable project identifier the product exposes through its supported test tools or interface.
Also define the end of the task. A toast saying that creation started is different from a saved project the user can reopen. Your test should establish whether the project exists, whether its initial content is present and whether the interface takes the user to that same result.
Record the starting state before trying to break it
Use a clean sample workspace and note the projects already present. Fix the account role, template and input values for the first comparison. If these change between attempts, you may end up explaining a different issue.
Write down the version and environment being tested. If the demo runs a development build with a mocked response, say so. A successful local rehearsal is useful evidence about that setup; it does not establish production behavior under every condition.
For the fictional form, begin with a normal single submission. Open the resulting project and confirm its starter items. This baseline lets you distinguish duplicate creation from a separate template-copying problem. Reset the disposable workspace between scenarios using the product's supported cleanup process, keeping enough notes to understand each result.
Test a second action while the first is pending
Add a controlled delay in an authorized test environment if your tools support it, or use the available testing conditions to make the pending state inspectable. Do not disrupt a shared live system just to produce a dramatic recording.
Try a quick double click on Create project. In a separate scenario, press Enter after clicking while the first request is still pending. Record what the interface shows and whether either input path remains available.
A disabled button can reduce repeated interaction through that button. It does not, by itself, prove that every request path handles repeats safely. The useful observation is the resulting project count and identity, together with the request behavior your authorized test tools expose. Keep attempted actions, submitted requests and saved projects as separate entries in the record.
Separate idempotency from a visual loading state
MDN defines idempotency in terms of the intended server effect of repeated identical requests. It also explains that POST is not guaranteed to be idempotent. The label on an HTTP method does not prove how a particular application handles its operation.
For the fictional form, the implementation question is how repeated attempts belonging to one intended creation are recognized and handled. This article does not prescribe a complete server design. Check your framework, API and storage behavior against the operation you actually need to protect.
The public demo can still be specific. State that you tested repeated activation during the pending state and checked the saved result. Avoid upgrading that observation into a claim that duplicates are impossible. Different clients, concurrent requests or later retries may require additional tests beyond the flow shown.
Rehearse an uncertain response after creation
A harder scenario occurs when creation succeeds but the user does not receive a clear response. The person may see an error and reasonably try again. Treat this as a different exercise from two quick clicks before the first request completes.
In an authorized test setup, arrange the supported condition that produces an uncertain result. Record whether the first operation actually completed. Then follow the recovery route the interface offers, using the same intended project creation.
The product should help the user discover the existing result or understand what remains unknown. If the retry creates another project, document the exact sequence and the two identifiers. If it returns the existing project, check that the content and navigation refer to that project. Two success messages can still conceal two saved results; one error message can conceal a successful first operation.
Distinguish an accidental repeat from a new request
A duplicate-prevention mechanism can create another problem if it blocks an intentional second project. After the first task is complete, the user may need a similar project for another client or another week.
Include that case in the fictional rehearsal. Complete the first creation, return to the form through the supported route and deliberately create a second project. Explain what makes this a new operation, rather than replaying an uncertain first attempt.
Do not assume that matching text always means duplicate intent. A name, timestamp or identical payload can be a useful test clue without being a universal identity rule. The public lesson should be about the boundary your product implements and the cases you checked, including any legitimate repeat that remains difficult to express.
Publish enough detail for a peer to challenge the result
A useful build-in-public note names the task, the starting state, the repeat action, the visible message and the saved outcome. Keep the sequence short enough to reproduce, and use sample identifiers rather than customer data.
For the fictional form, a compact record might describe a delayed create request, a second activation during the delay, one returned project identifier and one project in the reopened workspace. A separate row would describe the uncertain-response retry. These are proposed record fields, not results collected from an actual app.
Buildside is a community for founders sharing product work in public. If you bring this demo to founder peers, ask a narrow question: can they tell whether the recovery uses the existing project or creates another one? That review can improve the explanation, while actual repeat-submission behavior still needs direct testing.
Keep the claim tied to the tested version
After a repair, rerun the failed scenario and the ordinary single submission. Include the intentional second-project case too. A fix that prevents duplicates by making every later creation impossible has not preserved the task.
Keep the old observation connected to the new result. State which sequence previously failed and what the revised version now does under the same conditions. If you cannot reproduce the failure reliably, say that and preserve the uncertainty instead of turning a quiet retest into proof of a permanent fix.
Before recording the next release clip, choose one form that creates something and inspect its retry path. If a viewer cannot tell whether their action succeeded or what another attempt will do, the demo has found a useful product question. Answer that question with a checkable result before polishing the animation around the button.
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.
