foresight.org · web requests
How to send a new page or an update, what happens to it, and how long it takes. Pages built to the Foresight build spec go live fastest.
Every change reaches the site through one checked route.
That route is what keeps foresight.org secure, and it's also what makes it quick: when pages arrive in a format we already know, checking and publishing them is routine. Pages built to the spec skip most of the custom setup.
The route
One request per page, finished and approved on your side, with the details listed under What to send.
Checks the request is complete and the page follows the spec, and decides if it's a rush. Passes it on, usually the same day, or sends it back with what's missing.
Security and code review, setup on the site, then live at its final address with caches cleared. The turnaround clock starts when it reaches us.
Look over the live page on desktop and phone. If it doesn't match what you sent, we fix it the same day. Anything you'd now like different is an update.
Page types
Every page is one of three types. The choice decides how the page sits in the site, and who controls how it appears in search results and when shared on social media.
Your pageYour page sits inside foresight.org's normal header and footer, like any other page on the site.
Example: Advisory Circles join page
Your page, with its own headerYour page brings its own header. The site adds its normal footer at the bottom.
Example: Founder & Funder Mixer
Your page, nothing around itFor a page that must look completely separate from foresight.org. Rarely needed.
Example: a partner microsite
For types B and C, the page title, search description and social share preview (the image and text shown when the link is posted on LinkedIn, X or Slack) come only from your page's HTML. They must be built in before sending, and changing them later means sending a new file. With type A, the webmaster can change all of these in WordPress at any time.
Use type A unless there's a design reason not to. All three types keep the site's analytics.
Turnaround
Times count from when a request reaches The Webmaster Company from Djordje. Requests received by noon count as that business day.
| Request | Live within |
|---|---|
| Update to an existing pageNew version of a page that's already live, same address | 1 business dayoften the same day |
| New page, type A, built to the spec | 2 business days |
| New page, type B or C, built to the spec | 3 business days |
| Page that doesn't follow the specIts own setup, new connections, changes to the site's theme | Estimate within 1 business dayusually 3 to 5 business days |
| Site problemSomething on the live site is broken or wrong. See site problems and rushes | Same business day |
Pages go straight to their live address. Changes sent after a page reaches us follow the rules under Send it when it's final.
Final versions
Pages go straight to live, so the version you send is the version the world sees. A few minutes of checking before sending saves a day of follow-ups.
Djordje will ask "Is this final?" before passing it on.
If the live page doesn't match what you sent, that's ours to fix: same day, never counted as a rush.
Several at once
New pages are built and checked one at a time, in the order Djordje passes them on. Each takes its usual turnaround from when work on it begins, so when several arrive together, the later ones go live later.
If more than one request is waiting, you choose the order. Tell Djordje which matters most and we'll work in that order. A rush moves to the front, and we'll tell you which requests move back to make room.
Updates to pages that are already live don't wait behind new pages.
If a launch, event or campaign is coming, let Djordje know as soon as it's planned, even before the page exists, and we'll keep time free for it.
Site problems and rushes
There are two kinds of request that skip the normal turnaround. Djordje decides which one a request is.
Something on the live site is broken or wrong right now.
Handled the same day, always, and never charged.
Anything else that's needed sooner than its usual turnaround.
A rush goes to the front of the queue, and we'll tell you which requests move back.
Sometimes a page really is needed sooner. That's normal, and two rushes a month are included in your contract.
Every rush request answers one question: what happens if this goes live on the normal timeline instead?
What to send
Send these to Djordje. A complete request starts on time; an incomplete one comes back before it reaches us.
One page per request. Changes to three pages are three requests, which keeps the queue clear and each page's history easy to follow.
Build spec
The build spec sets out the file format, the rules for each page type, the SEO tags types B and C need, and a README template. If you build pages with an AI tool, paste the whole spec into it before you start. Pages built from it arrive ready to check instead of needing rework.