How do we choose the right service?
Start with the business problem and the decision the finished work must make easier. A public credibility or lead-generation need usually begins with Business Websites. Product sales point towards E-commerce Experiences, while authenticated workflows belong under Web Apps & Client Portals. Repetitive cross-system work may fit AI & Business Automation. Identity and post-launch care have their own boundaries. Avidni maps the scope to the nearest service and names any genuine dependencies, without making a buyer purchase all six.
What determines project scope and timeline?
Timeline follows the number and complexity of user journeys, content readiness, integrations, data migration, security requirements and the availability of decision owners. A focused site with approved material has fewer unknowns than a portal with roles, files and external systems. Discovery turns those variables into milestones and acceptance criteria before a commitment is made. Avidni does not publish a universal delivery promise because a fast estimate that ignores dependencies creates more risk than clarity.
What does Avidni need before work starts?
A useful start requires a named business owner, an agreed audience, the current problem, known constraints and access to relevant existing material. Brand assets, product data, policies, analytics or system documentation can follow through a controlled content plan when they are not ready on day one. Avidni also needs to know who can approve scope, content and launch. Missing information is recorded as a dependency, not filled with assumptions that later become rework.
Who is responsible for copy, product data and approvals?
Responsibility is agreed in the scope. Avidni can structure, write or edit public copy where that service is included, but the client remains responsible for factual accuracy, legal statements, prices, product information and final approval. The project names one decision owner and a practical review path so feedback does not arrive as conflicting individual notes. Delayed material or approvals can move the release plan, and that impact is made visible rather than absorbed silently.
How are domains, hosting, CMS access, source files and analytics handled?
The scope records the relevant accounts, named owners and access required for launch and support. Avidni avoids hiding a domain or analytics property inside an unexplained personal account. CMS access, handover material and source-file delivery are defined according to the service and commercial agreement. Hosting and software providers remain responsible for their own infrastructure layers. Where an existing account cannot be transferred or safely shared, the project documents an alternative and the operational consequence before release.
Can Avidni work with an existing website, store or system?
Yes, after a practical audit. Avidni reviews the current platform, content, access, analytics, dependencies, security posture and the cost of preserving what works. Some engagements are best handled as a focused improvement or migration; others need a rebuild because the existing foundation cannot support the approved requirement safely. The recommendation is tied to evidence and operating cost, not a preference for starting over. Third-party licences and provider limitations are surfaced before they shape the estimate.
How are integrations and third-party providers evaluated?
An integration is assessed by the business owner, available API or data boundary, authentication method, rate limits, privacy implications, failure behaviour and ongoing provider cost. A visual promise on a vendor page is not enough. Avidni confirms what can be tested and who owns credentials, support and escalation. If the provider cannot offer a stable or lawful path, the risk is documented and the scope may use a manual boundary instead of pretending the connection will be reliable.
How are scope changes handled?
New requests are compared with the approved scope, dependencies and release goal. A small clarification may fit inside the current work, while a new workflow, page family, integration or approval rule can require a written change with cost and schedule impact. The client sees that impact before the change is accepted. This protects the agreed launch and prevents useful ideas from disappearing into informal messages with no owner, estimate or testing plan.
How are accessibility, performance, security and privacy responsibilities divided?
Avidni implements the agreed interface, technical controls and testing within the delivered system. The client remains responsible for accurate content, lawful processing decisions, access approvals and operational use. Hosting, payment, messaging and other providers retain responsibility for their own services. Accessibility and performance are tested against the supported content and devices; security and privacy work is proportional to the data and risk. No website can be described as permanently secure, compliant or fast under every future condition.
What happens during testing, launch and handover?
Testing covers the agreed user journeys, responsive layouts, accessibility, content, forms, permissions, integrations and relevant failure states. Named decision owners review against acceptance criteria instead of taste alone. Launch includes the necessary domain or deployment work, analytics checks and a rollback or recovery path where applicable. Handover records accounts, access, operating guidance and remaining responsibilities. Training is scoped to the editors or operators who will actually maintain the work.
What support is available after launch?
Avidni can provide a defined Care & Growth Retainer for maintenance, content, analytics, hosting support and agreed improvements. The lane, reporting rhythm and boundaries are documented so support does not become an untracked promise. Major features, redesigns and new integrations are estimated separately. Provider incidents may require coordination with the responsible vendor. A specific response target or round-the-clock cover applies only when it is written into an approved commercial agreement.
How is an estimate developed without a public price list?
The estimate follows the agreed outcome, deliverables, content responsibility, integrations, data risk, review process and post-launch requirement. Avidni identifies assumptions and exclusions beside the cost so buyers can compare a real scope rather than an attractive number with missing work. A range may be useful early, but it is not treated as a final quotation until the important dependencies are known. This repository does not contain approved public starting prices, so none are invented here.
Can Avidni work with teams outside Nairobi or Kenya?
Yes. Nairobi-based and remote collaboration use the same named decision owners, documented reviews and clear handover. Workshops, content reviews and approvals can be run online for teams elsewhere in Kenya, East Africa or international markets. The scope accounts for time zones, currencies, provider availability and any local legal or payment facts that need client or expert confirmation. A location is not added to a project record merely because of its domain name.
What normally sits outside a service scope?
Typical exclusions include unapproved content production, legal advice, paid-media management, unlimited revisions, provider fees, print production, unsupported legacy software, ongoing data entry and new features that were not part of the accepted release. The exact boundary depends on the service and is written into the estimate. Avidni will not present a third-party platform's performance, payment settlement or uptime as its own guarantee.
Can we begin with one service and add another later?
Yes. A focused website, identity refinement or maintenance audit can be a sensible first engagement. The important point is to avoid decisions that make the next likely step unnecessarily expensive. Where future commerce, portal or automation work is already known, the initial information architecture, accounts and data ownership can allow for it without building unused complexity. Any later service still receives its own scope, evidence and approval rather than being assumed inside the first project.