DEV Community: ThirdWeb

Building a Browser-First Audio Cleanup Flow That Uploads Less

ThirdWeb — Tue, 03 Nov 2026 14:13:24 +0000

When a user wants to clean the sound in a video, the obvious implementation is to upload the whole video and process it on a server. That is also the first privacy and bandwidth decision worth questioning.

For a small speech-focused noise-reduction tool, we built the flow around a narrower contract: keep the original video in the browser, extract only its audio, process that audio, and put the cleaned track back under the original picture locally.

1. Validate the file before uploading it

The first useful check happens on the device, before an upload starts.

For audio, the current flow accepts MP3, PCM WAV, M4A/AAC, up to 100 MB and 30 minutes. For video, it accepts an MP4 with H.264 video and AAC audio, up to 500 MB and 30 minutes. The container extension is not enough: a file named clip.mp4 can still contain an unsupported codec.

A local preflight check gives the user a clear failure message and avoids spending time uploading a file that cannot be processed. It also makes the support conversation more concrete: report unsupported_codec, not just “something went wrong.”

2. Make the preview use the same settings as the paid job

A preview is only useful if it predicts the full result. Our preview uses the first 30 seconds of the user’s recording with the same noise-reduction settings used for the full task. The user can compare the original and cleaned speech before deciding.

The other important step is showing the exact minutes needed before confirmation. The system does not charge or deduct minutes while the user is still listening to the preview. That separation keeps the product flow understandable:

Choose a file.
Hear a real preview.
See the exact cost in minutes.
Confirm the full recording.

3. Keep the original video on the device

The browser extracts the audio track and uploads only that derived audio. When the cleaned audio is ready, the browser matches it back to the original file and exports a new MP4 with the original picture.

This reduces upload size and avoids sending video frames that the noise model never needs. It also creates a clear limitation: the user must keep the original file available until export is finished. A browser app should explain that requirement instead of hiding it behind a generic download button.

Local assembly also needs explicit browser support. In our case, MP4 export is supported in current Chrome and Edge on Windows and macOS; other browsers can still download the cleaned WAV even when local MP4 export is unavailable.

4. Treat retention and failure as part of the product

Audio uploads are temporary work data, not a permanent media library. The service deletes uploaded audio within 24 hours at the latest, and unconfirmed full-file inputs sooner. Cleaned audio is also temporary and can be deleted earlier from the task page.

Failure handling should distinguish a job that failed before the AI provider started from a result the user simply dislikes. The first case can return reserved minutes once. The second is why the preview must be honest: an automatic refund cannot turn a poor result into a useful workflow.

5. Be precise about what “noise reduction” means

The target is steady noise under speech: fan or air-conditioning hiss, microphone hum, and ordinary room ambience. It is not the same as music separation, de-reverberation, clipping repair, or removing another person who is speaking at the same time.

That boundary belongs on the upload page, not only in a help article. Users should know what to test before they spend minutes, and the preview should remain the final judge for their own recording.

Try the flow

Remove Background Noise offers a free 30-second preview for audio and video. The audio noise remover returns a cleaned WAV, while the video noise remover keeps the original picture on the device and processes only the extracted audio.

The useful design principle is simple: upload the smallest data object that the model actually needs, then make every limitation visible before the user commits.

Designing a public Reddit search tool with clear source and coverage limits

ThirdWeb — Fri, 30 Oct 2026 13:56:27 +0000

A public-content search interface has to explain what its results actually mean. A missing result is not proof that a discussion never existed, and an archive-themed product name should not imply deleted-text recovery.

Reddit Archive is an independent web tool for searching Reddit content that is still publicly available. Its interface supports keyword search for posts, opening a post or comment from a URL, and browsing public posts and recent comments by username or subreddit.

Match each input to a specific promise

Keyword search finds public posts. A known URL identifies a particular post or comment. A username or subreddit opens a public listing. These modes should stay visibly distinct: a post search is not a full-text search across every Reddit comment.

Keep the source attached

Returned text, available publication timestamps, fetch time, and original source links help users understand and check a result. Missing text should remain missing instead of being reconstructed or presented as recovered content. Availability depends on what the data service returns at query time.

Explain loaded-result filters

A filter over already loaded records can help narrow a list, but it should not promise a complete account or subreddit history. The interface needs to communicate that scope where the filtering happens.

