Prepare your website content before the build starts by handing over finished text, correctly sized photos, and final logo files in one organised pack — because content is the most common reason website builds stall. A build with approved copy, named image files, and a logo in the right formats can move from design to launch without waiting on anyone. A build that starts while text is still "being written" will pause at every page, and each pause costs days.
This guide covers the client side of the job: what to write, what to photograph, which file formats to supply, and how to package it all so a designer or developer can use it without chasing you. It is deliberately different from a page-by-page content plan. Where our earlier guide walks through what each page should say, this guide is about readiness: the files, the formats, the naming, and the handover that keep a build moving. If you are about to commission a website, work through it before the kick-off call, not during the build.
Why Content Delays Builds (And How to Avoid It)
Designers can design around placeholder text, but they cannot launch with it. Every page built with placeholder copy has to be revisited once real text arrives, because real headlines are longer or shorter than the placeholders, real service lists have more items, and real photos have different shapes. That rework is not a small tidy-up: text changes ripple into layouts, menus, mobile views, and search snippets. Supplying finished text first means each page is designed once, around the words that will actually appear on it.
Photos cause the second classic delay. A business that promises "photos next week" usually discovers that next week needs a photographer, a tidy premises, and permission from anyone pictured — none of which can be improvised on launch day. Logos cause the third: a single small JPEG pulled from a social profile cannot be enlarged for a website header, printed on a van, or placed on a dark background. Each of these delays is avoidable, and all three are avoided the same way: gather the real files before the build, not alongside it.
Tip: Set a content deadline a full week before the design start date, and treat it as seriously as a payment date. If text or photos are not ready by then, move the design start rather than starting with placeholders — a later start with finished content finishes earlier than an early start that stalls.
The Text Checklist: What to Write Before the Build
Write in plain documents, one file per page, using the page name as the file name. A designer should be able to open a folder and see exactly which document belongs on which page, without decoding a single combined file. Keep sentences short, write about the reader's problem before your own history, and give every page one clear action — the thing a visitor should do after reading it.
| Text item | What "finished" looks like | Why it blocks the build |
|---|---|---|
| Homepage headline + subheadline | One promise, one audience, one action | Design is built around the hero words |
| Service descriptions | One document per service, 150–300 words each | Service pages cannot be laid out without them |
| About page text | Story, team names, credentials, photo captions | Needs matching photos and permissions |
| Contact details | Phone, email, address, opening hours, areas served | Appears in header, footer, and contact page |
| FAQs | Five to ten real customer questions, answered plainly | FAQ sections are structured around real questions |
| Legal and policy notes | Privacy note, terms, delivery or returns wording | Must be reviewed before launch, not after |
Do not worry about perfect prose. A web team can tighten sentences, fix headings, and shape text for search, but it cannot invent facts about your services, your prices, or your process. Write the facts plainly — what you do, who it is for, what it costs as an indicative range where relevant, how long it takes, and what happens next — and let the design team polish the presentation. Text that is factually complete but roughly written is far more useful than polished text that says nothing concrete.
Photos: Specs, Sizes and Phone Tips That Actually Work
Supply original photos at the largest size your phone or camera produces, and never send screenshots of photos or images already compressed by a messaging app. Messaging apps shrink images aggressively; a photo that looks fine in a chat thread can turn soft and blocky at website size. Send originals through email, a cloud folder, or a file-transfer link, and keep the originals yourself as backup.
| Photo type | Minimum useful spec | Phone tip |
|---|---|---|
| Hero / banner image | At least 1920 px wide, landscape | Shoot landscape, leave space at the edges for text |
| Service and gallery photos | At least 1200 px on the longest side | Clean the lens, shoot in daylight, take several options |
| Team portraits | At least 1000 px square, consistent style | Same background and light for every person |
| Product photos | At least 1200 px, plain background where possible | One product per shot, plus one in-use shot |
For every photo, add a one-line caption or filename note saying what it shows and where it belongs, such as "team-leeds-workshop.jpg — About page". Captions do double duty: they help the designer place the image, and they become the starting point for the image description that search engines and screen readers use. If a photo shows identifiable customers or staff, confirm you have permission to publish it before handing it over; sorting permissions during launch week is a delay that is entirely avoidable. For product photography technique in more depth, see our phone product-photo guidance linked from Asad Webs blog.
Logos and Brand Files: Formats That Save Rework
Logos are small files that cause outsized trouble, because the wrong format cannot be fixed by enlarging it. A JPEG logo with a white box around it will look wrong on any coloured header, and a tiny social-media avatar will blur when stretched to header size. Ask whoever designed the logo for the original files; if no designer is available, supply the largest, cleanest version you have and say so honestly, so the team can plan around it.
| File to supply | Format | Used for |
|---|---|---|
| Logo, master version | SVG, PDF, AI or EPS if available | Headers, print, any size without quality loss |
| Logo, web version | PNG with transparent background | Website header and footer on any colour |
| Logo, dark-background version | PNG, light colours on transparency | Footers and dark sections |
| Brand colours and fonts | Colour codes + font names in a text file | Matching buttons, headings and graphics |
If you only have a JPEG logo, do not try to fix it yourself with online background removers that leave ragged edges; tell the web team at handover. A good team will redraw or rebuild a simple logo, or design around its limits, but only if it knows the limit on day one. The same honesty applies to brand colours: if there is no brand guide, say which colours you already use on signage, vehicles, or packaging, and let the team build from those rather than inventing a palette that clashes with the real business.
The Handover Pack: Folder Structure That Works
Package everything in one folder with a clear structure, and send a single link rather than a stream of attachments across several emails. Attachments scattered across inboxes get lost, duplicated, and mixed with older versions; a single folder with version dates does not. Name every file for what it contains, not for when it was made: "homepage-text-v2.docx" beats "final-final-new.docx" every time.
Example handover pack for a 10-page small-business site — item counts for one illustrative pack, not a required standard.
A workable folder structure looks like this: one folder for text (one document per page), one for photos (originals, with a short captions document), one for logos and brand files, and one for extras such as price lists, brochures, or certificates. Include a single "read me" document at the top listing what is included, what is still to come, and who to ask about each item. That read-me document is the difference between a handover and a data dump: it tells the team what is finished, what is intentionally missing, and what is merely late.
What Delays Builds Most: The Honest List
Text arriving page by page. Each late page reopens layout work on pages already approved. Finish all text before design starts, even if some pages need only a short draft.
Photos sent through messaging apps. Compressed images look acceptable on a phone and poor on a website. Originals only, through a cloud folder or file transfer.
Logo supplied as a single small JPEG. It cannot scale, cannot sit on a dark header, and cannot be fixed by enlarging. Supply vector or transparent PNG versions, or flag the gap early.
Approvals from several people with no single decision-maker. Nominate one person who can approve text and design. Builds stall fastest when every draft waits on a committee.
New services added mid-build. Every added page changes menus, navigation, and launch checklists. Freeze the page list at kick-off and put new ideas on a post-launch list.
Key takeaway: A build moves at the speed of its content. Finish the text, gather original photos, supply proper logo files, and hand everything over in one named, dated folder with a single decision-maker for approvals — and the build will finish faster than a build that started earlier with placeholders.
Frequently Asked Questions
How much text do I need before the build starts?
One finished document per page: a headline and a clear action for every page, plus 150–300 words for each service page and a short About text. Rough but factually complete text is enough; the web team can polish wording, but it cannot invent your facts.
Can I use phone photos on my website?
Yes, provided you send the original files at full size, shoot in good light, and avoid heavy filters. Originals sent through a cloud folder or file transfer are fine; photos forwarded through messaging apps are usually too compressed for website use.
What if I only have a JPEG logo?
Send the largest, cleanest version you have and tell the web team at handover. A simple logo can often be rebuilt, and a team that knows the limit on day one can design around it; a team that discovers it at launch cannot.
Who should approve content and design?
One named decision-maker. Builds stall when drafts wait on several approvers with different views, so nominate one person whose approval is final and let others comment through that person.
Can I add pages after the build has started?
You can, but each added page changes menus, navigation, and launch checks, so it usually adds time and cost. Freeze the page list at kick-off and keep new ideas on a post-launch list instead.
Starting a new website and want the content side handled properly? If you would rather hand over a finished pack than chase files mid-build, talk to Asad Webs about your new website and we will send you a handover checklist matched to your pages.
Methodology note: file specs are practical minimums for typical small-business websites, checked October 2026; prices mentioned anywhere in this guide are indicative market ranges. For more step-by-step guides, browse Asad Webs blog.
Be the first to share a useful question or thought.