01
AI agents and assistants
Voice agents, chat systems, internal assistants, RAG systems and tool-using AI applications.
AI PROJECT RESCUE
AI Project Rescue
Review what was promised, what exists and what should happen next with an independent recovery plan.
When to ask for a second opinion
You do not need to wait until a project has completely failed. An independent review can help when delivery, ownership, cost or technical progress no longer matches what was originally agreed.
Missed milestones
Deadlines continue to move without a clear explanation of what remains, what changed or why.
Repeated budget increases
Additional funding is being requested while the remaining scope, completion status or expected result stays unclear.
Unclear project status
You are receiving progress updates, but cannot independently confirm what has actually been completed.
Missing documentation
There is no reliable record of the architecture, requirements, deployment process, integrations or operating instructions.
Broken or incomplete integrations
The application works in isolation, but important connections to production systems remain unfinished or unreliable.
Unclear ownership or access
Repositories, hosting, domains, APIs, databases or administrative accounts are controlled by a vendor or individual.
Demo works, production does not
The system performs in a controlled demonstration but fails with real users, data, traffic or operating conditions.
The answer is always "more development"
You are being asked to keep investing without a clear assessment of what should be kept, fixed, replaced or stopped.
Projects we can review
The review can cover an active build, stalled implementation, vendor handoff, inherited codebase or proposed project before additional investment is approved.
02
Workflow automation
Automations connecting CRM, communications, documents, approvals, operations and other business systems.
03
Custom software
Business applications, internal platforms, portals, SaaS products and purpose-built systems.
04
Web and mobile applications
Customer-facing applications, MVPs, portals and digital products.
05
Data and machine learning systems
Data pipelines, predictive systems, model integrations, analytics and AI-enabled applications.
06
Integration projects
API connections, third-party platforms, CRM integrations, communications systems and multi-system workflows.
What we review
We compare the promised project against the evidence available today. The goal is to establish what exists, what works, what is missing and what would be required to move forward.
01 SCOPE
Scope and delivery
- Proposal and statement of work
- Requirements
- Milestones
- Change requests
- Delivery history
- Stated completion status
- Acceptance criteria
- Remaining work
02 SYSTEM
Technology and architecture
- Application architecture
- Repositories
- Databases
- APIs
- Integrations
- Hosting
- Deployment
- Environments
- Dependencies
- Technical documentation
03 CONTROL
Access and project control
- GitHub or other repositories
- Hosting accounts
- Domains
- Databases
- API accounts
- Cloud services
- Development tools
- Production systems
- Administrative access
04 OPERATIONS
Operational readiness
- What currently runs
- What has been deployed
- Existing vendor dependencies
- Setup instructions
- Testing
- Monitoring
- Support requirements
- Handover readiness
For AI projects, we go one level deeper
AI systems can fail even when the surrounding application works. Where applicable, we examine the AI layer separately from the software around it.
Model and provider configuration
Which models and services are being used, how they are configured and what the application depends on.
Prompts and agent instructions
System prompts, routing logic, tools, permissions, workflows and failure behaviour.
Knowledge and retrieval
Documents, vector databases, retrieval logic, data quality, citations and knowledge update processes.
Evaluation and testing
How responses or model outputs are being tested and what defines acceptable performance.
Guardrails and human review
Permissions, escalation rules, approval points and controls around higher-risk actions.
Cost and usage
Token consumption, API usage, infrastructure costs and areas where operating costs may scale unexpectedly.
Monitoring
Logging, failure tracking, model behaviour, latency, system errors and production visibility.
Data handling
What information enters the system, where it is stored and which third-party providers receive it.
How the review works
We investigate first. We do not start changing the project until the current state is understood.
01
Initial review
You explain what was promised, what has happened and what decision you need to make.
02
Evidence collection
We review the available scope, documentation, project history, repositories, accounts, environments and system access.
03
Technical assessment
We compare the documented requirements against what has actually been built and identify delivery, technical, ownership and handover risks.
04
Findings and recommendation
You receive a plain-language assessment of the current state, major risks, missing assets and recommended next actions.
05
Decision
You decide what happens next. Continue, modify the scope, recover the project, transition vendors, rebuild selected components or stop further investment.
What you receive
You receive a decision package designed to answer the practical question: What should happen next?
Current-state assessment
A plain-language description of what currently exists and the actual state of the project.
Scope comparison
What was expected, what appears complete, what remains incomplete and where evidence is unavailable.
Risk register
The main delivery, technical, ownership, access, security and dependency risks, prioritised by impact.
Missing-assets list
Accounts, documentation, source code, credentials, requirements or system information that still needs to be recovered.
Recovery priorities
The actions that should happen before additional development continues.
Technical findings
Material architecture, integration, deployment, data or AI issues that affect the next decision.
Recommended path
A written recommendation covering the reasonable next options and the implications of each.
Handover checklist
Where relevant, a list of the systems, accounts, documentation and access required for a controlled transition.
The review should lead to a decision
A rescue review is not useful if it produces another vague technical report. The findings should help you choose a practical next step.
01
Continue
The existing project is viable and the current delivery approach can continue with specific corrections.
02
Modify
The project remains viable, but scope, architecture, milestones or responsibilities need to change.
03
Recover
The project can be salvaged, but a structured recovery or vendor transition is required.
04
Stop or rebuild selectively
Further investment in the current approach may not be justified, or selected components may need to be replaced.
The purpose is not to recommend rebuilding by default. It is to determine which parts of your previous investment still have value and what should happen next.
Pricing
Start with the level of review that matches the decision you need to make.
AI Project Second Opinion
From CAD 1,000
Best for:
- Reviewing a proposal before signing
- Checking a project that has started to drift
- Validating a vendor recommendation
- Reviewing a defined technical concern
Includes:
- Project document review
- Scope and status assessment
- Identified concerns
- Second-opinion findings
- Recommended next step
AI Project Rescue Review
From CAD 2,000
Best for:
- Stalled projects
- Incomplete builds
- Disputed completion status
- Vendor transitions
- Missing documentation or access
- Projects requiring technical investigation
Includes:
- Project and scope review
- Technical assessment
- Available repository review
- Architecture and integration review
- Access and ownership review
- Missing-assets list
- Risk register
- Recovery priorities
- Written recommendation
Final scope depends on project size, number of systems, available documentation and the level of technical review required. Scope and pricing are confirmed before the review begins.
You do not need perfect documentation to start
Send what you have. Missing information is often part of the problem the review needs to identify.
Where available:
- Proposal or statement of work
- Requirements
- Invoices and change requests
- Project plans
- Status reports
- Application access
- Repository access
- Hosting information
- API and integration information
- Architecture documents
- Credentials controlled by your organisation
- Existing technical documentation
- List of known problems
If something is unavailable, we record it as part of the review rather than assuming it exists.
An evidence-based second opinion
01
Review before rebuilding
We assess the current system before recommending additional development.
02
Evidence over status reports
Findings are based on available requirements, access, repositories, systems and observable behaviour.
03
Separate findings from future work
The review should remain useful even if you choose another company to complete the project.
04
Plain-language findings
Technical issues are translated into business decisions, priorities and next actions.
Frequently Asked Questions
Do you need access to the source code?
Not always. We can begin with project documents, the application, requirements and available system information. Source-code access allows for a deeper technical assessment and may be required before making conclusions about architecture, code quality or recoverability.
Will you take over development after the review?
Possibly, but the review does not require you to retain Web Inventix AI for further development. The first objective is to determine the most practical next step.
Can you review a proposal before I sign it?
Yes. A second-opinion review can examine the proposed scope, requirements, architecture, integrations, ownership terms, delivery approach and technical assumptions before development starts.
Can you help with GitHub and source-code ownership?
We can assess who currently controls repositories, access, accounts and technical assets and identify what should be transferred for a practical handover. Questions involving legal ownership, intellectual property rights or contractual entitlement should be reviewed by qualified legal counsel.
Can you provide legal advice about a vendor dispute?
No. We provide technical and project findings. Those findings can help you and your legal counsel understand what exists, what appears incomplete and what technical evidence is available.
What if the current vendor will not cooperate?
We can review the information and access available to you and identify what is missing. The resulting missing-assets list can help structure a handover request or recovery plan.
Can you review a project built heavily with AI coding tools?
Yes. The review can include architecture, code structure, dependencies, deployment, testing, documentation and maintainability regardless of how the software was originally created.
How long does an AI Project Rescue review take?
Timing depends on the size of the project, the number of systems involved and the quality of the available information. The review scope and expected delivery period are confirmed before work begins.
NEED A CLEAR SECOND OPINION?
Find out what you actually have before spending more.
If an AI or software project is stalled, over budget, incomplete or difficult to verify, start with an independent review of the current state.
No obligation to continue into a development engagement.