Make credits understandable

New Reddit Archive accounts receive one free credit that never expires. Paid plans provide additional credits; payment does not unlock deleted text or deeper historical coverage. Empty results, errors, and timeouts do not consume a credit. Current options are described on the pricing page.

Archived does not mean deleted

An archived discussion can remain public while voting and commenting are closed. That is different from deleted or removed text. This distinction belongs close to the search experience, where users can interpret it before making assumptions about a result.

Reddit Archive is not affiliated with Reddit, Inc., does not provide a complete historical archive, and cannot recover deleted or removed text.

The practical design principle is to describe the scope of the data at the moment users rely on it: input, result, filter, and payment.

Designing a public profile viewer: clear limits, previews, and credits

ThirdWeb — Mon, 26 Oct 2026 09:38:02 +0000

A viewer for public social posts looks simple: accept a handle or URL and display the result. The product decisions become more interesting when the data is incomplete, requests have a cost, and the user needs to know what they will get before paying.

Start with explicit inputs

An exact username, profile URL, or post URL gives the interface a clear target. That is a different promise from keyword search, hashtag search, or a complete archive. Showing the supported inputs next to the form helps people recover from an invalid link without implying that the tool can search for anything.

Separate public access from account access

Not requiring an X login is useful, but it does not mean a tool can reveal private accounts or deleted posts. It also does not mean every feature has no account requirement. A free preview and a separate product account for paid features can coexist; the interface should describe which account is needed and when.

Make metering understandable before a purchase

A useful credit model should state the unit of consumption, the free allowance, and what happens when a request fails. For example, a profile preview might include three posts, while each additional delivered post consumes one credit. If a data source cannot return a post, charging for it would make the result hard to trust. Show the amount and action before the user commits.

Treat missing data as a normal state

Public does not mean complete or permanently available. Posts may be deleted, accounts may become protected, media may be unavailable, and a provider may return partial or cached results. A retrieval timestamp and a clear explanation of missing data are more useful than promising a complete live history.

These are the product boundaries used by Twitter Viewer, an independent browser-based tool for public X profiles and post links. Its free profile preview contains three posts; additional profile posts use prepaid credits. The service is not affiliated with X.

What other UI patterns have you found helpful when a third-party data source can return partial results?

Designing a no-match-no-charge flow for a song identification tool

ThirdWeb — Wed, 21 Oct 2026 05:26:58 +0000

Disclosure: this post is shared on behalf of TikTok Song Finder, an independent paid tool for identifying music from public TikTok links. The design below is a general implementation pattern, not a claim about measured performance or the exact internals of the service.

A recognition request can produce a match, no match, or a failure to process the input. A credit-based product needs to distinguish these outcomes before charging.

Model outcomes explicitly

type Outcome =
  | { kind: "matched"; title: string; artist: string }
  | { kind: "no_match" }
  | { kind: "unavailable"; retryable: boolean };

An unavailable video is not evidence that the catalog has no matching song. Keep input failure separate from recognition failure so the interface can explain whether a retry might help.

Make retries safe

Give each attempt a server-generated identifier. Record its outcome and credit ledger entry together in a transaction. Add a uniqueness constraint on the ledger reference for that attempt so a duplicate callback cannot deduct twice. Check the balance atomically. A browser timeout must not cause another charge when the user refreshes: return the stored attempt status instead of creating a second attempt. If credits are reserved before processing, model a reservation and its release explicitly so failed requests do not hold credits indefinitely.

Separate matches from listening links

A title and artist may be available even when a particular listening provider has no link. Treat provider links as optional fields. Avoid presenting a search result as a verified recording, especially when a clip contains a remix, sped-up edit, or speech over music.

Test failures as well as success

Cover two requests competing for the last credit, a result delivered twice, a timeout after a result is stored, an inaccessible video, and a match with missing listening links. Assert both the displayed outcome and final ledger balance. A useful invariant is that a single completed match can consume at most one credit.

Explain payment before recognition

Users should see sign-in and payment requirements before starting. TikTok Song Finder uses a one-time $9.99 pack of 10 credits; one credit is used only when a song is found. Credits never expire and there is no subscription. It accepts public TikTok links and is not affiliated with TikTok or ByteDance.

Connecting billing to a durable outcome gives developers a concrete invariant to test and users a clearer explanation of what happened.