Frequently asked questions

Not always. Where data or readiness is uncertain, an AI Opportunity Assessment is the responsible start, because it tests feasibility, quality and risk before you commit to production. If the use case is already clear and the data is understood, we can move to a prototype.

No. Prototype evidence does not automatically mean production readiness. Production AI needs evaluation, monitoring, security and human-oversight decisions appropriate to the use case, and prototype work does not include production hardening unless that is agreed.

No. We stay pragmatic about technology and vendors, and we make operational cost, reliability and provider dependence part of the design rather than an afterthought.

Usage costs are kept visible: they are separated from professional fees or capped by agreement, so a technically successful system does not become an unexpected cost.

That is the aim: Vitalos should be able to answer which model or provider processes your data, whether it is used for provider training, where it is stored, what retention applies, what tools and permissions an agent has, how outputs are evaluated and what happens when the model fails.

No. The work starts with how the process should run. Software, integration and automation follow the redesign, so the result is a better workflow rather than a faster version of the old one.

Only where replacement is the right answer. Often the bigger gain comes from connecting the platforms you already have so information flows automatically between them.

AI is combined with deterministic workflow automation and software integration where it creates measurable value. Bounded, measurable workflows come first.

Ownership after the engagement is made explicit before it ends. Your team can take over with documented handover, or Vitalos can continue to operate and improve the workflow under a defined service.

Yes, when the product objective is clear, requirements are understood well enough, constraints are known, decision-makers are available and dependencies are understood. Otherwise a short product discovery is the safer start.

Vitalos builds web platforms, portals, commerce and digital products. Routine brochure websites are generally not part of what we offer.

You can take over with documented handover, or keep Vitalos engaged for continuous product improvement against an agreed roadmap.

Yes. Interfaces are checked against the accessibility target agreed for the engagement as part of validation before release.

No. Modernisation can replace, re-platform or progressively refactor parts of the system in stages, chosen by risk and value.

Material legacy complexity is one of the cases where going straight to build is risky. An assessment establishes the architecture, dependencies and migration constraints first.

Responsibility is explicit at every stage. After transition, your team can take over with documented handover or Vitalos can operate it under Application Care.

Yes. For an inherited system the assessment also covers ownership and access, code and quality, security, data, operations and documentation before Vitalos commits to a plan or a service.

Not necessarily. The assessment shows whether connecting and governing existing sources is enough, or whether a new platform is justified.

Often. AI adoption depends on data foundations, governance and systems integration. Good reporting is valuable in its own right, and it is also the base that later AI work builds on.

Each important source gets an owner, lineage and quality expectations, and key metrics get documented definitions, so reports can be traced back to their data.

Once the foundation can be trusted, advanced analytics or AI can be built on it, under the same evaluation, monitoring and governance controls as any other production AI.

Yes, after an assessment. Acceptance is never automatic: we need to understand architecture, code ownership, dependencies, security, deployment, data responsibilities, known incidents and documentation first.

We do not promise outcomes before the assessment. It establishes what is wrong and what recovery involves, and it can conclude that a rescue is needed before any service starts, or that responsible support is not possible.

Then the assessment says so. Recovery, modernisation and replacement are all legitimate outcomes, chosen on evidence.

It moves into managed engineering or application care within a defined service boundary, or back to your own team with documented handover.