How to choose a website provider for your MCL detachment
By Geek Heros
Published
Updated
A Marine Corps League website should make the next meeting easy to find, explain how to get involved, and stay useful when officers change. When you compare providers, ask them to demonstrate those jobs before you spend time choosing colors.
The short answer: choose an MCL website provider by checking the public experience, volunteer editing, account ownership, migration, accessibility work, and ongoing support. Put the agreed responsibilities in writing. A polished homepage alone does not tell you whether the next Adjutant or volunteer webmaster can keep the site current.
Use the scorecard below with your Commandant, the people who will update the site, and whoever approves the expense. You do not need everyone to be technical. You need agreement on what the website must do and who will keep it useful.
Start with three jobs your detachment needs done
Write a short project brief before requesting proposals. For a first conversation, three concrete tasks are more useful than a long wish list:
- Help someone visit. A prospective member can find the next meeting, location, what to expect, and a person to contact.
- Help a volunteer publish. An authorized editor can update an event, correct a meeting detail, and post an approved announcement.
- Help the next team take over. Incoming officers can find the account inventory, instructions, renewal dates, and support contact.
Add your detachment's own priorities. You may need a program page, scholarship information, an event registration link, or an accessible newsletter archive. Identify which are essential for launch and which can wait.
Use your organization's actual officer titles and approval process. The Marine Corps League's current Detachment Report of Officer Installation lists roles including Commandant, Adjutant, and Paymaster; your local responsibilities should be confirmed rather than inferred from a generic club template. Marine Corps League officer form
Separate the public website from member and officer tools
A public website and a private workspace have different requirements.
Your public website might explain the mission, list events, introduce programs, and provide membership and contact information. A member area might hold resources intended only for members. An officer workspace might organize reports, assigned follow-ups, or meeting preparation.
Do not let a proposal blur those three scopes into one phrase such as "complete membership system." Ask which screens and workflows are included, who can see each kind of information, and what happens when someone's role changes.
If you already use a national membership system, payment tool, or shared document service, tell the provider. Ask whether the proposed site will link to it, embed part of it, exchange data with it, or replace it. Those are different projects. A promise to "integrate" should name the systems, permissions, data, and responsible parties.
The Geek Heros Digital HQ overview explains the distinction between public information, member experience, and officer work. Features and connections still need to be agreed for your project.
Use an evidence-based provider scorecard
This is a discussion tool, not a certification. Mark each row 0: unanswered, 1: described, or 2: demonstrated and included in the proposed scope. Record the evidence beside the score. An unresolved must-have matters more than a high total.
| Decision area | What to ask the provider to show |
|---|---|
| Membership and visiting | A clear path from the homepage to meeting details, membership information, and a monitored contact method. |
| Events and updates | A volunteer editing an event, previewing the change, and publishing through the agreed approval process. |
| Accessibility | The testing approach, what content is included, who fixes findings, and what evidence you receive. |
| Existing content | An inventory of pages and files, decisions about what moves, and a plan for changed URLs. |
| Accounts and ownership | The domain registrant, authorized administrators, billing owner, and contractual rights to content, data, and software. |
| Private information | Separate permissions for public pages and restricted records, plus a demonstrated account-removal process. |
| Training and support | Included training, written instructions, support hours, response targets, and work that costs extra. |
| Ongoing costs and exit | Recurring charges, renewal terms, export options, and the steps and charges involved in leaving. |
Keep a separate list of non-negotiables. For example: your organization retains control of its domain; two approved people can recover administrative access; and someone is responsible for answering membership inquiries. Ask the provider to explain any condition it cannot meet.
Watch a volunteer-sized demonstration
Bring a sample event and an approved announcement. Ask the provider to demonstrate the proposed editing experience using those examples, not just a prepared sales slideshow.
Have the person who will maintain the site try the workflow where possible. Can they identify the correct page, preview a change, fix a mistake, and find help? If approval is required, show that step too. Confirm which parts are available now and which would be built for your project.
Then test the public result on a phone. Can a visitor find the next meeting without opening a large flyer? Can they contact the detachment without guessing which officer is responsible? Does the form explain what happens after submission?
For an initial accessibility check, review headings, image alternatives, keyboard access, text resizing, and form labels. W3C's Easy Checks explains these starting points and warns that passing them is not a complete accessibility assessment. Ask for the more thorough testing appropriate to the agreed scope. W3C Easy Checks
Put ownership and the leadership handoff in writing
Before signing, identify the domain, hosting, website administrator accounts, email services, and any connected tools. For each, record the organization responsible, approved administrators, billing contact, and recovery procedure. Keep credentials out of ordinary meeting notes and public documents.
Clarify the difference between owning your content and owning all software used to run the site. A hosted platform or licensed component may have separate terms. Ask what you can export, in which format, and whether another provider can use that export without rebuilding everything.
Make the handoff part of acceptance: an incoming authorized volunteer should be able to locate instructions, request the correct access, complete a routine update, and reach support. Pair new responsibilities with the knowledge of experienced members. The goal is continuity, not pushing the people who built the detachment out of the process.
Ask what happens to your old pages and links
Your existing site may contain useful program information, newsletters, and links people have saved. Ask for a page-and-file inventory before approving migration costs.
Decide what stays, what needs revision, what moves to a relevant replacement, and what is retired with your approval. When URLs change, request a mapping and appropriate redirects, then test important old links. Google recommends planning URL mappings and monitoring a site move, and notes that search rankings can fluctuate during migration. No provider should promise that a redesign will preserve every ranking. Google's site-move guidance
Also test the things members depend on: contact forms, donation or payment links, event details, and downloadable documents. A homepage approval is not a launch checklist.
Compare the agreement, not just the design
Ask each finalist for the same written summary: included pages and workflows, migration limits, responsibilities, timeline dependencies, acceptance tests, training, recurring charges, and exclusions.
For references, ask what the provider actually delivered and whether it still supports the project. A concept design, a public website, and a working member portal are different evidence. If you need a particular capability, request proof of that capability rather than assuming it exists because a related project looks good.
Before the vote, make sure your team can answer: What are we buying, what will our volunteers do, and what happens after launch?
Frequently asked questions
Does an MCL detachment need a member portal?
Not automatically. If your main problem is outdated public information, a manageable website may be the right first phase. Consider a member or officer workspace when you can name the restricted information, recurring tasks, responsible people, and access rules it must support.
Should the website replace our national membership system?
Do not assume that it should. Document what the existing system handles and what remains a local responsibility. Any replacement or data connection needs specific agreement and authorization. A public inquiry form should not imply that submitting it grants membership.
What should we request before choosing a provider?
Request a task-based demonstration, a written scope, an ownership and access summary, a migration plan, training details, and an itemized account of startup and recurring costs. Resolve the must-haves before comparing optional features.
Bring a clear brief to your website assessment
Start with your current website, the three tasks that need improvement, and the people responsible for updates. Review Geek Heros websites for veteran organizations, then request a free Website & Digital HQ Assessment.
The form requests follow-up by email to arrange a conversation; it does not book a meeting or commit your detachment to a purchase. Geek Heros is an independent provider, not a National Marine Corps League-endorsed service.