Some of our takes might be new to you. We won't waste your time with another “everything about tech” FAQ. Instead, these are questions we actually get.

Web. AI. Marketing. Product Management. DO/IT. And Coaching, too. In the Ehven Consultants way!

What kinds of projects do you actually take on?

We work across six Areas of Interest: AI, Coaching, DO/IT, Marketing, Product Management, and Web.

Most engagements begin in one primary area, but real projects are rarely polite enough to stay in one lane. A Web project may need DO/IT release and access work. A Marketing engagement may need Product Management structure. An AI rollout may need Coaching and governance support. That is normal, expected, and accounted for in the way we scope and assemble work.

How do your Features work?

Everything we deliver is assembled from discrete packages that we call Features.

A Feature is not just a loose idea or a sales label. It is a defined unit of delivery that may include a Demo, Build Package, Test Suite, Developer Guide, Success Kit, Care Kit, and Pricing Pair. Some Features are included as part of the base structure of a project or engagement. Others are added only when they are actually needed.

This approach improves scope clarity, reduces ambiguity, supports stronger handoffs, and makes growth easier to plan without turning every change into a small diplomatic crisis.

What is a Pricing Pair?

A Pricing Pair is the two-part pricing structure attached to a Feature.

One number covers initial implementation or engagement work. The other covers ongoing care, continuity, or maintenance where applicable. Even when one side of that pair is $0, we still treat the pricing structure explicitly rather than hiding it behind mushy bundles or vague promises.

This helps separate build cost from ongoing support cost, which in turn reduces surprise spending and makes planning far more realistic.

What is included in Care and Maintenance or Care and Continuity?

Care is the ongoing operational layer that supports a project or engagement after the initial implementation work is done.

Depending on the type of work, that may include tested updates, reviews, reporting, monitoring, regression testing, progress review, office hours, followup guidance, operational support, and other continuing responsibilities. Care is not the same thing as implementation. It is the layer that helps the work stay healthy, current, and supportable over time.

In short: implementation builds it; care keeps it from turning into a museum piece or a fire drill.

What stays with us if we leave, and what does not?

Implementation Features are integrated into the project or engagement itself. Those deliverables generally remain with the project, even if you move to another provider.

Care Features are different. They are typically delivered through our own internal environments, processes, tooling, and operational practices. Because of that, many Care Features do not travel automatically with the project when it exits our ecosystem. In some cases, portions of that support can be adapted for handoff or exit, but that usually requires separate scoping and, in some cases, an Exit Package or equivalent transition work.

We do not believe in fake portability claims. Portable means portable. Provider-dependent means provider-dependent.

When is WordPress the right choice, and when is it not?

WordPress is often an excellent fit for content-rich, workflow-heavy, feature-extensible projects. It is especially strong when editorial flexibility, publishing breadth, ecosystem maturity, and administrative familiarity matter.

It is not automatically the right answer for every project. Some projects are better served by Astro.js, Webflow, headless patterns, or other approaches, depending on performance needs, editorial model, deployment strategy, staffing reality, and growth expectations.

We do not force every project into WordPress just because it is popular. Platform choice should be driven by fit, not by habit.

Are page builders a good idea for our site?

Sometimes yes. Sometimes absolutely not.

Page builders can speed delivery, expand content-editing flexibility, and reduce dependence on developers for certain kinds of routine changes. They can also create performance drag, maintenance friction, editing chaos, portability problems, and unnecessary complexity when overused or used without discipline.

The right question is not whether page builders are good or bad in the abstract. The right question is whether they are a good fit for your content model, performance requirements, team capabilities, design system, and long-term maintenance reality.

Is WordPress secure enough for serious work?

Yes, WordPress can absolutely be secure enough for serious work.

The catch is that security does not come from the logo on the box. It comes from disciplined implementation and disciplined operations: hardening, access control, sane component choices, tested updates, backup and recovery planning, logging, and ongoing review.

