Questions deserve complete,
plain-language answers.

Start with the narrowest useful task and the least-privileged tool set. Read-only steps can often run automatically, while payments, publishing, record deletion, account changes and other consequential actions should require explicit approval until evaluations and production evidence justify a broader boundary.

Treat webpages, documents, emails and tool responses as untrusted data rather than instructions. The agent should receive task-specific context, approved tool schemas, server-side authorization, output validation and confirmation gates for irreversible or high-impact actions.

Build a representative evaluation set covering normal tasks, edge cases, refusal behaviour, tool selection, argument accuracy and recovery from failure. Measure task completion and harmful side effects, then keep regression evaluations and trace review in the release process.

Common integrations include CRMs, help desks, databases, browsers, document stores and internal APIs. Access should use scoped credentials, explicit tenant and role checks, rate limits, audit logs and idempotent actions rather than giving a model unrestricted system access.

The main drivers are workflow depth, number and quality of integrations, data sensitivity, approval rules, evaluation coverage, latency targets, observability and the amount of human review required. A bounded pilot is usually more estimable than an open-ended request for a general autonomous agent.

A bounded single-task agent is commonly a matter of weeks. Agents with retrieval, multiple integrations or approval workflows typically run to several months, and multi-agent systems with compliance and audit requirements longer again. Evaluation and guardrail work usually takes more calendar time than the agent logic itself.

Model usage per task, infrastructure, and maintenance as provider models, APIs and business rules change — commonly estimated at fifteen to thirty percent of build cost annually. Modelling cost per successful task rather than per API call is what makes the economics legible.

That is usually the more reliable design. The agent handles the bounded, repetitive portion and escalates anything uncertain or consequential, with a person retaining approval. It also produces better evaluation data, because human corrections show exactly where the boundary is currently wrong.

Retrieval-augmented generation is useful when answers must use changing private knowledge and show sources. Fine-tuning is better suited to stable behaviour or style; it does not by itself provide current facts, permissions or reliable citations.

Improve document parsing, chunk boundaries, metadata, access filters, hybrid retrieval and reranking before changing the prompt. Evaluate retrieval recall and answer faithfulness separately so a missing source is not confused with a generation problem.

It should filter retrieval with the authenticated user's organization, role and document permissions before content reaches the model. Application authorization remains mandatory even when the vector database supports metadata filters.

A citation should point to the exact source, section or page that supports the statement and remain accessible to the authorized user. Generated references that cannot be opened or do not entail the answer should fail evaluation.

Build cost is driven by document variety, access-control requirements and evaluation depth rather than document count. Running cost is per query — embedding, retrieval and generation — so it scales with usage. Caching, smaller models for simple queries and limiting retrieved context are the levers that control it.

Almost always a retrieval failure rather than a generation failure. If the right passage never reaches the model, it answers from general knowledge. Measure retrieval recall separately from answer quality — teams frequently rewrite prompts for weeks when the actual problem is chunking or document parsing.

Treat ingestion as a pipeline, not a one-off upload: change detection, re-embedding on update, deletion propagation and a visible last-indexed timestamp. Stale answers destroy trust faster than missing ones, so it should be obvious to users how current the underlying source is.

Not if permissions are applied at retrieval. Filter candidate documents by the authenticated user's role and access before anything reaches the model, and test it deliberately. Relying on the model to decline is not access control, and vector database metadata filters do not replace application-level authorisation.

Version prompts, models, retrieval settings and output schemas, then run a representative regression suite before release. Production traces, user feedback and failure categories should feed the next evaluation set.

That depends on the cost of a wrong answer and whether the result can be verified. Low-risk suggestions may be immediate; policy, financial, medical, legal or irreversible outputs need stronger evidence, constraints and human approval.

Minimize the data sent, separate tenants, redact where practical, apply retention controls and document every provider and storage boundary. Provider terms do not replace application-level access control, logging and deletion procedures.

Route simple tasks to smaller models, limit context to task-relevant evidence, cache only safe reusable results and measure cost per successful task. Timeouts, retries and fallbacks should be designed around the user journey rather than hidden behind an indefinite loader.

A contained feature over existing data is typically a matter of weeks; anything touching sensitive data, needing approval workflows or requiring high accuracy takes considerably longer because evaluation and guardrails dominate the effort. Ongoing model usage is a recurring cost that should be modelled per successful task, not per request.

Constrain the task rather than relying on instructions alone: structured output schemas, validation before anything is displayed or acted on, refusal boundaries, and human approval for consequential actions. Test adversarial inputs deliberately as part of the evaluation set rather than discovering them in production.

Provider models are retired on their own schedule, so pin versions explicitly and keep a regression suite that can be rerun against a replacement. Treating the provider as a swappable boundary behind your own interface reduces the work, though prompts and behaviour still need re-validation.

Define what a successful task looks like before launch, then measure completion rate, correction rate, escalation rate and cost per successful outcome. Usage volume and user satisfaction scores are weak proxies — a feature can be heavily used and quietly wrong.

OCR turns visible characters into machine-readable text. Document intelligence also interprets layout, document type, tables, key-value relationships and field meaning so the result can enter a validated business workflow.

Start with representative scans, digital PDFs, rotations, languages, attachments and template variants. Preserve page regions and reading order, define normalized field schemas, and test each important document cohort instead of relying on one clean sample.

Review rules should combine field importance, model confidence, cross-field validation and business risk. A low-confidence postcode may be recoverable automatically, while an uncertain bank amount, identity field or contractual term normally needs a person and the source image beside it.

Yes. Consequential values should retain the source page, region or quotation, processor version and correction history. This provenance makes quality checks, audits and disputed records much easier than storing flattened OCR text alone.

Define where files are processed, who can access them, encryption and deletion rules before choosing a model or cloud service. Accuracy should be measured per required field and document cohort, including false acceptance and human-review rates—not as one headline OCR score.

It varies sharply by field and document cohort, so a single headline figure is not meaningful. Clean digital PDFs with consistent layouts reach high accuracy on structured fields; handwriting, poor scans and variable templates do not. Accuracy should be measured per required field, with false acceptance reported separately from overall extraction rate.

Off-the-shelf tools are appropriate for common document types with standard fields and no unusual workflow requirements. Custom work earns its cost when documents are non-standard, when extraction must feed a validated business process with defined review rules, or when data residency and retention constraints rule out a hosted product.

They need an explicit path, not a silent failure. Unreadable files, unrecognised types and low-confidence extractions should route to a review queue with the source document visible beside the extracted values, so a person can correct and release them without leaving the workflow.

Use recordings that represent actual speakers, devices, background conditions and domain terms. Measure word and entity accuracy separately because names, amounts and action items often matter more than general transcript fluency.

Yes, but streaming requires latency, interruption and partial-result handling, while batch processing can prioritize throughput and reprocessing. The product should make provisional and finalized text states clear.

Diarization, channel separation and word timestamps depend on the audio format and model. Validate them on overlapping speech and preserve original audio references when the transcript becomes evidence.

Obtain appropriate consent, restrict access, encrypt files and define retention and deletion rules for both audio and derived text. Redaction and regional processing may be required for sensitive calls or regulated workflows.

Provider pricing is usually per minute of audio and falls with commitment. The larger cost at scale is often the surrounding workflow — storage, review, redaction and integration — rather than the transcription itself. Self-hosting can be cheaper at high sustained volume but adds real operational responsibility.

Speaker diarisation and language identification are supported by most current models but degrade with overlapping speech, poor microphones and code-switching mid-sentence, which is common in multilingual settings. Test on your actual recordings rather than clean samples before committing to a provider.

That depends on the data and jurisdiction. Regional processing endpoints, self-hosted models and on-device options all exist with different cost and accuracy trade-offs. Consent, retention and deletion rules should be settled before choosing, because they can rule out otherwise attractive providers.

Compare providers on representative tasks, structured output and tool behaviour, latency, availability, context needs, data terms and total cost per useful result. Public benchmarks alone rarely predict product performance.

A provider boundary, shared task schema and regression suite reduce coupling, but models are not drop-in equivalents. Prompts, tool calls, safety behaviour and token economics still require measured adaptation.

Set task-specific timeouts, bounded retries and an honest fallback such as a queued job, smaller model or human route. Record the provider and model version so incidents and quality changes can be diagnosed.

That depends on the provider, product tier and contract in force. Confirm current retention and training controls, minimize submitted data and document any subprocessors instead of assuming one policy applies to every endpoint.

Test them on your actual task rather than trusting benchmarks. Compare structured output reliability, tool-calling behaviour, latency at your context length, availability, data terms and cost per useful result. Providers differ more in behaviour under constraint than in headline capability.

Route simple tasks to smaller models, keep context to what the task needs, cache safe reusable results, and set per-tenant limits. Measure cost per successful outcome rather than per call — a cheaper model that fails a third of the time and triggers a retry is not cheaper.

Self-hosting makes sense at high sustained volume, with strict data residency requirements, or where a fine-tuned smaller model genuinely outperforms a general one on your task. It shifts cost from per-token to infrastructure and staff, and you take on capacity planning, updates and uptime.

A frequent, rules-based workflow with clear inputs, a known owner and measurable exceptions. Automating an unstable or undocumented process makes errors faster and harder to trace. If people cannot agree on how the process currently works, that disagreement has to be resolved before any tool is chosen.

Zapier and Make suit straightforward connections a non-developer will own. n8n suits more complex logic and self-hosting where data cannot leave your infrastructure. Custom code is right when the workflow is core to the business, needs proper testing, or platform per-task pricing becomes uneconomic at your volume.

The build follows the number of systems, rule complexity and how much exception handling is genuinely required. Platform subscriptions add a per-task running cost that scales with volume and is routinely underestimated. A workflow that changes every month costs more to maintain than to build.

That is a business decision, not a technical outcome, and it is usually the wrong framing. The reliable result is removing repetitive handling so the same people absorb more volume and spend time on exceptions and judgement. Automation without someone owning the exceptions moves work rather than removing it.

They need an explicit route, not a silent drop. Exceptions should reach a named person with enough context to resolve them, and the resolution should feed back into the rules. A review queue is part of the design, not an admission that the automation is incomplete.

Validate inputs before acting, make external actions idempotent, put approval gates on anything irreversible or high value, and roll out to a subset before running everything through it. Speed multiplies whatever the rules actually say, including the parts nobody checked.

Usually, through their APIs where they exist, and through file exchange or middleware where they do not. The practical questions are whether your plan tier includes API access — a common surprise — and whether your IT policy permits the credentials required.

