Normal web engineering optimises for sustained load and gradual growth. A drop page has neither. It sits at zero, receives everything at once, and then returns to near zero.
Design for the spike or do not bother.
Static, always
No database in the critical path. No server-side rendering on request. No API call that has to succeed before the page paints.
Everything that can be a file should be a file, and every file should be on an edge network. When the announcement lands, the only thing between the visitor and the experience should be a CDN with a warm cache.
The dynamic parts, capture, counters, personalisation, go behind the first paint and fail gracefully. If the email endpoint is down, the experience still runs and you lose emails. If the experience is down, you lose everything.
The failure mode is blank, not slow
This is the reframe that changes decisions.
A build that degrades to a still frame and audio under extreme load is a success. A build that shows a white screen for eleven seconds is a wasted announcement, and announcements are not repeatable.
So: every heavy thing needs a lightweight fallback that ships in the same deploy. Not a plan to add one later.
Set the asset budget before art direction
Kilobytes are a creative constraint and they should be handed to the creative process at the start, exactly like a canvas size.
A budget agreed after the art is approved is not a budget, it is a fight. A budget agreed before is a brief, and briefs make work better.
For a mobile-first drop experience, a total critical-path payload in the low hundreds of kilobytes is achievable and produces something that feels instant on cellular data. Multi-megabyte hero video does not.
Capture at the peak, not at the end
The most common design puts email capture at the bottom, after the experience.
That is the worst possible position, because it asks for something at the exact moment the visitor's attention is lowest. Ask at the peak, the moment they have made something, seen the reveal, or hit the thing they came for. One field. No second field.
And ask for the thing you can actually use later. An email address you own outlasts a follow you rent.
Load test at ten times
Whatever you expect, test ten times it, and test the announcement rather than the release. Announcements peak higher and arrive earlier than plans assume, frequently because someone posts before the scheduled time.
What to build first
In order:
- The single interaction, ugly, on a phone, with placeholder assets.
- Hosting and the static pipeline.
- The degradation path.
- Capture.
- Art direction.
- Everything else, if there is time, which there will not be.
That order looks wrong to most creative processes and it is the order that ships. The parts that get cut when the timeline compresses should be the parts at the bottom, and they are only reliably at the bottom if you built from the top.