AI in 90 Days: An Action Plan for Fast Results

AI in 90 Days: An Action Plan for Fast Results

Ninety days. Three months. That is enough time to go from "we should do something with AI" to a working system delivering measurable results.

Not a proof of concept gathering dust. Not a slide deck full of promises. A real AI solution, running in production, solving a real problem in your business.

This action plan lays out exactly how to make that happen, broken into three 30-day phases. It is the same framework we use at Felgor with our clients, refined through dozens of implementations across industries.

The pace is aggressive but achievable. It requires commitment, focus, and the willingness to start small. What it does not require is a massive budget, a team of researchers, or years of preparation.

Let us get into it.

Prerequisites: What You Need Before Day 1

Before the clock starts, make sure you have these three things in place:

Executive sponsorship. Someone with decision-making authority must champion this initiative. AI projects that lack executive backing die from organizational friction — budget approvals stall, stakeholders do not participate, and competing priorities take over.

A dedicated point person. Someone in your organization needs to own this project day-to-day. They do not need to be technical, but they need to understand the business problem deeply and have the authority to make decisions about requirements, data access, and user acceptance.

Budget allocation. For a 90-day AI project, plan for $30,000-$80,000 in total investment (including development partner fees and infrastructure). The exact number depends on complexity. Have the budget approved before Day 1 so financial discussions do not slow down execution.

With these in place, the clock starts.

Phase 1: Discovery and Strategy (Days 1-30)

The first 30 days are about making the right decisions. Rushing into development without this phase is the fastest way to waste your entire budget.

Week 1: Problem Identification (Days 1-7)

Day 1-2: Stakeholder Interviews

Meet with 5-8 key people across the organization. Ask each person:

• What is the most time-consuming repetitive task in your area?
• Where do errors or delays have the biggest impact?
• What decisions would be better with more data or faster analysis?
• What would you automate if you could?

Do not lead with "where should we use AI?" People will give you answers based on what they think AI can do (usually informed by marketing hype). Instead, focus on pain points. AI is the solution — let the problem emerge first.

Day 3-5: Problem Shortlisting

From the interviews, identify 3-5 candidate problems. For each, document:

• A clear problem statement in one sentence
• The estimated annual cost of the problem (in dollars, hours, or lost revenue)
• The data sources that exist for this problem
• The current process for handling it
• The key people involved

Day 6-7: Problem Selection

Score each candidate on impact (1-5) and feasibility (1-5). Multiply the scores. Pick the highest-scoring problem.

Be ruthless here. One problem. Not two. Not "a platform." One specific, measurable problem that, if solved, would make people's lives noticeably better.

Week 2: Data Assessment (Days 8-14)

Day 8-10: Data Inventory

For your selected problem, identify every relevant data source:

• Databases and data warehouses
• Spreadsheets and documents
• CRM and ERP records
• Emails and chat logs
• API endpoints and external data sources
• Sensor data or IoT feeds

Document each source: what data it contains, how much data exists, what format it is in, and who controls access.

Day 11-12: Data Quality Check

Pull samples from each data source and assess:

• Completeness (what percentage of fields are populated?)
• Consistency (are formats standardized?)
• Accuracy (do the values make sense?)
• Timeliness (how current is the data?)
• Volume (is there enough data for the intended approach?)

Rate overall data readiness on a 1-5 scale. If you are below a 3, add time to the plan for data preparation.

Day 13-14: Data Access and Privacy

Work with IT and legal to establish:

• How data can be accessed securely
• What privacy regulations apply
• Whether data can be used for AI training
• What anonymization or pseudonymization is required
• Data retention and deletion policies

Do not skip this step. Data access issues discovered during development are the number one cause of project delays.

Week 3: Solution Design (Days 15-21)

Day 15-17: Technical Approach

Based on the problem and data assessment, select the technical approach:

• RAG system: Best if the problem involves answering questions based on existing documents or knowledge bases. Requires no model training.
• Fine-tuned LLM: Best if the problem requires generating domain-specific text, following specific formats, or understanding specialized terminology.
• Classical ML model: Best for prediction, classification, or anomaly detection on structured data.
• Computer vision model: Best for image or video analysis tasks.
• Hybrid approach: Combining multiple approaches for complex problems.

For a 90-day timeline, RAG systems and classical ML models are the safest choices. Fine-tuning and computer vision are achievable but carry more risk.

Day 18-19: Architecture Design

Design the end-to-end system:

• Data pipeline: How data flows from source to the AI system
• Model/system: The AI component itself
• Integration: How the AI connects to existing systems
• Interface: How users interact with the AI
• Monitoring: How you will track performance