This should be agreed before it is built. Someone needs to own alerts, exceptions and changes when a connected system updates. Handover should include documentation of the rules, credentials in your accounts, and a runbook for the failures that are known to be possible.

Webhooks deliver events promptly but are not guaranteed to arrive. Polling catches what webhooks miss. Scheduled batches suit bulk work where timeliness does not matter. Reliable integrations combine at least two of these with checkpoints and a reconciliation pass rather than trusting one delivery mechanism.

Nothing, if the integration is built for it. Every external action needs an idempotency key or a stable external identifier so a repeated event is recognised and ignored rather than creating a duplicate order, charge or record. Retries and provider re-deliveries make duplicates a certainty, not an edge case.

Nominate one system of record per field before any code is written, and make the conflict policy explicit — last write wins, source system wins, or flag for human review. Most sync problems are not technical failures; they are two systems both believing they own the same value.

Frequently, through database-level access, file exchange on a schedule, a small middleware service, or screen-level automation as a last resort. The real constraints are usually network access and credential policy rather than technical feasibility. Each approach has different fragility, which should be stated upfront.

Only if it was designed to tell you. Every workflow needs error handling, alerting to a named person, a record of which specific item failed and why, and a way to replay that item safely. Integrations that fail quietly are usually discovered weeks later through a data discrepancy.

Scoped service accounts with the narrowest workable permissions, secrets in encrypted storage rather than in code or a workflow tool's plain fields, rotation as a documented procedure, redacted logs, and only the fields the workflow genuinely needs crossing the boundary.

Beyond the build, there is platform or infrastructure cost, and maintenance as the connected systems change their APIs, authentication or data shapes. Third-party API deprecations are the main recurring driver. Budgeting nothing for maintenance is how integrations quietly stop working.

A single well-documented API with straightforward field mapping is a short project. Time is driven by the number of systems, how good their documentation and sandboxes are, how much data cleanup the mapping exposes, and how much exception handling the business genuinely needs — not by the number of endpoints.

Make is quicker for non-developers and fully hosted. n8n suits more complex branching, custom code steps, and cases where data cannot leave your infrastructure because it can be self-hosted. The deciding factors are usually who will maintain the workflows and whether self-hosting is a requirement, not the node count either platform advertises.

Self-host when data residency, compliance or per-execution pricing at your volume makes it worthwhile, and when someone will own the server. It is a real operational responsibility — updates, backups, queue mode for concurrency, and monitoring. Cloud hosting is the right default until one of those constraints genuinely applies.

Whatever you designed, which is why it needs designing. Without error handling a partial run leaves records half-processed with no record of where it stopped. Reliable workflows use idempotent steps, checkpoints, an error branch that alerts a named person, and enough context logged to replay a single failed item rather than the whole batch.

To a point. Per-execution pricing becomes the constraint before technical limits do, and heavily branched workflows get difficult to reason about long before they get slow. A common pattern is keeping orchestration visual while moving the heavy or high-frequency work into a service the platform calls.

Partially, and it is a real limitation. Both platforms support exporting workflow definitions as JSON, which can be committed, but restoring one is not the same as a code deployment and credentials live outside the export. Treat exports as backups and change records rather than as a full deployment pipeline.

Use the platform's credential store rather than pasting keys into node fields, scope each service account to the narrowest permissions the workflow needs, and rotate on a documented schedule. Self-hosted instances need their encryption key backed up separately, since losing it makes every stored credential unrecoverable.

Only if you built for it. Logic held entirely in proprietary nodes has to be rebuilt elsewhere. Keeping business rules in your own code or database, and using the platform mainly for triggering and transport, keeps the exit viable — worth deciding early, because retrofitting it means rewriting the workflows anyway.

This needs naming before they are built. Someone must own alerts, exceptions, and updates when a connected service changes its API. Handover should include the workflow documentation, credentials in your own accounts, and a runbook for the failures already known to be possible.

Map users, decisions, roles, data, integrations, current workarounds and measurable outcomes. Prototype the most uncertain workflow or technical dependency before turning every idea into a backlog.

A prototype tests an assumption and may be disposable. An MVP is a minimal operable product for real users, with essential validation, security, administration, measurement and support.

Use server-side validation, scoped credentials, idempotency keys, signed webhooks, bounded timeouts, retries and a reconciliation job that catches whatever slipped through. The interface needs matching states: pending, failed and recovered, shown honestly. An order must never depend on the customer's browser returning successfully from a payment page.

Include environment documentation, schema and migration history, build and deployment steps, test coverage, operating responsibilities, known limitations and access owned by the client—not only a repository archive.

Cost follows workflow depth, integration count, data sensitivity and how much of the surrounding operation has to change, not screen count. A bounded first release solving one journey is far more estimable than an open brief. Expect a discovery step to produce a defensible range; anyone quoting a fixed figure before understanding the data model is guessing.

Configure wherever a supported product already matches the process closely. Custom work earns its cost when the process is a genuine competitive difference, when licence costs scale badly against users, or when integration and data ownership requirements cannot be met by the product. The honest answer is often a hybrid.

You do. The repository, environments, credentials and deployment accounts should be in your organisation's name from the start rather than transferred at the end. Contracts should state IP assignment explicitly, and any third-party or open-source components should be listed with their licences.

Software needs an owner. That means monitoring, dependency and security updates, defect response, and a route for changes as the operation evolves. Scope should name who does each of those, what response time applies, and what happens if you later move the work in-house or to another supplier.

Start by trying to buy it. If a supported product covers the process closely and the objection is cosmetic, buy it — configuration is always cheaper than construction. Custom work earns its cost in three situations: the process is genuinely part of how you compete, licence costs scale badly against your user count, or integration and data ownership requirements exceed what the product permits. A fourth situation is worth naming because it is common and it is a trap: the process itself is undefined, and software is being asked to settle an argument nobody has had. That never works, and it is expensive to discover late.

A prototype tests one assumption and is meant to be thrown away — it can be ugly, hardcoded and unsafe because nobody real will use it. An MVP is a minimal operable product for actual users, which means it still needs authentication, authorisation, error handling, a way to see what people are doing and a route to fix bad data. Version one is what you build once the MVP has told you which assumptions were wrong. Conflating the first two is the most expensive mistake in this sequence: building an MVP to prototype standards produces something that cannot be operated, and building a prototype to MVP standards wastes months proving something you could have learned in a week.

Frequently, and it often produces a better result than replacing them, because they hold context nobody else has. What makes it work is a clear boundary — which system, which repository, which decisions belong to whom — and agreement on how code is reviewed and merged. What makes it fail is ambiguity about ownership, especially when something breaks and two teams each assume the other was watching. Access to environments and repositories needs settling at the start rather than negotiated per task, and it is worth agreeing early how disagreements about technical direction get resolved, because they will happen.

By reducing what is unknown before quoting, rather than padding a number to cover it. Requirements that are genuinely settled can be estimated with reasonable confidence. Requirements that are not — an unfamiliar integration, an undefined process, an unproven assumption about users — get a paid discovery step that produces a defensible scope. A fixed price quoted against uncertainty does not survive contact with the real system; it either gets renegotiated, which damages trust, or gets delivered thin, which damages the product. The honest sequence is to make the uncertain parts certain first, then price the rest.

Nothing, because it was never held anywhere you do not control. Repository, environments, database, domain and third-party service accounts should be in your organisation's name from the first day, not transferred at the end. Source code is delivered with schema and migration history, deployment steps, environment documentation and known limitations. The practical test of a handover is whether a different developer could take over from what you were given, without needing to ask us anything — and that is worth confirming during the project rather than at the point you need it.

It varies with what the system does, but a common planning figure is fifteen to twenty-five percent of build cost annually — and budgeting nothing is how working software becomes unsupportable. That covers dependency and security updates, defect response, monitoring, backups with tested restores, and the small changes every system needs as the business changes around it. Software that sits untouched for a year usually needs significant remedial work before it can ship again, because dependencies move, platforms deprecate APIs and security disclosures accumulate. Continuous small maintenance is consistently cheaper than periodic catch-up.

Usually, and it starts with an audit rather than a quote. That means establishing what it runs on, whether the source is complete, whether it can be built and deployed from scratch, what the dependency and version state is, whether backups actually restore, and what is undocumented. The audit is chargeable work and produces a written risk picture. The complications that matter are undocumented modifications, dependencies that can no longer be installed, and environments nobody can reconstruct — each of those needs a decision before an ongoing arrangement means anything.

As a build requirement rather than a review at the end. Server-side authorisation on every request regardless of what the interface prevents, validated input at every boundary where untrusted data enters, parameterised queries, secrets in encrypted storage with a documented rotation procedure, and dependency scanning in the pipeline. Beyond the code: least-privilege access to environments, audit logging on consequential actions, and a tested restore path. The gaps that show up most often in real systems are not exotic — they are missing authorisation checks on endpoints nobody expected to be called directly, and credentials that were committed once and never rotated.

Not if the project is set up correctly, and you should treat that as a requirement rather than a courtesy. Standard technologies with a real hiring pool rather than an unusual stack only we understand. Documentation written for someone who was not in the conversations. Accounts and repositories in your name throughout. No proprietary framework you would have to keep paying for. The measure is simple: if you decided tomorrow to move to another developer, how long would it take them to become productive? If the answer is more than a couple of weeks, something was built wrong.

Weeks rather than months, if the project is sequenced properly. Building in vertical slices means each release completes one journey end to end — genuinely usable rather than a layer that does nothing on its own. That matters because it lets you correct direction while correction is still cheap, and because a working thing generates far better feedback than a specification does. Projects that reveal everything at the end are the ones that overrun, since every misunderstanding compounds silently until it is expensive to unpick.

They will, and that is normal rather than a failure of planning. What matters is that changes are decided rather than absorbed. Each one gets assessed for its effect on scope, timeline and cost, then explicitly accepted or deferred. Projects overrun not because requirements changed but because they changed invisibly — a small addition here, a reasonable extra there, none individually worth a conversation, collectively consuming the budget. Making the trade visible each time keeps both sides in control of it.

For anything customer-facing, usually yes, and the cost of skipping it appears later as support tickets and abandoned journeys. For internal tools the answer is more nuanced — a competent developer working from a component library often produces something perfectly usable, and paying for bespoke visual design on a screen five staff use daily is rarely the best allocation. What cannot be skipped either way is thinking about the task: what the user is trying to finish, what information they need at each step, and what happens when something goes wrong.