A properly run WordPress project can be very strong. A casually assembled one can become a liability. The difference is not magic. It is method.

Should our WordPress site update automatically?

Automatic updates are a tool, not a complete policy.

Some updates are low-risk enough for controlled automation. Others should be tested before deployment because they can affect compatibility, performance, workflow, or revenue-producing functionality. The more moving parts a project has, the more foolish blind updating becomes.

Our preference is not “update nothing” and not “update everything instantly.” Our preference is tested updates, with rollback thinking and real operational judgment behind the process.

How do you keep projects affordable to run over time?

We keep long-term costs under control by making good decisions early and boringly responsible decisions later.

That means clear scope, modular Feature packaging, standards-based implementation, sane platform choices, maintainable component selection, explicit care pricing, and steady operational routines instead of neglect followed by panic spending. It also means resisting the temptation to solve every short-term problem with another fragile dependency.

Cheap at launch and expensive forever is not a bargain. We prefer durable value over decorative savings.

How do you keep projects usable for nontechnical staff?

We do not assume that a technically successful implementation is automatically a humanly successful one.

Usability for real teams often requires cleaner admin experiences, stronger defaults, clearer workflows, better documentation, practical training, and sometimes coaching or rollout support. We also favor structures that reduce fear and reduce accidental breakage, because “please do not touch anything” is not a serious operating model.

Good systems should help your team work. They should not demand that your team become amateur archaeologists.

Why do standards and portability matter so much?

Because they reduce fragility, reduce provider lock, improve supportability, and protect your future options.

Standards make it easier to update, easier to hand off, easier to expand, easier to train new staff, and easier to recover when something goes wrong. Portability matters for the same reason. A project should not become a hostage just because it was implemented by a particular provider, including us.

We take standards seriously not because we enjoy paperwork, but because we enjoy avoidable disasters even less.

How do you handle AI safety, grounding, and governance?

We do not treat AI as a toy, a magic trick, or a substitute for judgment.

Useful AI systems require grounding, guardrails, review logic, model and vendor evaluation, testing, and governance that matches the actual risk of the use case. In some cases, that also means human oversight, escalation rules, and explicit limits on what the system is allowed to do.

The goal is not merely to make AI impressive. The goal is to make it useful, reliable, and safe enough for the work it is actually supposed to perform.

Can you help our team adopt the work after launch?

Yes.

Implementation alone is often not enough. Teams may need onboarding, orientation, notes and action plans, followup support, workshops, coaching, rollout guidance, or additional training as the work becomes part of daily operations. That is especially true when the project introduces new workflows, new automation, new AI usage, or new cross-team responsibilities.

Adoption is not an afterthought here. It is part of delivery maturity.

Do you work with agencies, freelancers, and internal departments?

Yes.

We work directly with project owners and organizations, but we also support agencies, freelancers, and internal departments that need specialized implementation, strategy, care, or operational backup. Some engagements are entirely direct. Others are collaborative. Others still are structured so that we handle a very specific segment of the work while another team leads the broader initiative.

This flexibility matters because real delivery environments are often multi-party. Pretending otherwise only creates avoidable friction later.

What happens at launch, handoff, or exit?

Launch is a controlled process, not a leap of faith.

Handoff and exit are also structured events, each with their own responsibilities, deliverables, risks, and limitations. Depending on the project, that may include access changes, release steps, documentation, training, backups, validation, provider coordination, rollback planning, and transition support. It may also include a distinction between what is integrated into the project itself and what depends on our ongoing operational environment.

A clean launch is good. A clean handoff is also good. A clean exit, when needed, is part of treating provider relationships like adults.

Still not sure? Start here.

If your exact question is not listed above, that does not mean we cannot help. It usually means your situation crosses more than one discipline, which is normal.

Tell us what you are trying to accomplish, what is already in place, and where things feel unclear, overloaded, risky, or stuck. We will help you identify the most relevant path, without forcing the conversation into a fake one-size-fits-all answer.