Skip to main content
Plant Powered Pixels

Site menu

FAQ

The questions people actually ask.

Straight answers, most-asked first. If yours isn't here, ask it on a call. We'd rather tell you plainly than have you guess.

Can I edit the site myself, or do I have to call you for every change?

On a WordPress build, you can change routine content yourself: hours, prices, and photos for a storefront; events, statements, leadership, and campaign pages for an organization. On a custom-coded site, routine edits usually come through the ongoing plan instead. We tell you which model we're proposing, and who will make each kind of change, before work starts.

What's actually included?

Depends on the work. It can be a public site, a booking flow, a members-only portal, a custom app with a real backend, employer or market research, or some combination. We scope it to what you need, not to a package, and we tell you plainly what's in and what's out before you commit.

What's included in the monthly?

Hosting and security updates, accessibility upkeep, performance and uptime monitoring, and a real person who answers when you email. Routine content changes are handled for custom-coded sites; WordPress clients can make them directly and can still send us the ones they'd rather not handle. The agreement spells out ownership and includes a documented handoff if we part ways.

What's a typical timeline?

A focused site is usually weeks, not months: for a local business, a few weeks from kickoff depending on how much content you have ready. Apps with a custom backend take longer, and research runs on its own clock. We give you a real timeline up front, not a vague "soon," and when something has to be live before a launch or a press call, say so and we'll plan around it.

What technology do you build on?

We use WordPress when your team needs a familiar editor and a custom-coded build when the design, interaction, or data work calls for it. Either way, the site has to load fast, stay portable, and meet accessibility standards. We explain the recommendation in plain language before you commit.

Can't we just add an accessibility overlay?

No, and we'd steer you away from paying for one. A script bolted onto a finished page can't cover what a real audit or a Section 508 review looks at, automated fixes reach only part of the standard, and the people overlays are meant to help often switch them off. So you can pay for the tool and still carry the risk. Compliance that holds up comes from fixing the site itself and testing it by keyboard and screen reader, which is the work we do. How we build accessible sites.

What happens if we part ways?

Our standard agreement is structured so you keep the site, domain, content, and commissioned research, subject to any third-party licenses named up front. We document the handoff so another developer can pick it up instead of locking the work inside something only we can run.

You've never worked with someone exactly like us.

Maybe not, and we'll say so plainly. Lincoln builds web applications for a public research program at UCLA, and we built and still run the organizing platform for our own union. Those are different environments, but both require tools that stay usable, accessible, and maintained. We'll be just as clear about the parts of your project that are new to us.