By testing the conditions that occur in reality rather than the path that was demonstrated. Permissions and roles, invalid and malicious input, third-party services failing or timing out, weak networks, real devices, accessibility with keyboard and screen reader, and data quality on representative records rather than clean samples. Automated tests cover the paths that would cost money if they broke. Manual testing covers what automation cannot judge. The happy path is the easiest thing to get right and the least useful thing to test exclusively, which is why demos are a poor proxy for readiness.

Usually, and the technical feasibility is rarely the constraint. The real questions are whether your plan tier includes API access — a surprisingly common blocker — whether the API is documented and has a sandbox, and whether your IT policy permits the credentials required. Legacy or on-premise systems without an API can still be integrated through database access, file exchange or a small middleware service, with different fragility trade-offs that should be stated upfront rather than discovered. Every integration also needs failure handling designed in: retries, idempotency and reconciliation, not just a working connection.

Source code with its full history, database schema and migration record, environment configuration and how to reproduce it, build and deployment steps including rollback, test coverage and how to run it, operating responsibilities, known limitations and outstanding issues, and credentials for accounts already in your name. A repository archive is not a handover. The standard worth holding to is that a developer who has never spoken to us could set the system up, deploy a change and recover from a failure using only what was provided.

Almost never, and the instinct to do so has probably wasted more startup budget than any other technical decision. Architecture built for imagined future volume is slower to build, harder to change and usually wrong about where the load will actually appear. Build for the users you have with sensible foundations — clean boundaries, sane data modelling, no obviously quadratic queries — and measure. Scaling problems are real problems with real solutions, and they are far cheaper to solve when you can see them than to guess at in advance.

Then stopping is the correct outcome, and it should be possible without losing everything spent. Building in slices means there is always a working state to stop at, and testing the riskiest assumption first means the bad news arrives while the investment is still small. That is the entire point of sequencing risk early rather than saving the hard part for last. A supplier who cannot tell you that something is not working, or who keeps building on momentum after the evidence has turned, is more expensive than one who says it plainly.

The first release should complete one valuable end-to-end journey and test the riskiest business assumption. It still needs the minimum authorization, administration, measurement, recovery and support tools required to operate safely.

Use tenancy when customer organizations, isolated data, memberships and organization-level settings are part of the validated model. It adds authorization, billing and operational complexity, so it should not be introduced only because the word SaaS is used.

Treat payment events as asynchronous, verify webhook signatures, make processing idempotent and reconcile provider state. Product entitlements should be derived through a clear policy rather than scattered UI checks.

Organization-scoped authorization, invitation controls, audit logs, secure support access, rate limits, data export and deletion, secret rotation and tested tenant-isolation failures are frequent gaps beyond login itself.

A focused first release completing one valuable journey is commonly a few months rather than a few weeks, because even a minimal product needs authentication, authorisation, billing, administration and support tooling. The timeline is driven by integration complexity and how settled the business rules are, not by page count.

Keep entitlement logic separate from the payment provider. Treat provider events as asynchronous and idempotent, verify webhook signatures, and reconcile against provider state on a schedule. Derive what a customer can access from one policy layer rather than scattering plan checks through the interface.

Every query scoped by tenant at the data layer rather than in the UI, authorisation checked server-side on every request, and tests that deliberately attempt cross-tenant access. Shared caches, background jobs, exports and search indexes are the places isolation most often leaks.

Build both early. Export needs a complete, documented format covering all of a tenant's records. Deletion needs a defined scope — what is removed, what is retained for legal reasons, how long backups hold copies — and it should be tested, because discovering it does not work during a compliance request is expensive.

Keep data fetching and non-interactive UI on the server by default, then add small client boundaries for state, browser APIs and immediate interaction. This reduces shipped JavaScript without sacrificing the required experience.

Choose from data freshness, personalization and invalidation ownership. Stable marketing content can be prerendered or revalidated, while authenticated or request-specific data normally belongs in dynamic server rendering.

Yes. Self-hosting needs a supported Node or container runtime plus explicit handling for reverse proxying, cache coordination, image optimization, persistent assets, process management and zero-downtime releases.

Inventory URLs, content, metadata, interactive behaviour and integrations, then move complete journeys while preserving server-rendered search signals. Test redirects, canonicals, analytics and forms before switching traffic.

For content that must be indexed, generally yes, because Next.js renders HTML on the server so crawlers and AI agents receive content without executing JavaScript. A client-rendered React app can be indexed but depends on rendering behaviour that varies by crawler. For an authenticated dashboard the distinction rarely matters.

A small marketing site can run on inexpensive shared or platform hosting. Costs rise with server rendering volume, image optimisation, function invocations and bandwidth. Self-hosting on a VPS trades platform fees for operational responsibility — process management, caching, zero-downtime releases and image handling all become yours.

Default to Server Components, add client boundaries only where interaction genuinely requires them, and check the bundle analyser rather than assuming. The common causes of bloat are a date or icon library imported wholesale, a client boundary placed too high in the tree, and third-party scripts added without a budget.

It can, with caveats. You need a supported Node runtime, a persistent process manager, and a reverse proxy configuration. Image optimisation and caching behave differently from a managed platform and often need explicit configuration. It works, but treat deployment and recovery as a designed procedure rather than an upload.

Usually re-renders or bundle size rather than computation. Profile before changing anything: look for state held too high in the tree, context values recreated each render, large lists without virtualisation, and libraries imported whole. Memoisation added without a measurement typically adds complexity and no speed.

When genuinely shared across unrelated parts of the tree and not derivable from the server. Server data belongs in a caching layer rather than a global store, since it needs invalidation and staleness handling. Much of what ends up in a global store is either server cache or state that should have stayed local.

A library is usually right for internal tools and early products, where speed matters more than a distinct visual identity. Build your own when the brand expression is part of the product or when accessibility and interaction behaviour need to be exactly specified. Either way, accessibility still needs testing.

Clear component contracts, colocation of related code, a documented approach to state and data fetching, and boundaries that prevent one feature reaching into another's internals. Conventions matter more than any specific library choice, because they are what let a new developer predict where something lives.

For interactive product interfaces, yes — the ecosystem, hiring pool and library support remain the deepest available. The more useful question is which rendering model you need. Content-led sites are often better served by a framework that renders on the server by default than by a client-rendered single-page application.

Test behaviour rather than implementation. Component tests that query by accessible role and label survive refactors and catch accessibility problems at the same time. Add a small number of end-to-end tests over the journeys that would cost real money if they broke, and treat those as the release gate.

Inventory the React version, build tooling, routing and state approach, then move in vertical slices rather than rewriting wholesale. Class components, legacy context and deprecated lifecycle methods can usually coexist with modern code during transition, which keeps the application shippable throughout.

Not inherently, but client-rendered React makes it easy to. LCP suffers when content waits on a JavaScript bundle, and INP suffers when hydration and event handlers block the main thread. Server rendering, code splitting and keeping interactive islands small are what address it.

Good at APIs, integrations, streaming and I/O-heavy work where many operations wait on network or disk. Bad at sustained CPU-bound computation, because a long synchronous operation blocks the event loop and stalls every other concurrent request in that process.

Horizontally, by running multiple processes behind a load balancer, plus clustering to use all cores on a single machine. Because each process holds its own memory, session and cache state must live in a shared store such as Redis rather than in the process.

The runtime is fine; the risk is usually the dependency tree. Audit dependencies regularly, pin versions, validate all untrusted input at the boundary, avoid running as root, and keep secrets out of the code. A typical project pulls in hundreds of transitive packages that nobody has read.

LTS versions have published end-of-life dates roughly every two to three years, after which they stop receiving security patches. Plan an upgrade before that date rather than after. Staying on an unsupported runtime is one of the more common findings in a security audit.

For anything beyond a small script, generally yes — it catches interface mistakes at build time and documents contracts. It does not replace runtime validation, since types are erased before execution and external data can be any shape regardless of what the code declares.

Usually references retained unintentionally — growing caches without eviction, event listeners never removed, closures holding large objects. They are found by watching heap usage over time and comparing heap snapshots between two points under load, rather than by reading the code.

Express is ubiquitous and easy to hire for. Fastify is faster with built-in schema validation. NestJS imposes structure that helps larger teams and hurts small ones. Choose from team size, existing conventions and how much structure the project genuinely needs, not benchmarks.

A process manager or container runtime that restarts on failure, health checks the load balancer respects, graceful shutdown so in-flight requests finish during a deploy, structured logging to somewhere searchable, and a rollback that does not require rebuilding from source under pressure.

No. Types are erased at compile time, so anything crossing a boundary at runtime still needs validating: HTTP request bodies, form submissions, environment variables, webhook payloads and third-party API responses. A declared type on external data is an assumption, not a guarantee, and it fails silently when the source changes shape.

Node.js works well for web APIs, streaming and integration-heavy applications that benefit from the JavaScript ecosystem. CPU-intensive work may need worker processes, a queue or a separate service.

Share the stable domain and transport contracts — the shapes that cross the wire — rather than database internals or anything encoding an authorisation assumption. The server stays responsible for permissions, validation and state transitions regardless of what the client's types claim, because a type shared with the browser is not a security boundary.

Use structured errors, logs and traces, bounded timeouts and graceful shutdown, then keep supported runtime and package versions current through staged upgrades and regression tests.

Usually yes once more than one person touches the code or it lives longer than a few months. The cost is mostly upfront configuration; the return is refactoring confidence and self-documenting contracts. For a genuinely disposable script it may not be worth it.

Strict from the start on a new project — enabling it later means fixing everything at once. On an existing codebase, turn on strict checks incrementally per directory. Widespread use of `any` or non-null assertions means the type system is being bypassed and is no longer providing guarantees.

Node.js is a strong default when the team already writes JavaScript, when the work is integration and I/O heavy, and when sharing types across frontend and backend is valuable. CPU-bound work benefits from worker threads, a queue, or a separate service in a language suited to it.

Validate environment variables at startup with a schema so a missing value fails immediately rather than at 3am. Keep secrets out of the repository and out of client bundles, use per-environment values, and make rotation a documented procedure rather than an emergency.

When you need authentication, roles, queues, scheduling, an admin surface and a mature ORM working together quickly, and the team writes PHP. Next.js is stronger for content-led frontends and rendering control; Node suits integration-heavy services. Laravel excels at internal business applications.

Yes. Modern PHP is fast, typed where you want it, and actively developed, and Laravel is one of the more productive application frameworks in any language. The hiring pool is deep and hosting is inexpensive. The objections are usually about older PHP codebases rather than the current language.

Most often N+1 queries — a loop that looks harmless issuing one query per record. Eager loading relationships fixes the majority. After that, missing indexes, unbounded result sets, and work happening in the request that belongs in a queued job.

