Frequently asked questions

Lethavia can assess needs from small and mid-sized organisations, service businesses, associations, internal teams, and product founders that need to create or evolve software, an application, a platform, a professional website, digital commerce, or an automated workflow. Fit is evaluated around the problem, users, risk, stakeholder availability, and the organisation’s ability to make decisions during delivery. When a need falls outside the appropriate scope or requires a complementary specialist, that should be stated clearly at the beginning.

No. An honest description of the current process, the problem, the people affected, and the outcome you need is enough to begin. Discovery turns that information into priorities, boundaries, dependencies, user scenarios, and measurable success criteria. An existing requirements document can accelerate the review, but it should still be challenged so the project is not built around assumptions that are no longer accurate.

They are defined after a discovery phase proportionate to the initiative. Lethavia reviews priority capabilities, integrations, data, security, accessibility, content, target devices, internal responsibilities, and launch constraints. A proposal should identify what is included, what is excluded, the assumptions, deliverables, validation points, and the factors that may change the schedule or budget.

Yes, and that is often the safer approach. A useful first release can be isolated, tested with real users, and expanded in stages without weakening the technical foundation. Progressive delivery validates decisions earlier, limits risk, and directs investment toward the capabilities that create value. The stages still need to form one coherent system rather than a collection of temporary fixes.

Yes, after an assessment of the current foundation. The review should cover architecture, data, dependencies, known incidents, hosting constraints, and critical operating processes. The goal is not automatically to rebuild everything: parts of the system may be stabilized, isolated, replaced, or migrated progressively. Sensitive changes should include backups, rollback planning, and continuity measures.

Responsibilities and rights should be written into the agreement. The organisation should retain control of its domain, hosting accounts, data, and essential administrative access. Ownership of custom code, reusable components, third-party licences, and brand assets must be clarified before work begins. Lethavia favours a structure that avoids locking a client into an account the client cannot control.

These concerns are built into discovery, architecture, and acceptance criteria instead of being added at the end. Depending on the context, this can include data minimization, input validation, access control, secret management, useful logging, backups, upload limits, keyboard journeys, contrast, and assistive technology support. Controls should match the actual risk and applicable obligations; a simple public website has a different profile from a portal that handles sensitive information.

Yes. Routes, components, validation messages, metadata, content, and user journeys can be structured for Canadian English and Canadian French from the foundation. The goal is not merely to translate words, but to adapt language, formats, search intent, and market expectations. A prepared architecture can later support additional locales without duplicating the entire application.

A serious SEO migration begins with an inventory of existing URLs, indexed pages, metadata, internal links, and content that currently attracts traffic. Permanent redirects, canonical URLs, language alternatives, sitemaps, structured data, and performance should be checked before and after launch. No one can guarantee a particular ranking, but avoidable losses can be reduced substantially and changes can be measured through Search Console and Analytics.

Hosting, domains, environments, and deployment responsibilities are discussed according to the initiative. Lethavia can prepare the architecture, environment variables, production controls, and documentation, then support launch. The organisation should remain the owner of its primary accounts. Recurring costs, backups, provider limits, and emergency procedures should be understood before release.

The model depends on how much is known. A well-defined scope may be structured by phase or as a fixed engagement, while an initiative with meaningful uncertainty may begin with discovery. When priorities need to evolve during implementation, reserved capacity or time-based billing can be more appropriate. The model, boundaries, payment terms, validation points, and handling of additional requests should always be documented.

The request is reviewed to understand the need, identify obvious constraints, and determine whether an exploratory conversation is appropriate. Missing information is clarified before an estimate is prepared. A first discussion may then confirm the operating context, decision-makers, target schedule, indicative budget, and next step. Submitting the form does not automatically create a contractual engagement, and submitted documents remain subject to the site’s privacy rules.

Depending on the agreement, the next stage may include stabilization, error monitoring, security updates, performance work, operational support, documentation, training, and product evolution. Continuity should not be left implicit: responsibilities, response expectations, priority levels, backups, and the process for requesting changes are defined before launch. A well-delivered system should be understandable and maintainable by another qualified professional.

Measures should connect directly to the initiative’s goals: reduced processing time, fewer errors, adoption, conversion, satisfaction, performance, or availability. Analytics can measure general interactions without receiving personal information, while operational data should remain in the appropriate systems. A post-launch review helps distinguish technical issues, adoption challenges, and new opportunities for improvement.