Keep it simple. The architecture for an MVP should fit on a single diagram.

Day 20-21: Success Metrics and Acceptance Criteria

Define exactly what "success" looks like:

• Primary metric (e.g., "95% accuracy on classification" or "50% reduction in processing time")
• Secondary metrics (e.g., "response time under 2 seconds" or "user satisfaction above 4/5")
• Acceptance criteria for moving from pilot to production
• Baseline measurements from the current process

Write these down. Get stakeholder agreement. These metrics prevent scope creep and "moving goalposts" later.

Week 4: Planning and Setup (Days 22-30)

Day 22-24: Project Plan

Create a detailed plan for the next 60 days:

• Sprint 1 (Days 31-45): Data pipeline + baseline model
• Sprint 2 (Days 46-60): Model optimization + integration
• Sprint 3 (Days 61-75): Testing + user validation
• Sprint 4 (Days 76-90): Launch + optimization

Assign responsibilities, set milestone dates, and identify risks.

Day 25-27: Environment Setup

Set up the technical environment:

• Development environment (cloud or local)
• Data pipeline infrastructure
• Model training environment (GPU access if needed)
• Version control and CI/CD
• Staging environment for testing

Day 28-30: Data Preparation Kickoff

Start the data preparation work that will feed into Sprint 1:

• Extract data from source systems
• Clean and standardize formats
• Create training/validation/test splits (if applicable)
• Set up data versioning

Phase 1 Deliverables

By Day 30, you should have:

• A clearly defined problem with stakeholder buy-in
• A complete data assessment with quality scores
• A technical architecture and approach selected
• Success metrics agreed upon
• A development environment ready
• Data preparation in progress

Phase 2: Development and Integration (Days 31-60)

This is where the building happens. Thirty days, two sprints, one goal: a working system ready for testing.

Sprint 1: Data Pipeline + Baseline Model (Days 31-45)

Days 31-35: Complete Data Pipeline

Build the pipeline that moves data from source systems to the AI system:

• Automated extraction from source systems
• Data transformation and cleaning steps
• Loading into the training environment or vector database (for RAG)
• Validation checks at each stage

The pipeline should be automated and repeatable. Manual data processing does not scale and introduces errors.

Days 36-40: Baseline Model

Build the simplest version that could work:

• For RAG: Set up the retrieval system, connect it to an LLM, test with sample queries
• For classification: Train a simple model (logistic regression or small gradient boosting) on your labeled data
• For prediction: Build a baseline model using standard features
• For fine-tuning: Run the first fine-tuning job with a small dataset

The baseline is not meant to be good. It is meant to establish a performance floor that you will improve on.

Days 41-45: Evaluation and Iteration

Evaluate the baseline against your success metrics:

• Where does it perform well?
• Where does it fail?
• What types of inputs cause problems?
• Is the data quality sufficient, or do you need to clean further?

Use these insights to plan Sprint 2. Common findings: the model needs more data in certain categories, specific data quality issues need fixing, or the approach needs adjustment.

Sprint 2: Optimization + Integration (Days 46-60)

Days 46-52: Model Optimization

Based on Sprint 1 findings, improve the model:

• Add more training data or improve data quality for weak areas
• Optimize hyperparameters
• Test alternative approaches if the baseline approach is hitting a ceiling
• For RAG: Improve chunking strategies, retrieval parameters, and prompt engineering
• For ML models: Engineer better features, try ensemble methods

Target: reach at least 80% of your success metric threshold. Going from 80% to 95% is an optimization problem; going from 50% to 80% might require a different approach.

Days 53-57: System Integration

Connect the AI to your existing systems:

• Build the API layer for real-time inference
• Connect to source systems for live data
• Integrate with the user-facing application (CRM, internal tool, website)
• Implement error handling and fallback logic

Days 58-60: End-to-End Testing

Test the complete system end-to-end:

• Data flows correctly from source to model
• Model produces accurate results on live data
• Results are displayed correctly in the user interface
• Error handling works as expected
• Performance is acceptable (response time, throughput)

Phase 2 Deliverables

By Day 60, you should have:

• A working data pipeline processing live data
• An optimized model meeting at least 80% of the success metric target
• Integration with existing systems
• End-to-end functionality tested internally

Phase 3: Testing, Launch, and Optimization (Days 61-90)

The final stretch. The system works technically — now you need to prove it works in practice and launch it.

Sprint 3: User Testing and Validation (Days 61-75)

Days 61-65: Pilot User Onboarding

Select 5-10 pilot users — people who will use the system daily and provide honest feedback. Choose a mix of enthusiasts and skeptics. Provide them with:

• A brief training session (30 minutes maximum)
• Clear instructions on what the system does and does not do
• A simple way to provide feedback (a form, a Slack channel, or a dedicated email)
• An escalation path for when the system fails

Days 66-72: Pilot Execution

Let the pilot users work with the system in their normal workflow. During this period:

• Monitor system performance daily (accuracy, response time, error rates)
• Collect user feedback continuously
• Track usage patterns (what features are used, what is ignored)
• Measure the business metric (is it actually reducing time, improving accuracy, etc.)
• Fix critical bugs immediately

Do not intervene unless the system is broken. The point of the pilot is to observe how the system performs in real conditions with real users.

Days 73-75: Pilot Review

Analyze pilot results:

• Did the system meet the success metrics?
• What feedback did users provide?
• What edge cases were discovered?
• What needs to change before wider launch?

Decide: proceed to launch, iterate further, or (rarely) pivot the approach.

Sprint 4: Launch and Optimization (Days 76-90)

Days 76-80: Pre-Launch Fixes

Address the top issues from the pilot:

• Fix the most impactful bugs
• Adjust the model for discovered edge cases
• Improve the user interface based on feedback
• Update documentation and training materials

Do not try to fix everything. Focus on the issues that would block adoption or cause significant errors.

Days 81-85: Full Launch

Roll out the system to all intended users:

• Communicate the launch clearly (what it does, how to use it, where to get help)
• Provide training sessions for new users
• Set up a support channel for questions and issues
• Monitor closely during the first week of full deployment

Days 86-88: Performance Monitoring

After full launch, monitor key metrics intensively:

• Model accuracy on production data
• System uptime and response times
• User adoption rates
• Business impact metrics
• Error rates and types

Compare against your success criteria defined on Day 20-21.

Days 89-90: Optimization and Roadmap

Based on the first week of full production:

• Identify the top 3 optimizations that would have the biggest impact
• Create a 30-day optimization plan
• Document lessons learned from the 90-day process
• Outline potential Phase 2 expansions (new features, new use cases)

Phase 3 Deliverables

By Day 90, you should have:

• A system running in full production
• Validated performance against success metrics
• Trained users actively using the system
• A monitoring dashboard tracking key metrics
• An optimization roadmap for continued improvement

What Realistic Results Look Like at Day 90

Let us set honest expectations. At the end of 90 days, you will have:

What you will have:

• A working AI system solving a specific business problem
• Measurable improvement over the previous process (typically 30-60% improvement on the target metric)
• A team that understands how AI works in practice, not just in theory
• A foundation for expanding AI capabilities across the organization

What you will not have:

• A perfect system (expect 85-95% of target performance, not 100%)
• A fully autonomous system (human oversight is still needed)
• A system that handles every edge case (these will be discovered over time)
• An AI strategy for the entire company (that comes next)

This is normal and expected. The 90-day plan delivers a strong foundation that you improve over the following months.

Common Pitfalls That Derail the 90-Day Plan

Week 1-2 Pitfalls

• Choosing a problem that is too broad. "Improve customer experience" cannot be solved in 90 days. "Reduce average ticket resolution time by 40%" can.
• Skipping stakeholder alignment. If key people are not bought in by Day 7, the project will face resistance later.

Week 3-4 Pitfalls

• Over-designing the architecture. The MVP architecture should be simple. Complexity can be added later.
• Data access delays. Start the data access process on Day 1, not Day 8. IT and legal approvals take time.

Week 5-8 Pitfalls

• Perfectionism in model development. An 85% accurate model shipped on time is better than a 95% accurate model shipped two months late.
• Skipping the baseline. Always build the simplest model first. It is your benchmark and your safety net.

Week 9-12 Pitfalls

• Insufficient pilot time. Do not compress the pilot to 3 days. Users need at least a week to give meaningful feedback.
• Ignoring change management. Technical launch without user preparation leads to low adoption.

For a more detailed step-by-step, read our complete guide on how to implement AI in your company. And learn about the Open Forge model: we build first, you pay later. Book your free diagnosis.

Conclusion

Ninety days is enough time to prove that AI can deliver real value for your business. Not in theory. Not in a demo. In production, with real users, solving a real problem.

The key is disciplined execution: clear problem definition, honest data assessment, focused development, rigorous testing, and commitment to iteration. Skip any of these, and the timeline stretches or the project fails.

The 90-day plan we have outlined here is the same approach Felgor uses with clients. We have refined it through real implementations and know where the risks are and how to mitigate them. If you want to put this plan into action with an experienced partner guiding the process, reach out. Ninety days from now, you could have a working AI system delivering measurable results.