Queue anything slow or externally dependent — email, exports, imports, third-party API calls — so the request returns quickly. That needs a queue driver, a supervised worker process, failed-job handling and a visible retry path. Workers must be restarted on deploy or they keep running old code.

Manageable if done regularly. Laravel releases yearly with a published support window, and incremental upgrades are usually straightforward. Jumping several major versions at once is materially harder because breaking changes compound and third-party packages may have no compatible release.

A PHP runtime of a supported version, Composer, a database, and ideally Redis for cache and queues. Shared hosting can run it but often makes queue workers and scheduled tasks awkward. A VPS or managed PHP platform gives the process control that queues and scheduling actually require.

Yes, and it is a common pattern. Laravel provides the API, authentication and business logic while the frontend is separate. Token-based authentication, API versioning, consistent error shapes and CORS configuration need deciding early rather than after the frontend is built.

Feature tests exercising real HTTP routes against a test database catch the most regressions for the least effort. Add unit tests for business rules with genuine complexity. Laravel's testing tools make database refreshing and external service faking straightforward, so there is little excuse for none.

Both are mature relational databases. Choose from existing expertise, hosting, extensions, replication and query needs; good modelling, constraints, indexing and operations usually matter more than generic feature comparisons.

Start from measured query patterns and execution plans rather than intuition. Index the columns actually used for filtering, joining and ordering in queries that matter, then confirm the planner uses them. Every index costs write throughput and storage, and redundant or unused indexes are a common and invisible drag on performance.

Often, through backward-compatible expand-and-contract changes, staged backfills and application releases that tolerate both schemas. Large tables and hosting limits still require rehearsal and rollback planning.

Define recovery point and time objectives, keep independent backups and perform clean restore tests. Reconciliation is also needed for events that occur around a failure or partial migration.

Model the real entities and their relationships rather than the current screens, and let constraints — foreign keys, uniqueness, not-null, checks — enforce the rules in the database rather than only in application code. Screens change often; the underlying entities usually do not.

Most often a missing or unusable index, a query pattern that changed as data grew, or statistics that no longer reflect the table. Read the execution plan before adding anything — an index that is not selective, or that the planner will not use because of a function applied to the column, costs writes and returns nothing.

Both, deliberately. An ORM removes boilerplate for straightforward reads and writes. Reporting queries, bulk operations and anything performance-sensitive are usually clearer and faster as explicit SQL. The problem to avoid is an ORM generating queries nobody has ever inspected.

Cost follows storage, memory, connections and IOPS rather than row count alone. Managed services charge a premium for backups, failover and patching that is usually worth it. Connection limits are a common surprise on shared plans, particularly with serverless applications that open connections per invocation.

A custom block theme suits teams that need reusable governed patterns and performance control. A carefully constrained builder can support faster marketing changes, but unrestricted widgets often create inconsistent markup, accessibility and speed.

Yes, when content types, block patterns, preview and permissions are designed around routine publishing tasks. Guardrails should protect spacing, hierarchy and responsive behaviour without blocking legitimate content changes.

Set budgets for templates, media, fonts and third-party scripts, then measure real LCP, INP and CLS across important page types. Hosting and caching help, but cannot compensate for a heavy theme or uncontrolled plugins.

Those are related but separate workstreams that should be scoped from the current site. URL mapping, metadata parity, editor training, updates, backups, security monitoring and ownership after launch all need named deliverables.

A template-based site is inexpensive; a custom block theme with a designed editing model, custom content types and integrations is a considerably larger project. The variables that actually move cost are the number of distinct templates, how much editorial flexibility is required, and what has to connect to other systems.

A straightforward marketing site is usually a matter of weeks once content is ready. Content readiness is the most common cause of delay — builds routinely wait on copy, images and product data rather than development. Custom functionality, migration and integrations extend the timeline further.

Block themes align with the direction WordPress itself is going and generally produce lighter markup. Established page builders remain reasonable where a marketing team is already productive in them and performance is actively managed. What causes problems is an unconstrained builder with no component discipline, which produces inconsistent, slow pages.

Yes. Content, URLs and media stay in place while templates and styling change. The work needing care is content that was authored inside a page builder's own format, since that does not transfer cleanly to a different builder or a block theme and usually needs a conversion pass.

Business logic, integrations, scheduled work and reusable functionality belong in a plugin so they survive a theme change. Presentation-only behaviour can remain in the theme or block layer.

Check capabilities and nonces, validate and sanitize untrusted input, use prepared queries and escape output at the correct context. Webhooks and REST routes also need authentication, rate limiting and safe error responses.

Compatibility must be implemented and tested explicitly against the supported checkout experience and High-Performance Order Storage. Order access should use WooCommerce APIs rather than assumptions about legacy post tables.

Define supported versions, automated and manual regression journeys, upgrade notices and a rollback path. A maintained plugin includes compatibility work and data migrations, not only the initial code delivery.

A contained plugin doing one well-defined job is a modest project. Cost rises with WooCommerce involvement, external integrations, data migrations and the number of WordPress, PHP and plugin combinations that must be supported. Ongoing compatibility work should be budgeted separately from the initial build.

Often, if the source is available and the licence permits modification. The safer pattern is usually to extend it through its own hooks from a separate plugin rather than editing it directly, so the original can still be updated. Where that is not possible, a fork needs an explicit maintenance owner.

Only if it uses documented extension points and is tested against new versions. Plugins that modify core behaviour, query the database directly around WooCommerce, or depend on undocumented internals are the ones that break. Supported version ranges and a regression suite should be part of the deliverable.

Yes, but distribution changes the engineering requirements — licensing, update delivery, multi-environment support, uninstall behaviour and support processes all become part of the product. It also means testing against themes and plugin combinations you do not control, which is a materially larger scope than a single-site plugin.

Caching may improve server response while large hero media, render-blocking CSS, fonts, JavaScript and third-party tags still hurt LCP, INP or CLS. Diagnose each metric on the real template and device class.

The issue is behaviour rather than a universal blacklist: repeated database queries, uncached remote calls, broad asset loading and long browser tasks are common causes. Profile the active stack before replacing anything.

Use lab traces to diagnose changes and field data to confirm real-user impact over time. Test logged-out pages plus checkout, search, forms and any uncached or authenticated journeys.

Optimized formats and responsive dimensions help, but they do not fix slow PHP, blocking styles, excessive JavaScript, font shifts or third-party code. Performance work should follow the measured bottleneck.

Aim for the Core Web Vitals thresholds on real user data rather than a lab score: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, at the 75th percentile. A perfect synthetic score on a page nobody visits is not a useful target.

It will help server response time for anonymous visitors and nothing else. Render-blocking CSS, oversized hero images, font loading, heavy JavaScript and third-party tags are unaffected by caching, as are logged-in, cart and checkout journeys which typically bypass the cache entirely.

The count is the wrong measure. Twenty lightweight, well-written plugins can outperform three that make uncached external calls on every page load. Profile what the active stack actually does per request rather than deactivating by number.

Sometimes, and it is straightforward to test: measure server response time on an uncached request. Consistently slow TTFB points at hosting, PHP workers or database work. Fast TTFB with poor perceived speed points at the frontend, and moving host will not change it.

No. A security plugin covers a slice — usually login protection and file scanning. Practical hardening also means supported core and extensions, least-privilege user roles, protected authentication, correct server permissions, careful input and output handling, change monitoring, and a recovery procedure that has actually been tested rather than assumed.

Maintain an inventory, remove unused code, monitor disclosures, stage updates and run regression checks on critical journeys. Unsupported extensions should be replaced or isolated with a documented risk decision.

Store database, uploads, configuration and any deployment-specific files off site with clear retention. A backup becomes trustworthy only after a restore is tested in a clean environment.

Contain access, preserve evidence, rotate credentials, identify the entry point, rebuild from known-good code and reconcile content and accounts. Restoring the same vulnerable snapshot without closing the cause invites recurrence.

Most commonly through a known vulnerability in an outdated plugin or theme, weak or reused administrator credentials, or a compromised hosting account. Establishing the entry point matters as much as cleaning the site — restoring a backup without closing the cause reliably results in reinfection.

Inventory and updates of core, plugins and themes with regression checks; least-privilege user roles; login protection; file and account change monitoring; off-site backups with tested restores; and a documented response procedure with a named owner. A security plugin is one component, not the programme.

Managed hosts handle platform patching, isolation and often malware scanning, which removes a meaningful class of risk. They do not manage your plugin choices, user accounts, custom code or content permissions, and those are where most compromises originate.

Containment and a clean rebuild from known-good code is often achievable within a day for a straightforward site. Identifying the entry point, reconciling content and accounts changed during the compromise, and removing search engine or blocklist penalties takes longer and is the part that cannot be rushed.

By reproducing the requirement or the defect somewhere that is not production, first. That means a staging environment mirroring the live plugin and PHP versions, because testing against a different stack proves very little. From there the work is to map what the change touches — which plugins, which database tables, which scheduled tasks — then make the smallest supportable change rather than the most elegant one. Before release, the journeys that matter get tested deliberately: an editor publishing, a visitor completing the main action, any API consumer, and any cron job that runs unattended. Finally the release needs a way back. A change that cannot be reversed within minutes is a change nobody should be making on a Friday afternoon.

Yes, and it is one of the more common reasons custom development is worth paying for. The engineering questions matter more than the connection itself. Which system owns each field, so that two systems never both believe they are authoritative? What identifier links a WordPress record to the external one, and is it stable? What happens when the external service is slow, returns an error, or silently changes its response shape? Reliable integrations combine webhooks for timeliness with a scheduled reconciliation pass that catches whatever the webhooks missed, because webhook delivery is never guaranteed. Every write should be idempotent so a retry cannot create a duplicate record, and operators need visibility into which specific records failed and why.

Core, plugin and theme updates applied in a controlled way with regression checks on the journeys that actually earn money, rather than clicking update and hoping. Backups taken off-site, with a restore genuinely tested into a clean environment — an untested backup is an assumption, not a safety net. Uptime and application error monitoring that alerts a named person with enough context to act. Security review covering user accounts, file changes and disclosed vulnerabilities in your installed extensions. Periodic checks that forms and transactions still complete, because those break silently and are usually discovered by a customer. And a documented response path, so when something does go wrong everyone already knows who does what.

By designing for failure before the first run, because at volume failure is certain rather than possible. Work is processed in batches with checkpoints, so an interruption resumes from the last completed position instead of starting over. Every operation is idempotent, so re-processing a record cannot create a duplicate. Structured logs record which record failed, at which step, with what error — not just that the job failed. The operator then needs a way to replay a single failed item or a defined subset, rather than rerunning the entire import blindly and hoping the second attempt behaves. Where an import touches published content or orders, a dry-run mode that reports what would change is worth building.

