Websites, tools, and research.
We design and build accessible public sites, then add the booking, intake, member, or internal tools the job calls for. Research is available when the work depends on understanding an employer, a market, or the public record.
Accessible websites, built with care
Public sites designed to read clearly, load quickly, and hold up as content changes. On WordPress, your team updates hours, prices, events, and statements without waiting on us, and the design holds while they do. We target WCAG 2.1 AA from the first commit and include Section 508 when the work requires it.
Custom tools, platforms, and integrations
Backends for the part of the job nobody wants to manage by hand: member tracking, portals, schedulers, intake and subscription forms, and role-gated internal tools. When something needs to reach people, reminders, confirmations, alerts, it goes out by email or text on a system your team controls, wired to the services you already use. The union we organize with runs this kind of system in production.
Large builds and content migrations
Sites with thousands of pages, moved and rebuilt without losing the content, the links, or the search ranking, and left faster and more accessible than the site they replace. Structured content and bulk migrations are scripted and checked on a staging copy before anything goes live.
Hosting and infrastructure you own
Your site runs on foundations you own and can move: reproducible from source, portable off any single host, and monitored so problems surface before your visitors do. Nothing is locked to us or to one vendor, and the handoff is documented from day one. This is how we run our own.
Employer and market research
Employer profiles, ownership and money trails, contract research, and public-records work for campaigns and unions. Market and competitor research for businesses. The result is written for the decision in front of you, with the sources attached.
The build should fit the way you work.
A proposal should make the important choices clear: who edits the site, how much custom behavior it includes, and where it will run. We settle those questions before we price the work.
Who makes routine edits
- WordPress site
- Best when your team wants to publish routine updates itself. We give the editor structure, so hours, news, staff, and pages do not require a developer.
- Custom-coded site
- Best when the design, speed, or interaction calls for a tighter build. Your team does not edit the code; routine changes usually come through the ongoing plan.
How much app you need
- One job, done properly
- Something your team currently does by hand: taking bookings, collecting intake, quoting a price. Often this is a custom extension inside WordPress rather than a separate app, so it lives in the site your staff already knows.
- Somewhere people sign in
- For a group that comes back. Members see what is theirs and update their own details, which is mostly a way of getting your staff out of doing it for them over email.
- A view of your own data
- What you already collect, in one place, when there is a real decision riding on it. If nobody would act differently for having seen it, we will tell you that and save you the build.
Where it runs
- Your preferred host
- If procurement or an existing IT setup decides the host, we build for it and document the handoff.
- Our managed server
- A practical fit for most ongoing sites and small apps. We manage the server, updates, monitoring, and backups as part of the plan.
- Managed platform
- For institutional support requirements, stricter isolation, or vendor-backed service levels. It costs more, and sometimes that is the right trade.
Wherever it runs, the ongoing work is the same: keeping the site secure, available, and accessible as its content changes.
Ongoing care, scoped to the build
- Managed hosting, security updates, and backups
- Accessibility checks when standards, code, or site content changes
- A named point of contact who answers within one business day, not a ticket queue
- Routine content changes on custom-coded sites, plus WordPress help when your team wants it
- Performance and uptime monitoring, with follow-up when something fails
- A documented handoff for the domain, site, and accounts if the engagement ends
Accessibility is part of the build, not an add-on.
We target WCAG 2.1 AA across public sites and include Section 508 where the work requires it.
How we build accessible sites →Start with what the site needs.
Some clients need a new build. Some need ongoing care for the site they already have. Often, it is both. The scope and price follow from what needs to change and what needs ongoing support.
Project build
You send us what you have. We review it, ask what we need to ask, and come back with a scope, a timeline, and a number within three business days of the call. If we are not the right people for the job, we say so then, not after a deposit.
Build plus ongoing plan
How most engagements run. The build lands, then the site stays secure, available, and accessible as its content changes and as the standards move. The build is the same build; this is what happens after launch.
Ongoing plan only
You already have a site and you are not rebuilding it. We take over hosting, updates, monitoring, and accessibility checks on the site you have. If a rebuild is genuinely the right call we will tell you, but it is not the price of getting help.
Not sure which one you are in? Tell us what you have and we will say so.