Custom website development services
in Boston

Most site briefs treat forms as a solved problem, with one name field, one email field and a message box. Then the real requirement arrives. The form has to take a file, it has to branch, and it has to ask a question that only applies to one kind of visitor while skipping it for everyone else.

That is a different piece of software. It needs state, it needs validation that explains itself, and it needs somewhere for the data to land that is not a shared mailbox.

Start with the question nobody enjoys. What is actually collected, and why. Every field has a cost. Each one lowers completion, and each one becomes a retention obligation the moment it is stored. Fields that exist because somebody might want them later are the ones to cut.

Conditional logic is where these forms break. A branch that hides a field does not always clear its value. The submission then carries an answer to a question the visitor never saw. Test the branches by walking them, not by reading the configuration.

File uploads deserve their own decision. Size limits, accepted types, virus scanning, and a storage location that is not the web root. A form that accepts documents and writes them into a public directory is a data leak waiting for a search engine to find it.

Confirmation matters more than people expect. A visitor who submits a long form and sees a blank page assumes it failed. They submit again. Now there are duplicates, and the team is calling the same person twice.

Then there is the boring half: who reads the submissions, what the response time is, and where the record lives after somebody responds. A form that works technically and dies in an unmonitored inbox has not solved anything.

We build these as small applications rather than as page decoration. That means the field list is versioned, the branches are documented, and the destination is a system somebody owns.

Plenty of organisations publish their most useful material as documents. Reports, schedules, tariffs, minutes, technical sheets. Then the site search indexes page titles and finds none of it.

Visitors do not care where the answer is stored. They type the term and expect a result. When the search returns nothing, the conclusion is that the organisation does not publish that information at all.

The first fix is extraction. Text inside a document can be read and indexed alongside pages. A scanned document cannot, because it is an image. Those need optical recognition or a text summary entered by hand.

Filenames carry more weight than anybody intends. A result listed as final-v3-updated tells the visitor nothing. Every document needs a human title, a date and a short description held as data, not baked into the file.

Decide how results are mixed. Documents and pages in one list is simplest, provided the type is labelled and the file size is shown. A visitor on a phone deserves to know before tapping.

Superseded versions are the quiet failure. An old tariff sheet that stays indexed will keep being found, and somebody will act on it. Retire documents deliberately, and where the old version must remain available, mark it clearly on the page that holds it.

Search for nothing is worth designing. When the query returns no results, offer the section index and the contact route rather than an empty page.

Then read the query log monthly. It lists, in the words of real visitors, what they expected to find. Half the entries usually describe something that exists under a different name.

Plenty of announcements are not ours to time. A partner sets the date, a funder lifts an embargo, or a regulator publishes first, and everything downstream has to follow within hours.

Sites that handle this well share a few traits. Content can be finished and staged without being visible, publication is a scheduled action rather than a person clicking at the right minute, and somebody other than the original author can release it.

Scheduled publishing sounds trivial and usually is not. Time zones cause most of the damage. A post scheduled in local time and served to an audience elsewhere goes live at the wrong hour. Store and display the zone explicitly.

Preview is the other half. Reviewers need to see the finished page, on the real template, before it exists publicly. A shared link with a token does that. Sending screenshots does not, because the layout is exactly what people are checking.

Caching will fight you. A page that goes live at nine and stays invisible until the cache expires has missed the moment. The publish action has to invalidate the relevant paths, including the listings and the feeds that point at it.

Build a rollback path before it is needed. Occasionally something goes out early or wrong. Being able to unpublish in one step, without deleting, keeps a bad moment from becoming a lost page.

Where several items release together, group them so that one action publishes several pages. Releasing them one at a time produces a window where half the story is public and half is not.

None of this is exotic. It is ordinary editorial infrastructure, and it is usually missing because nobody asked about timing during the brief.