Next.js landing builds for pages a builder cannot do

Most landing pages should not be a Next.js application, and we will say so on the first call if it applies to yours. Go custom when the page has to do something a builder cannot: read live pricing, inventory or network state from your own API, serve a different legally required variant per market on the same URL, sit behind your own authentication, or pass a security review that rules out third-party script hosting. If none of those hold, we will build it in Webflow and invoice you less. Where it runs: Your infrastructure. The build ships as a standalone Next.js output behind nginx or Caddy, under systemd or PM2, or into the Kubernetes you already operate. We avoid host-proprietary primitives deliberately, because at a listed manufacturer or a regulated exchange the security review is where an engagement dies, and 'it only runs on one vendor's edge network' is the answer that ends the conversation. If you would rather we host it, we will, on a machine you can take the keys to. Performance is reported from the field: Targets are LCP under 2.5 seconds and INP under 200 milliseconds at the 75th percentile in Chrome's field data, on your traffic, not a Lighthouse score on a developer laptop with a fast connection. We send the reading 28 days after launch. Where the site is too small to appear in the public dataset we install a web-vitals beacon and report from that, and we tell you which of the two you are getting before the work starts. What the custom part usually turns out to be: Pricing read from your billing system and revalidated on a schedule you set, rather than on a designer's memory. Geo and locale routing in middleware, with the legal variant resolved server-side so nobody sees the wrong disclosure while JavaScript loads. Forms posting straight into your CRM with server-side validation, a rate limit and a signed honeypot, so your sales team stops receiving bot submissions at three in the morning. A Content-Security-Policy with nonces and no unsafe-inline. Consent Mode v2 and server-side tagging, so the page carries a fraction of the third-party weight it otherwise would. What we refuse: Shipping a marketing page as a client-side single-page application. Adding a headless CMS nobody asked for — if one person owns the copy it lives as MDX in the repository and they edit it in a pull request, and if you already pay for a CMS we wire that one instead of selling you another. Building anything only we can deploy: the repository ships with one deployment document and one command, and we test that document by having someone who did not write the code follow it. Handover, and what stays yours: The repository, in your organisation, from the first commit. Environment variables documented. A staging environment that matches production rather than approximating it. No licence, no retainer required to keep the page running, no code that phones home to us. Not for you if: You need the page live next week; this work takes longer, and rushing it produces exactly the fragile thing you were trying to avoid. Nobody on your side can own a repository long term and you do not want us hosting it either. You want a marketing site rebuilt in React because React is modern — that is a cost with no reader on the other end of it, and we will argue against it before we agree to bill you for it.