Pricing follows change frequency, business risk and how quickly you need someone to respond — not the size of the site. A brochure site needing monthly updates, backups and a check that the contact form still works sits at the low end, because the work is genuinely small. A transactional site is materially more expensive, because every update needs staging, regression testing across checkout and account journeys, and someone available inside an agreed window when something breaks. The honest way to compare quotes is to look at what is actually included: whether restores are tested, whether there is a named response time, and whether small changes are covered or billed separately.

Usually, and it starts with an audit rather than an assumption. That means establishing what hosting it runs on, recovering access to every account involved, inventorying plugins and their licences, identifying custom modifications, checking whether backups exist and actually restore, and reading enough of the code to know what shape it is in. The common complication is undocumented modifications — changes made directly to core, to a plugin, or to a theme that will be destroyed by the next update. Those need a remediation decision before any ongoing support arrangement means anything, because supporting a site you cannot safely update is not support. The audit is chargeable work and produces a written risk picture.

Whatever was agreed, which is why it needs agreeing explicitly rather than assumed. Genuine out-of-hours cover requires three things working together: monitoring that detects the failure quickly, an alert that reaches a specific named person rather than a shared inbox nobody watches at midnight, and a tested restore path that can be executed under pressure. Without all three, out-of-hours availability is a promise rather than a capability. It also costs money, because it means someone is on call. Many businesses correctly decide that same-business-day response is sufficient for their risk, and that is a legitimate choice — provided it is a decision rather than a discovery made during an outage.

Almost certainly, since WordPress runs a substantial share of the highest-traffic publishers online. When a WordPress site struggles under load the cause is nearly always specific and fixable rather than architectural. Pages that cannot be cached because they are personalised, database queries that were fine at ten thousand rows and are not at two million, plugins making synchronous external API calls during page generation, and media served at full resolution are the recurring culprits. Capacity planning should begin with a load profile of the journeys that actually matter, including the ones that bypass caching entirely — site search, cart and checkout — because those are what fail first and they never appear in a homepage speed test.

No migration can guarantee unchanged rankings, but risk can be reduced by preserving valuable URLs, server-rendered content, metadata, canonicals, internal links, structured data and media signals. Test a complete redirect map and rendered HTML before DNS changes.

It can when editors need the existing authoring workflow and plugins are not required on the frontend. Preview, revisions, webhooks, media URLs, authentication and two-system maintenance must be designed explicitly.

Crawl every indexable URL and record status, canonical, headings, copy, media, schema, backlinks, traffic and conversion value. Include PDFs, taxonomy archives and redirected legacy URLs that a menu export may miss.

Monitor redirect hits, crawl errors, canonicals, XML sitemaps, rendered content, analytics events and high-value queries. Keep the old crawl and a rollback plan so unexpected changes can be traced quickly.

Cost tracks URL count, template variety, integration complexity and how much content modelling has to change — not the visual design. A brochure site with clean URLs is a contained project; a large site with plugin-dependent functionality, forms and commerce is substantially more because each dependency needs a replacement decision.

Some fluctuation during recrawl is normal even on a well-executed migration. Sustained loss is usually caused by broken redirects, content that no longer renders server-side, or metadata that was not carried across. Keeping the pre-migration crawl and a rollback path is what makes a problem diagnosable rather than mysterious.

This is the decision that most often gets deferred and should not be. Either WordPress stays as a headless CMS and editors keep their interface, or content moves to another system and they need training and migration. Preview, revisions and media handling all need explicit design in the headless option.

If WordPress remains as a headless CMS, yes — plus hosting for the Next.js frontend, so you are running two systems. If content moves fully, WordPress can be retired once media URLs and any remaining redirects are handled. The two-system cost should be in the business case from the start.

Yes, for most content-led and marketing sites, and for a large share of small to mid-sized stores. The reasons are practical rather than ideological: your team can publish without a developer, hosting is inexpensive, the hiring pool is deeper than for any other CMS, and the extension market already solves the majority of common requirements. Where it stops being the right answer is when the site is really an application wearing a CMS, or when the frontend needs behaviour the theme layer cannot express. Those are real limits, but they apply to fewer projects than the internet's opinion of WordPress would suggest.

The core software is actively maintained and patched quickly. Almost every compromise traces to something around it: an outdated plugin or theme, a weak or reused administrator password, or a hosting account that was itself breached. That means security is largely an operational discipline rather than a property of the platform. Keeping core and extensions current, removing code you no longer use, enforcing least-privilege roles, protecting login, and holding tested off-site backups closes the overwhelming majority of the real risk. A site that is patched and monitored is not meaningfully less safe than the same site on another platform.

Because it is easy to make slow, not because it is inherently slow. The platform imposes almost no discipline — a page builder, a dozen plugins each loading their own assets on every page, unoptimised images and three tracking scripts will produce a slow site regardless of hosting. The same platform runs some of the highest-traffic publishers in the world. Speed on WordPress comes from the same things it comes from anywhere: controlled assets, sensible caching, optimised media, and not making uncached external calls on every request. The difference is that WordPress lets you skip all of that, and many sites do.

The count is genuinely the wrong measure, and it is worth resisting the advice that says otherwise. Twenty small, well-maintained plugins doing narrow jobs can be considerably faster and safer than three that each make external API calls on every page load. What matters is what your active plugins actually do per request, whether they are still maintained, and whether anyone knows why each one is installed. The real risk of a large plugin surface is not performance — it is that nobody can say what the site depends on, which makes every update a gamble.

Keep WordPress when the people publishing are non-technical and the authoring experience matters to them daily. Consider headless when the frontend genuinely needs something a theme cannot deliver, when content feeds more than one surface, or when you already maintain a React application and do not want a second stack. Note that headless WordPress is also an option — the editors keep their interface and the frontend becomes yours. That middle path costs two systems to operate, which is a real ongoing expense and belongs in the decision rather than being discovered afterwards.

Comfortably, when it is built and hosted for it. WordPress powers a substantial share of the largest publishers online, so the platform ceiling is far above where most sites operate. Problems come from specific, fixable things: pages that cannot be cached because they are personalised, expensive database queries running on every request, plugins calling external services synchronously, and media served at full size. Capacity planning should start with a load profile of the journeys that actually matter, including the ones that bypass caching entirely such as search, cart and checkout.

Hosting, premium plugin and theme licences, and maintenance time. Hosting is usually the smallest of the three. Licences accumulate quietly — a store running eight or ten commercial extensions often pays more annually in renewals than in hosting. Maintenance is the cost most often ignored and the one that determines whether the site is still safe to update in two years: core and plugin updates with regression checks, backups with tested restores, monitoring, and someone available when something breaks. Budgeting nothing for it is how sites become unsupportable.

When the reasons you chose it no longer apply. If plugin dependencies now block updates, if the theme layer is the hard limit on performance you need, if two teams need to work on the frontend independently, or if the site has become an application where the CMS is incidental — those are genuine signals. What is not a signal is that another platform sounds more modern. Migration costs real money and carries real search risk, so it should be justified by a constraint you can name and demonstrate, not by dissatisfaction with the platform's reputation.

WooCommerce is a free plugin that turns a WordPress site into an online store. Installing it adds products, a shopping cart, checkout, order management, tax and shipping handling to a site that was previously just pages and posts. The combination is powerful because you get a full content management system and a store in one place — the same editor publishes a blog post and a product — and because both are open source, you own the data and can host it anywhere. It sells physical goods, digital downloads and services, though services usually need an extension for scheduling or subscriptions.

Yes. WooCommerce is a WordPress plugin, not standalone software, so it requires a working WordPress installation to run at all. That is a genuine consideration when comparing it against hosted platforms: with Shopify you sign up and start, while with WooCommerce you first need hosting, a domain, WordPress installed and maintained, then WooCommerce configured on top. The trade is control and cost — nothing is locked to a vendor and there are no transaction fees on the platform itself — in exchange for being responsible for the stack underneath.

The plugin is free and always has been, with no licence fee and no cut of your sales. The realistic total is different. You pay for hosting, a domain and an SSL certificate. Payment gateways charge their normal processing fees. Most real stores end up buying two or three commercial extensions — subscriptions, bookings, advanced shipping, a better search — and those renew annually. A working store commonly costs a few hundred dollars a year in extensions plus hosting, which is still frequently cheaper than a hosted platform at volume, but it is not zero.

You are responsible for the stack. Updates to WordPress, WooCommerce, PHP, the theme and every plugin are yours to manage, and a bad combination can break checkout. Performance degrades if plugins accumulate unchecked, since nothing prevents you installing thirty of them. Security is your operational discipline rather than a vendor's. Extension quality varies widely and support is not centralised. At very large catalogue sizes it needs deliberate database and hosting work. None of this makes it a poor choice — it makes it a choice that assumes someone competent is maintaining it.

Different trades rather than a ranking. Shopify hosts everything, handles PCI compliance and updates, and gives a proven checkout you cannot break — at a monthly fee, transaction charges unless you use Shopify Payments, and real limits on checkout customisation below Plus. WooCommerce gives complete control, no platform fee, full data ownership and unlimited customisation — in exchange for operating the hosting, updates and security yourself. Choose Shopify if you want to run a shop; choose WooCommerce if you want to own a system and have someone to maintain it.

Because it is self-hosted open source, there is no central register of who runs it, and that is itself informative — nobody can see your store unless you tell them. Independent surveys consistently place it among the most widely used e-commerce platforms on the web by site count, with particular strength among small and mid-sized retailers, content publishers who added a shop, and businesses selling digital goods. Very large enterprise retailers more often run custom or headless platforms, though several sizeable brands do run WooCommerce successfully.

No, though the question comes up constantly. It still powers a very large share of the web, its release cadence is active, and the block editor has substantially modernised the authoring experience. What has genuinely changed is the competitive picture: hosted site builders are better than they were, and headless architectures suit teams with frontend engineers. That has taken some projects away at both ends. For the middle — businesses where non-technical people publish regularly and hosting cost matters — the case for WordPress is as strong as it has been.

Hosting built for WordPress with enough resources for uncached traffic, since a store's cart, account and checkout pages bypass page caching entirely. That means adequate PHP workers and memory, object caching such as Redis, and a database that is not shared with hundreds of other accounts. Managed WordPress hosts handle patching and often bundle staging environments, which is worth the premium for most stores. Cheap shared hosting works for a small catalogue with light traffic and becomes the bottleneck sooner than owners expect.

