How edits work.

No logins. No CMS. No email purgatory. A labeled button on every page, a short form, and the change shows up.

The idea

Most church websites die the same way. The person who built it moves on; nobody on staff feels qualified to touch the code; change requests pile up in someone’s inbox; six months later the pastor’s old photo is still there and the food-pantry hours are wrong. The site stops being trusted, and then it stops being read.

A nave.build site treats edits as a first-class feature, not an afterthought. Every page has a Suggest an edit link in the footer. Anyone on staff can use it. The pastor, the office admin, the youth-group volunteer who noticed the VBS dates are wrong. They don’t need an account. They don’t need to learn anything.

What it looks like

1. Notice something.Maybe the staff page still shows the previous pastor, or someone wants to put up a poster for the spring rummage sale. Scroll to the bottom of any page. There’s a small link that says Suggest an edit.

2. Fill out a short form.Name, email, where on the site, what’s changing, an optional photo, an optional date for when it should go live (and when it should come down). Then the staff passcode — one shared word the church admin gives to anyone allowed to make requests. Think of it like the key to the supply closet, not a bank password.

3. Hit Send.The page says “Thanks — we got it.” A confirmation email lands in their inbox a moment later with a copy of what they submitted, in case they need to refer back to it or reply with a correction.

4. The change appears. Usually within a day or two. The person who submitted it never has to log in anywhere or check on its status.

The quick stuff: a small admin panel

For the handful of things that change often — service times, the announcement banner, staff photos, contact info, the welcome paragraph — there’s also a small admin panel at /admin. One passcode for the person doing the editing. A focused form for each thing. Changes are live on the site within about a minute, no developer required.

It’s deliberately narrow. New pages, layout changes, redesigns — those still come through the Suggest-an-edit form, where a person looks at them. The admin panel is for the routine updates that shouldn’t need a person in the loop.

Behind the scenes

Every request becomes a labeled item in a private queue that the church admin (or, on the hosted plan, the nave.build team) works through like a worklist. Nothing falls through email cracks because nothing happens by email. The queue keeps its own history — you can see every request that was ever sent, who sent it, and when it shipped.

On the handoff plan, the church handles its own queue. On the hostedplan ($10/month), nave.build watches the queue and processes up to two minor updates a month — staff changes, service times, a new event poster.

What it isn’t

This isn’t a content management system. There’s no admin dashboard with fifty buttons, no “page builder,” no plugins to update. The whole interaction is one form. We’ve found that for most parishes that covers about 80% of the edits they’ll ever want. The other 20% — new pages, layout changes, design tweaks — we handle separately, so the website doesn’t become the kind of thing that needs constant feeding.