Hiring for a creative or technical role without an ATS usually means applications arrive four different ways at once: PDF attachments, Google Drive links you have to request access to, WeTransfer links that expire before you open them, and the occasional 400 MB video reel that bounces entirely. By the time you shortlist, half your review time has gone into file logistics instead of candidates.
This guide is the setup we recommend for small teams: what to ask for, where applications should land, and what happens to the files after the search closes.
First: do you even need this?
If you already run Greenhouse, Lever, Workable or any real ATS, stop here - use its application form. An ATS handles intake, parsing and compliance in one place, and a separate upload page would just fragment your pipeline.
A dedicated upload page makes sense when you hire a few times a year and an ATS subscription is not worth it, when a role needs large files an ATS form rejects, or when you are running a confidential search outside your normal pipeline.
Ask for the right things per role
Most of the pain here is self-inflicted by vague instructions ("send us your portfolio"). Be specific, and calibrate to the role:
- Designers: one PDF portfolio capped at a stated size, plus a link sheet for interactive work. High-res source files belong in a later round, not the application.
- Video / motion: ask for links (Vimeo, YouTube unlisted) as a text file or PDF, not the reels themselves - unless you specifically want raw files, in which case say so and expect 500 MB+ per candidate.
- Developers: a resume plus repository links. Asking for zipped codebases mostly collects other people's tutorial projects.
- Writers: 2-3 samples as PDFs, with a note on what their role was in each piece.
Whatever you ask for, state the file formats you accept and name one fallback contact for candidates who get stuck. The candidates you most want are often the ones applying to several places - friction filters them out first.
One page per role, or one evergreen inbox
Two patterns work, and the choice depends on volume:
One page per opening (small teams). Title it with the role and window - "Senior UX Designer - Applications (July 2026)". Pages run up to 10 days at a time, so for a longer application window extend the page as it approaches expiry - a two-click nudge that doubles as your reminder the role is still open. You get one clean ZIP per role, and the page dies with the search, which also solves data retention (see below).
One evergreen page (agencies, constant intake). A single long-lived intake URL on your careers page. Rely on an uploader-name field and per-candidate subfolders when you download; accept that you will do more manual sorting.
Rotate an evergreen intake URL once or twice a year. Old job-board postings and scraped listings keep feeding a URL long after the roles close - rotation is the only reliable off switch.
The job-board reality
You cannot change how LinkedIn or Indeed collect applications, and candidates will apply there regardless. Treat the upload page as the second step, not a replacement: put it in the auto-confirmation email, the post-screening follow-up, or the interview scheduling email ("before the call, drop your portfolio here"). That way the heavy files arrive only from candidates who passed the first filter - which is also when you actually want them.
Structured intake beats a free-for-all
If your tool supports a required-items checklist, use it: resume required, portfolio required, cover letter optional. Candidates see exactly what is expected, you see at a glance who submitted an incomplete application. This converts the most common recruiter follow-up ("did you attach the portfolio?") into a non-event. On getfiles.app this is checklist mode; other tools have equivalents.
While you are at it, restrict the allowed file types to documents and images. An application page is an open invitation for strangers to send you files - there is no scenario where you want a candidate's .exe, and a type restriction closes that door before your antivirus has to.
Confidential searches
Replacement hires and internal-only searches need two properties from an intake page: the upload URL is password-protected and shared only with approached candidates, and the reviewing link is separate from the upload link, shared only with the hiring panel. Check that your tool separates the two before trusting it with a search your own team should not see.
After the offer: onboarding paperwork
The intake problem does not end at the signed offer - it moves to HR. A typical new-hire document set:
- Government-issued ID
- Tax forms (W-4 and state forms in the US)
- Direct deposit authorization
- Signed offer letter or contract
- Emergency contact form
- Certifications or licenses the role requires
Collect these on a fresh page per employee, password-protected, with a short expiration (a week is plenty). Download the ZIP into your HR system as soon as the set is complete and let the page expire. Reuse the same description text as a template for every hire so nothing is forgotten.
These are identity documents and bank details. They should not sit on any web-accessible URL longer than necessary - short expiration on the intake page is a security control here, not a convenience.
Delete what you collected
Candidate files are personal data. When a search closes: download what you are required or want to keep (check your local rules - some jurisdictions expect unsuccessful-candidate data gone within months), then delete the page rather than letting it linger. Expiring pages make the compliant path the lazy path, which is the only kind of compliance that reliably happens.
If you want a ready-made version of this setup, getfiles.app does upload pages with checklists, passwords, expiration and per-role ZIP downloads, free and without requiring candidates to create an account.