Not directly. Wix does not provide a full site export, so moving means rebuilding the design and templates elsewhere. Content can be recovered manually or by scraping, and URLs can be redirected from the new site, but treat leaving Wix as a rebuild rather than a migration.

Velo adds JavaScript, custom database collections, external API calls, scheduled jobs, dynamic pages driven by data and custom form logic. It turns Wix into something closer to an application platform, within the execution time, storage and rate limits the platform imposes.

No — Wix renders server-side, produces clean URLs, and supports meta tags, canonicals, redirects, structured data and sitemaps. The real constraints are less control over technical details than a self-hosted stack, and platform-level performance you cannot tune directly. Content and intent still matter far more.

Stay if a non-technical team maintains the site, requirements are stable, and the platform limits are not blocking anything. Move when you need portability, complex catalogue or membership logic, deep integrations, or control over hosting and performance that Wix does not expose.

It handles straightforward catalogues, payments and shipping well. It strains with large numbers of variants, B2B or tiered pricing, complex tax rules, deep ERP or fulfilment integration, and high-volume catalogue updates. Assess against your actual catalogue and order operations, not the feature list.

The subscription is only part of it. Premium plans, third-party apps with their own recurring fees, transaction charges and paid templates add up, and app costs frequently exceed the plan itself. Model the total across three years when comparing against self-hosted alternatives.

Yes — editor and design work, SEO configuration, Velo development, integrations and performance improvements within platform limits. What cannot be done is server-level access, arbitrary code injection outside Velo's model, or anything requiring control of the hosting environment.

Frequently, yes. Each third-party app adds scripts that run on page load, and several together noticeably affect Core Web Vitals. Because you cannot control bundling or execution order at the platform level, restraint about which apps are genuinely necessary is the main lever available.

Matching search intent better than the pages currently ranking. That usually means changing the format the page takes — comparison, tutorial, definition, product listing — or adding the depth and specific detail competitors omit. Title and heading refinements help clarity and click-through; they rarely close a genuine coverage gap on their own.

No. It is not a ranking factor and optimising for a target percentage generally makes the writing worse. What matters is covering the subtopics and entities the topic genuinely involves, in language that reads naturally. Repetition of an exact phrase past the point of usefulness is a quality signal in the wrong direction.

As long as the query requires and no longer. Read what currently ranks to see what depth the intent is rewarding — some queries are satisfied in 300 words and padding them hurts, others need thorough treatment. Word count targets produce filler, which is the thing to avoid.

Lead with what the page is about in the terms people search, keep the important part early enough to survive truncation, and make it accurate. Google rewrites titles it judges unhelpful or mismatched with the page, so a title that oversells relative to the content is often replaced anyway.

Not directly. They influence click-through when Google chooses to use them, which it frequently does not, preferring a passage from the page that matches the query. Writing them is still worthwhile for important pages, but they are not where on-page effort should be concentrated.

One is the clearest convention and the safest for accessibility, even though HTML5 permits more and search engines tolerate them. The heading hierarchy matters more than the count: H2s and H3s should reflect the actual structure of the content, not be chosen for visual size.

Usually update. An existing page with history, links and indexation is easier to improve than a new page is to establish, and adding another page on the same topic risks competing with the one you already have. New pages are for genuinely distinct intents that nothing currently covers.

Track by query group and landing page against a baseline captured before the change, allowing several weeks for recrawl and reprocessing. Annotate the release date so a later movement can be attributed. Watch impressions and average position as well as clicks, since ranking can improve before traffic follows.

They are separate systems. Organic ranking weighs the website; local ranking weighs the Google Business Profile against relevance, distance and prominence for the searcher's location. A site can rank nationally and still be missing locally because the profile is incomplete, the primary category is wrong, or business details disagree across the directories Google cross-references.

It is one of the strongest local ranking inputs, and choosing a broader or adjacent category to seem more relevant usually reduces visibility rather than increasing it. Pick the category that most precisely describes the main business, then use secondary categories for genuine additional services.

Only to a limited extent. Proximity to the searcher is a ranking factor nobody can optimise away, so map pack visibility falls off with distance from your actual location. Service-area businesses can define their area and build location-relevant content and links, but a listing cannot be placed where the business does not exist.

Consistency does. Google cross-references your name, address and phone across directories and data aggregators, and conflicting versions create doubt about which record is correct. The value is in accuracy and consistency across a sensible set of relevant directories, not in the raw number of listings.

Ask every customer, at the point they are most satisfied, with a direct link to the review form. What is not permitted is gating — asking for feedback first and only routing happy customers to Google — or incentivising reviews. Both breach Google's policies and can result in review removal or profile suspension.

Yes, promptly and factually. The reply is written for everyone who reads it later, not for the reviewer. Acknowledge the specific issue, avoid disputing details publicly, and move the resolution to a private channel. Response rate and recency both contribute to how a profile is perceived.

Only where there is genuinely distinct information — a real address, staff, opening hours, local pricing or service differences. Generating near-identical pages with a swapped town name is the doorway page pattern Google's spam policies name explicitly, and it is one of the more reliably penalised tactics in local SEO.

Profile corrections such as categories, hours and service areas can affect visibility within weeks. Citation consistency, review accumulation and local authority build over months. Competitive urban categories take longer than rural ones, and proximity places a ceiling on how far the improvement can extend geographically.

The top section is field data from real Chrome users over the past 28 days, which is what Google actually assesses. The lower section is a simulated lab test on a throttled connection. They disagree routinely. Use the lab test to diagnose causes; use field data to decide whether a problem exists.

LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, measured at the 75th percentile of real users. Meeting them at the median while failing at the 75th percentile means a quarter of your visitors have a poor experience and the assessment reflects that.

They are a real but small input, and they rarely outweigh relevance and content quality. Where competing pages are otherwise comparable, page experience can be a differentiator. A fast page that answers the query poorly will not outrank a slower page that answers it well.

Most often the hero image is not prioritised, or a render-blocking stylesheet or font delays it. Slow server response contributes on uncached or database-heavy pages. Identify the element the browser actually reports as LCP before optimising, because it is frequently not the element assumed.

INP replaced First Input Delay in 2024 and measures the full latency of interactions throughout the visit, not just the first one. It is a harder metric to pass because it includes processing and rendering, so sites that comfortably passed FID often fail INP without any code change.

Reserve space before content arrives: explicit width and height on images and video, defined dimensions for ads, embeds and banners, and font loading configured so a swap does not reflow text. Shifts caused by content injected above existing content are the most damaging and the most avoidable.

Mobile assessment reflects mid-range devices on real networks, where reduced CPU makes JavaScript execution and hydration far more expensive. Desktop testing on a development machine hides this almost completely. Test on a throttled profile or a genuine mid-range handset.

Field data uses a rolling 28-day window, so a change takes several weeks to be fully reflected and appears gradually as the window moves. Deploy, verify in lab data that the cause is genuinely fixed, then wait for field data rather than repeatedly re-testing.

It is several pages on one site targeting the same intent, so search engines split signals between them and rank none as well as a single consolidated page would. It matters where the pages genuinely compete for one query. Pages covering related but distinct intents are not cannibalising, they are covering a topic.

In Search Console, look for queries where the ranking URL changes over time, or where several URLs receive impressions for the same query. That flip-flopping is the clearest signal that the site is offering multiple answers to one question and search engines cannot decide between them.

Merge where the weaker page contains genuinely useful content or has earned links, redirecting it to the consolidated URL so that value is preserved. Delete and redirect where it adds nothing. Removing a page without a redirect discards whatever authority and traffic it had for no benefit.

A broad page covering a topic at overview depth, linking to specific pages that treat each subtopic properly, with those pages linking back. The structure makes the relationship between pages explicit rather than leaving it to be inferred, which helps both readers and search systems navigate the topic.

There is no target worth chasing. Link where a reader would genuinely benefit from the related page, using anchor text that describes the destination. A page with three well-placed contextual links usually outperforms one with thirty in a footer block nobody reads or clicks.

It carries no information about the destination, for readers or search systems, and it is poor for screen reader users navigating by link. Descriptive anchors are better for all three. It does not need eliminating everywhere, but important internal links should say what they lead to.

Important pages should be reachable within about three clicks from the homepage. Depth correlates with how often a page is crawled and how much internal authority reaches it. Pages buried under several layers of pagination or filters are frequently crawled rarely and rank accordingly.

There is short-term risk with any URL change, which is why consolidation needs a complete redirect map, a pre-change crawl to compare against, and staged rollout rather than a single large change. Done carefully the medium-term result is usually improvement, because signals stop being divided.

Ranking places a link in a list a user chooses from. AI visibility means being retrieved and cited inside a generated answer, often with no click at all. The same technical foundations apply, but the content has to resolve the question in a self-contained passage rather than persuade someone to click through.

No. Selection sits entirely with each system, the surfaces change without notice, and nobody outside those companies controls inclusion. What can be committed to is the work that improves eligibility — extractable structure, verifiable claims, accurate markup, crawler access — plus honest measurement of what moved.

By sampling and triangulation. A fixed prompt set is run across the relevant assistants on a schedule and the answers, citations and brand mentions recorded; AI crawler activity is read from server logs; reported referrals are tracked where available. The result is a defensible trend, not a ranking report.

It is a commercial decision per crawler, not a default. Allowing GPTBot, ClaudeBot, PerplexityBot and Google-Extended permits citation and recommendation but also permits use of your content. Blocking protects the content and removes the visibility. Whichever you choose should be deliberate and documented in robots.txt.

Only if it adds something not already available. Systems synthesising an answer have no reason to retrieve a page that restates what other sources cover. Volume without information gain adds duplication risk and crawl cost. Fewer, genuinely specific pages consistently outperform more generic ones.

Usually because the sources they draw on disagree, are out of date, or describe a similarly named organisation. It cannot be edited directly. The route is to make the authoritative record consistent — site, structured data, profiles — and earn accurate mentions in the third-party sources those systems cite.

Own-site retrievability improvements are usually reflected within weeks of recrawl. Changes in how often a brand is cited move over months and unevenly between systems, because they depend on third-party coverage and each provider's refresh cycle. A baseline taken beforehand is what makes any later claim meaningful.

It is a question of proportion. Most of the underlying work — crawlability, clear structure, extractable answers, accurate entities — strengthens conventional search at the same time. The specifically generative additions are worth the incremental cost where you can see buyers researching through assistants.

The page it sits on and the text describing it. Filename, alt text, caption, surrounding copy and page relevance all contribute, alongside image quality and dimensions. An excellent image on a page that never mentions its subject has almost nothing for a search system to work with.

Describe what the image shows, for someone who cannot see it. That is the accessibility requirement and it happens to be what search systems want too. Keyword-stuffed alt text fails both. Purely decorative images should have an empty alt attribute so screen readers skip them rather than announcing a filename.

They make the content readable by search systems, usable by people who cannot or will not play audio, and available as text for AI systems to extract. For anything explanatory, a transcript is usually the single highest-value addition — it converts an opaque media file into indexable content.

WebP or AVIF for photographs, with appropriate fallbacks, and SVG for logos, icons and diagrams. The larger win is usually serving correctly sized images rather than the format: a 3000px image scaled down in the browser wastes most of the bytes it cost to deliver.

No. ImageObject and VideoObject markup clarify what the media is and how it relates to the page, which helps interpretation. Whether any visual result is shown remains the search engine's decision, and markup that describes media the page does not actually contain breaches the structured data policies.

They are the most common LCP element, so priority and sizing matter directly. They are also a frequent source of layout shift when width and height are not declared. Lazy loading helps below the fold and hurts above it, because it delays the element the metric is measuring.

YouTube provides its own discovery surface, handles delivery and adaptive streaming, and costs nothing, at the price of branding and its embed's performance weight. Self-hosting gives control and a cleaner page, but you own bandwidth, encoding and player accessibility. Many sites use YouTube for reach and a lighter embed on-page.

Worth doing the fundamentals, not worth restructuring around. Descriptive filenames, real alt text, captions, transcripts and clean surrounding context serve accessibility and conventional search regardless of what happens to visual search, so the work is not speculative even where the payoff is uncertain.

They count differently. Ads attributes a conversion to the click that drove it, within its own window, and reports it on the click date. GA4 attributes across a different model and reports on the conversion date. Neither is wrong; they answer different questions and will never reconcile exactly.

The events that change a business decision — qualified enquiries, purchases, bookings, meaningful signups. Tracking every scroll and click produces dashboards nobody acts on. If you cannot say what you would do differently based on an event, it does not need to be a conversion.

Substantially. Visitors who decline analytics consent are not observed, so reported figures are a subset of reality and modelled data fills part of the gap. This means platform numbers and actual revenue diverge more than they used to, and closed revenue has become the more reliable arbiter.

It improves data quality where browser restrictions and ad blockers are causing meaningful loss, and gives more control over what is sent to third parties. It adds infrastructure cost and complexity, and it does not remove consent or transparency obligations. Worth it at scale, over-engineering for a small site.

Server logs count every request including bots, crawlers and automated traffic. GA4 counts JavaScript-executing browsers that consented and were not blocked. The gap is expected and usually large. They are not comparable measures and should not be reconciled.

Pass campaign parameters into the CRM at the point of enquiry, record the stage progression, and report on closed revenue by original source. Platform-reported conversions become a leading indicator for optimisation rather than the outcome measure. Without CRM feedback, long-cycle attribution is guesswork.

Document the events and parameters as a specification rather than tribal knowledge, and verify the critical ones after every significant release. Most tracking breaks silently during an unrelated deployment, and the loss is only discovered when someone questions a number weeks later.

It helps when marketing needs to add and change tags without a developer, and it centralises third-party scripts. It also becomes a performance problem and a security surface if nobody governs what is in it. Review the container periodically and remove what is no longer used.

Only when the storefront genuinely needs something the platform's theme layer cannot deliver — unusual interaction, multi-channel delivery, or a frontend shared with an existing application. Headless adds preview, deployment, caching and API complexity, and it makes checkout the hardest part rather than the part you get free. Most stores are better served by a well-built theme.

Never assume the customer's browser returns from the payment provider. Treat the provider's webhook as the source of truth, verify its signature, make processing idempotent, and reconcile against provider state on a schedule. Orders should have a pending state that resolves either way rather than existing only once someone lands on a success page.

In one system, with every channel reading from it. Overselling almost always traces to two systems both believing they own stock. Reservation behaviour at checkout, oversell handling and a reconciliation pass for missed updates need deciding explicitly rather than emerging from whichever integration was built last.

From the attributes customers actually choose by, not from how the warehouse organises SKUs. Each purchasable combination needs its own identifier, price, stock and availability, with a stable grouping identifier tying them together. Retrofitting variant structure onto a catalogue built around single products is one of the more expensive commerce migrations.

Usually, provided it offers a documented API and webhooks. The questions worth asking early are whether it supports the payment methods your customers expect, how it handles refunds and partial captures, and whether hosted fields are available so card data never touches your server. Provider migration mid-project is expensive and worth deciding before build.

Costs appearing late, forced account creation, too many form fields, unclear delivery timing, missing payment options, and slow or broken behaviour on mobile. Each is measurable per step, so instrument the funnel before redesigning it — the actual drop-off point is usually more specific than the general impression of where it happens.

Through customer-group or account-level pricing rules rather than duplicate catalogues, with tax display, minimum quantities and payment terms varying by group. Most platforms support some of this natively and none support all of it, so the gap between what is needed and what is built in is the actual scope of the project.

Rarely. A direct coupling means every ERP change becomes a storefront outage risk. An integration layer with defined contracts, idempotent writes, retries and a reconciliation job isolates each side from the other's failures and makes it possible to see which records did not sync and replay just those.

Usually a mismatch between the feed and the landing page — price, availability or currency differing from what the page renders — or a missing required attribute such as GTIN, brand or condition. Google re-crawls the landing page and compares, so the fix is almost always making the feed reflect live catalogue data rather than editing the feed in isolation.

For products that have them, yes — omitting a GTIN that exists reduces matching and can affect eligibility. Genuinely custom or handmade goods without a manufacturer identifier are exempt, but the identifier_exists attribute must be set correctly rather than left blank, which is treated as an error rather than an exemption.

Generated from the same catalogue data the storefront reads. A manually maintained spreadsheet drifts within weeks — price changes and stock movements do not propagate, disapprovals accumulate, and nobody notices until traffic falls. Generation also makes currency, availability and variant handling consistent by construction.

Review markup is only eligible when the reviews are genuinely collected, visible on the page, and about the product being marked up. Self-serving reviews about the business on a product page, or aggregated ratings a visitor cannot see, breach the structured data policies and can cost eligibility across the site rather than just that page.

Yes, and that is the reliable route to volume — a timed request after delivery rather than at order confirmation. What matters is not filtering by expected sentiment: routing happy customers to a public review and unhappy ones to a private form is review gating, which breaches most platforms' policies and can result in removal.

Because platforms expect a specific relationship between the parent product and its variants, and most catalogues model it differently. Size and colour need consistent attribute naming, each variant needs its own identifier and availability, and the item_group_id has to be stable. Inconsistent variant data is the most common source of large-scale disapprovals.

No. It makes a product eligible for specific result presentations and helps systems interpret price, availability and rating correctly. Correct interpretation can affect which queries a page is considered relevant for, but markup is not a ranking factor and adding more of it does not improve position.

Nominate the catalogue as the single source of truth and have every channel read from it, rather than maintaining separate copies. Where a platform caches, use its update API rather than waiting for a scheduled fetch. Discrepancies between the page and the feed are the leading cause of both disapprovals and abandoned checkouts.

When you want hosted reliability, PCI compliance and a proven checkout without operating any of it, and your catalogue fits its model. WooCommerce suits content-led stores already on WordPress that need deeper customisation. The honest trade is control and cost predictability against operational burden.

Within defined limits, and those limits changed with checkout extensibility replacing the old script-based approach. Extensions can add fields, validation and content at supported points. Wholesale checkout rewrites are only available on Plus, and anything relying on the legacy scripts needs migrating rather than assuming it still works.

Buy where a well-maintained app genuinely covers the requirement — the app market is one of the main reasons to be on Shopify. Build when the requirement is specific to your operation, when app subscriptions stack up beyond the cost of building, or when several apps overlap and each adds storefront weight.

Almost always apps. Each installed app can inject scripts that load on every page, and a store carrying a dozen of them accumulates real weight regardless of theme quality. Audit what each app actually loads, remove ones no longer used, and check whether the theme is loading assets it never renders.

Products, variants, customers, order history, content and URLs, plus a redirect map for every changed address. The parts routinely underestimated are variant restructuring where the source models options differently, and replacing functionality that plugins provided on the old platform. Order history migration in particular needs deciding early — full, partial or archive-only.

Not inherently, but Shopify imposes its own URL structure — /products/, /collections/ — so almost every URL changes and a complete redirect map is mandatory. Collection pagination and duplicate product paths across collections also need canonical handling. The risk is entirely in the migration execution, not the platform.

Native B2B features exist on Plus, with company accounts, price lists and payment terms. On lower plans it is app-dependent and the gaps show quickly with complex tax rules, per-customer catalogues or approval workflows. Establish which specific B2B behaviours you need before choosing the plan, not after.

The plan, transaction fees where you are not using Shopify Payments, app subscriptions, and theme or development work. App costs are the most commonly underestimated — a store running eight to ten apps often pays more monthly in subscriptions than in platform fees. Model all four across a year before comparing platforms.

The one where your buyers already are and where you can sustain quality output, judged against your sales cycle and unit economics. A single well-run channel with credible measurement beats budget spread across every platform. Existing demand for what you sell is the strongest signal of where to begin.

Enough to reach statistical significance on your primary conversion within a sensible window. Below that you are paying for noise. The figure derives from your own cost per click and conversion rate, so it should be calculated rather than taken from a percentage-of-revenue rule of thumb.

Paid channels produce data within weeks but usually need iteration on targeting, creative and landing pages before the economics work. Organic and content channels take months. A long sales cycle pushes observable return further out, which is why leading indicators should be agreed before launch.

Usually a mismatch between what the campaign promises and what the business actually sells, targeting that is too broad, or an offer attracting researchers rather than buyers. The fix is feeding sales outcomes — not form fills — back into targeting and creative decisions.

Define conversion events, campaign parameters, CRM stages and offline outcomes first, then reconcile platform-reported numbers against first-party analytics and actual closed revenue. Attribution should be treated as directional evidence for decisions, not as a precise record of every influence on a purchase.

No, and spreading thin generally underperforms. Choose the platforms where your buyers spend attention and where you can maintain quality consistently. One channel with a real audience is worth more than five neglected profiles that signal inactivity to anyone who checks.

They reduce the completeness of what any platform can observe, which is why reported conversions and actual revenue increasingly diverge. Collect only what you need, obtain appropriate consent, and build measurement around first-party data and closed revenue rather than assuming platform figures are complete.

In-house works where there is sustained production capacity and someone accountable for the numbers. An agency helps with specialist skills, an outside view of the market, and concentrated periods of change. Many businesses combine both — external strategy and specialist execution, internal production and ownership.

A refresh suits a brand that still represents the business where the problem is expression and consistency. A rebrand is warranted when positioning, audience or offering has genuinely changed, or the identity actively misrepresents what you now do. Rebranding to solve a conversion problem usually disappoints.

Logo files in vector and raster across the sizes and backgrounds you will really use, colour values for screen and print, typography with licensing settled, usage guidance covering clear space and misuse, and the working source files. Ask explicitly whether source files are included — not everyone includes them.

Design work should be assigned to you in writing on final payment. Fonts usually are not — typefaces are licensed, not sold, and web, desktop and app use are often separate licences priced by traffic or installs. Confirm who holds the licence and what it covers.

Weeks rather than days for a considered identity, because the value is in the research, the exploration of genuinely different directions, and the revision cycles. The most common delay is decision-making on the client side, so agreeing who approves what at the start saves real calendar time.

This should be explicit in the proposal. A small number of well-developed directions is more useful than many superficial ones, and revision rounds should be defined so both sides know when the project ends. Open-ended revisions are how design projects lose money and momentum for everyone.

Only if the applications are known in advance. A mark that works on a website may fail as a favicon, an app icon, embroidery or signage. Name the real applications during the brief so the system is designed and tested against them rather than adapted awkwardly later.

Sequence it: digital properties and templates first, then printed and physical items as stock is replaced, with an internal announcement before anything is public. A short overlap where both identities exist is normal and preferable to an incomplete simultaneous switch.

Usage guidance that answers the questions people actually have, master templates for the documents produced most often, an accessible asset library, and someone who approves anything unusual. Consistency erodes through improvisation when files are hard to find, not through deliberate deviation.

Enough to know who the page is for, what they are trying to finish, and what currently stops them. Analytics, support tickets, sales conversations and watching someone attempt the task are usually more useful than formal research, and far more useful than choosing a visual direction first and fitting the content to it afterwards.

A small number of genuinely different directions beats many superficial variations. Two or three well-developed options force a real decision about approach; six near-identical ones postpone it. Revision rounds should be defined in the proposal so both sides know when the design phase ends.

When several people build related interfaces repeatedly and consistency is eroding faster than anyone can correct it. For a marketing site with a handful of templates, a documented pattern library is enough. A full system with tokens, governance and contribution rules is a product in itself and needs an owner.

Specified at the component stage rather than audited afterwards: colour contrast, focus order, keyboard operation, target size, text scaling, error messaging and media alternatives. Testing means using the interface with a keyboard and a screen reader on real content, which finds problems no automated checker reports.

Only if it was designed against real content. Placeholder text hides almost every hierarchy problem — long headings that wrap badly, empty states nobody considered, products with missing images, names that overflow. Ask for the design to be reviewed with your actual worst-case content before approving it.

Ownership should be assigned in writing, and source files handed over rather than only exports. Whether your team can edit them depends on tooling and skill — a system with clear components is far more editable than a set of bespoke artboards, which is one practical argument for building one.

Task completion, conversion quality, error and abandonment rates, support volume on the affected journeys, accessibility findings and page performance — measured against a baseline captured before the change. Stakeholder preference, including the designer's, is the weakest evidence available and the most commonly used.

Yes, and it usually shortens the project. What is worth checking early is whether the guidelines cover digital use — many are built for print and are silent on interaction states, focus styling, responsive behaviour and accessible contrast, which then need deciding as part of the work.

Choose from required device APIs, offline behaviour, performance expectations, team skills and release cadence. Cross-platform frameworks remove duplicated work but not platform-specific testing and UX. A PWA avoids install friction and store review entirely, at the cost of some device capabilities and discoverability.

An app earns its cost when you need offline capability, device features like camera or background location, notifications people genuinely want, or frequent repeat use. For occasional use and content-led experiences, a fast responsive website avoids the install barrier that most apps never overcome.

Workflow depth, how mature the backend API already is, authentication, payments, offline synchronisation, notifications, device integrations, accessibility and store compliance. Offline sync is the most commonly underestimated, because conflict resolution is a genuine design problem rather than a setting.

Review is usually days for a compliant submission, but first submissions are frequently rejected over privacy declarations, account deletion requirements, permission justifications, payment rules or incomplete metadata. Plan for review time plus at least one resubmission before any launch date is announced.

OS releases, device changes, dependency and SDK updates and store policy changes all require work even with no new features. An app left untouched for a year commonly needs substantial effort before it can ship again, so continuous small maintenance is cheaper than periodic catch-up.

You should, from the start. Developer accounts in your organisation's name, signing certificates and keystores held by you with documented backups, and release roles assigned to your staff. Signing keys held only by an agency are a serious continuity risk that is painful to unwind.

Across supported OS versions and real devices rather than only simulators: permissions flows, weak and offline networks, interruptions, upgrade from the previous version, deep links, accessibility, and backend failure behaviour. Beta distribution and crash monitoring should precede any broad rollout.

Usually yes, and it is normally the right choice — one source of business logic, one set of permissions, one place to fix things. The API may need additions for mobile concerns such as pagination, payload size, token refresh and offline-friendly responses.

Shared hosting is adequate for brochure sites and small WordPress installations. VPS or managed platforms become necessary with sustained traffic, background processing, Node applications or strict uptime requirements. Resource limits and database connection caps are usually what you hit before raw CPU.

Build and fully test the new environment first, lower DNS TTL in advance, synchronise data at cutover, then keep the old environment running until traffic has fully moved. Email routing, SSL certificates and hardcoded absolute URLs are the parts most often forgotten.

Well-run hosting on quality infrastructure commonly achieves around 99.9%, which still permits several hours of unavailability a year. Higher requires redundancy across failure domains and costs substantially more. Detection and recovery speed usually matter more to a business than the headline figure.

Uptime alone is insufficient. Add application error rates, certificate and domain expiry, critical forms and transactions completing end to end, resource limits, and performance trends. Every alert needs a named owner and enough context to act on, or it becomes noise people learn to ignore.

On a recurring schedule and after any major platform change. A backup that has never been restored is an assumption. Verification should cover database, uploaded media, configuration and the secrets needed to actually operate the restored service, not just confirm a file exists.

It should be written down rather than assumed. Hosts cover infrastructure; application faults, plugin conflicts, expired certificates and exhausted resources usually are not. Out-of-hours cover is only real if monitoring alerts a named person and a tested restore path exists.

A CDN helps when visitors are geographically distributed or you serve substantial static assets and media. It does not fix a slow origin, expensive database queries or uncacheable personalised pages. Measure where the time is actually going before buying one.

Sometimes, with a supported Node runtime, a persistent process manager and reverse proxy configuration. Image optimisation, caching and zero-downtime releases behave differently from a managed platform and need explicit setup. It works, but deployment and recovery become a designed procedure rather than a file upload.

When visitors are geographically spread, or you serve substantial static assets and media. A CDN moves cacheable content closer to people; it does nothing for a slow origin, expensive database queries or personalised pages that cannot be cached. Measure where the time actually goes before buying one.

Vercel removes operational work — builds, image optimisation, caching and rollbacks are handled — at a cost that scales with usage. Self-hosting is cheaper at steady high volume and gives full control, but you take on the Node runtime, process management, cache coordination, image handling and zero-downtime releases yourself.

Edge functions suit small, latency-sensitive work with no heavy dependencies — redirects, geolocation routing, header rewriting, A/B assignment. They are a poor fit for anything needing a database connection pool, large libraries or long execution. Most application logic belongs in a regional runtime near the data.

Deliberately, or it becomes the main source of complaints. Decide what is cached, for how long, and what triggers a purge — ideally tag-based, so publishing one page does not invalidate everything. A caching strategy without an invalidation path produces stale content and people who stop trusting the site.

It changes what your origin sees. Visitor IP arrives in a header rather than the connection, SSL mode has to match your origin configuration or you get redirect loops, and aggressive caching rules can serve authenticated pages to the wrong person. Each is straightforward once known and confusing when it is not.

Your site is down, and that is the trade for not operating infrastructure yourself. Mitigation is mostly about detection and communication: independent uptime monitoring rather than relying on the platform's own status page, and a documented plan for what you tell customers. True multi-provider redundancy is expensive and rarely justified.

Usually on bandwidth, function invocations, image optimisations and build minutes rather than a flat plan. Costs are modest until traffic or server rendering grows, then rise faster than most teams expect. Model your actual page views and rendering strategy against the pricing before committing, and set spend alerts.

Easier than most vendor lock-in, harder than the marketing suggests. A standard Next.js application ports reasonably well; platform-specific edge functions, image handling, caching primitives and analytics integrations do not. Keeping those boundaries thin is what preserves the option.

Compare business impact, root cause, support status, test coverage and migration risk over a two-to-three year horizon. A targeted fix suits an isolated defect. A rebuild needs justification from structural constraints — an unsupported platform, changes that routinely break unrelated features, or an inability to hire people willing to work on it.

With an audit: recovering access and accounts, inventorying repositories and environments, establishing dependency and version state, verifying that backups actually restore, and documenting how the system really deploys. That produces a risk picture before anyone commits to maintaining or replacing it.

Cost follows system size and how much is undocumented. The deliverable should be a prioritised findings list with reproduction steps, severity, effort estimates and a recommended sequence — not a tool export. It should be actionable by your own developers if you choose to implement it internally.

Usually, provided source and access exist. The practical questions are whether the runtime is still supported, whether dependencies can still be installed, and whether a working local environment can be reconstructed. Where a platform is genuinely end-of-life, containment plus a staged migration is more honest than indefinite maintenance.

Security patches are urgent. Minor versions should be routine and batched. Major versions need planning, regression tests and a rollback path. The expensive position is deferring everything until a security disclosure forces several major upgrades simultaneously under time pressure.

Updates and patching, backups with tested restores, uptime and error monitoring, defect response inside an agreed window, small changes, and periodic reporting on what changed and what risk remains. New features and redesigns should be scoped separately so the retainer stays predictable.

Usually, through a staged transition rather than a switchover. Common patterns are running old and new side by side behind a routing layer, migrating one workflow at a time, or rebuilding the frontend while the existing backend keeps operating. Each adds temporary complexity that has to be planned for.

Define the outcome and acceptance criteria before starting, migrate in vertical slices that each deliver working value, and keep the system shippable throughout. Projects overrun when the goal is described as replacing the system rather than as a sequence of specific, verifiable improvements.