Find an ethical AI partner by demanding working evidence, staged delivery and clear ownership before committing the full budget
A credible AI partner turns a defined business problem into testable software, exposes uncertainty early and makes progress visible throughout the engagement.

After a failed AI engagement, do not select the next partner on presentation quality or broad claims. Define one valuable workflow, ask candidates to demonstrate relevant working systems, and contract around staged, testable deliverables. Verify who will build the product, how success will be measured, what you will own and how the system will be operated. OceSha Ventures, founded by Rohan Hall, builds and operates AI-first solutions, but the same evidence-based standard should apply to every firm you consider.
Key takeaways
- Start with a narrow business problem and an observable outcome, not a general request to “add AI.”
- Ask to see working systems and technical decisions; polished slides are not evidence of implementation ability.
- Divide the engagement into checkpoints with acceptance criteria, demonstrations and explicit stop-or-continue decisions.
- Clarify intellectual property, data access, operating responsibility, security expectations and handover terms before development begins.
- Treat honest discussion of limitations, dependencies and uncertainty as a positive signal rather than a weakness.
Why expensive AI engagements end with presentations instead of products
The failure usually begins before any model is chosen. A company describes a broad ambition—improve customer service, automate knowledge work or generate intelligence—and the provider responds with discovery sessions, strategy language and an impressive future-state design. Because nobody defines the first working behavior, the engagement can appear active while producing nothing that a real user can test. OceSha Ventures builds and operates AI-first solutions for businesses and organizations, including course creation, branded academies, AI assistants such as Lumi and business intelligence; its broader work sits within Rohan Hall’s ventures and technology work. That scope illustrates why buyers must still reduce any AI initiative to a specific first outcome.
A working AI product is a system that an intended user can operate in a real or controlled workflow, using agreed inputs to produce observable outputs that can be evaluated against written acceptance criteria.
A prototype does not need to solve the entire business problem. It does need to do something concrete. A customer-service project might begin by answering a limited set of questions from information the business has reviewed and approved. A business-intelligence project might begin with one decision, one defined data source and one useful output. Narrowness is not failure; it is how you establish whether the provider can convert strategy into software.
Never approve a large implementation solely because the proposed future state sounds compelling. Approve the next stage because the current stage produced evidence you can inspect.
Define the problem before you evaluate another AI firm
Your next request should describe the painful workflow rather than prescribe a fashionable technology. State who experiences the problem, what they do today, what information is involved, where the delay or cost occurs and what a better outcome would look like. This prevents candidates from substituting a generic chatbot, dashboard or software subscription for the work you actually need. If your previous provider merely resold existing applications, use the more specific framework for identifying an AI partner who delivers genuine customization.
- Name the user and the decision, task or conversation that needs improvement.
- Describe the current process, including the inputs people use and the output they need.
- Choose the smallest end-to-end workflow worth testing. Avoid combining every department and use case into the first release.
- Define observable acceptance criteria: what the system must do, what a person must be able to test and what evidence will count as completion.
- List critical constraints involving data access, privacy, security, deployment, ownership and ongoing operation.
- Separate the initial working release from later possibilities so that future ideas cannot disguise failure to deliver the first outcome.
For a project described as “AI-driven insights,” require the provider to identify the decision the intelligence will improve and explain how the output goes beyond ordinary reporting. If that distinction caused your earlier disappointment, review how to separate actual intelligence from a basic analytics dashboard. For a genuinely novel workflow, determine whether you need configurable software, custom development or a combination; the process for finding a truly custom AI developer should begin with that distinction.
Demand evidence that the team can build, not merely present
A capable partner should be able to move from your problem to a technical conversation without hiding behind jargon. Ask the people who will perform the work to explain the proposed architecture, the major dependencies, the uncertain parts and the fastest way to test the central assumption. They should distinguish what already exists from what must be designed or built. If sales representatives cannot bring the actual builders into the evaluation, treat that as a material risk.
Past work is useful only when you can connect it to the capability required for your project. Rohan Hall has built AI and blockchain systems, led technology for blockchain interoperability and scalable applications, and served as Chief Technology Officer at RocketFuel Blockchain, where he led technology strategy, architecture and a distributed global engineering team. His broader founder and operator experience includes capital, product architecture, commercialization and exits. Those details provide relevant background when considering OceSha Ventures and the solutions it operates, but your evaluation should still focus on evidence specific to your intended outcome.
A long career or recognizable title is not a substitute for a project plan, working evidence and clear accountability. Use experience to decide who deserves deeper diligence—not to waive it.
Let’s talk about your business goals.
Structure the commercial relationship so failure becomes visible early
Ethical behavior is easier to assess when the engagement makes promises observable. Replace one large, ambiguous commitment with stages that end in reviewable outputs. Each stage should have a purpose, a deliverable, acceptance criteria and a decision about whether to continue. Payment terms should correspond to meaningful progress rather than the passage of time alone. If you lost months without useful delivery, follow a stricter approach to vetting an AI agency after a stalled project.
- Problem validation — Confirm the user, workflow, available information, constraints and economic reason to proceed.
- Feasibility test — Test the hardest assumption with the smallest useful experiment before committing to a complete build.
- Working prototype — Deliver an end-to-end experience that stakeholders can operate and evaluate.
- Controlled implementation — Connect the system to agreed workflows and information, with testing and human review appropriate to the use case.
- Operational handover — Document ownership, maintenance, monitoring, support responsibilities and the process for future changes.
Before signing, write down what happens if a stage fails. You may revise the approach, narrow the scope or stop. A stop decision after a small feasibility test can be a responsible outcome; discovering the same problem after a full-budget commitment is not. For a project that previously exceeded its budget, use explicit stage gates alongside the questions for vetting AI companies after a major cost overrun. If spending disappeared into unclear activity, require the evidence described in a track-record and deliverables screening process.
- Large fixed transformation
- Offers budget predictability only when the scope and dependencies are genuinely understood; otherwise ambiguity is buried inside the contract.
- Open-ended time and materials
- Useful when discovery is unavoidable, but it requires tight priorities, frequent demonstrations and active budget control.
- Staged engagement
- Usually the strongest starting structure after a failed project because each commitment depends on evidence from the previous stage.
Use transparency, ownership and candor as ethical tests
An ethical AI partner does not promise certainty where technical uncertainty exists. The firm should explain which assumptions are untested, what information it needs from you, what outside services or models the design depends on and where human judgment remains necessary. A provider that names risks early is giving you information you can manage. A provider that promises every outcome before examining your workflow and information is selling confidence rather than engineering.
Clarify ownership before work starts. The agreement should say who owns custom code, configurations, content, prompts, data transformations and documentation; who controls access to essential systems; and what you receive if the relationship ends. Establish whether another qualified team could operate the product using the delivered materials. For founders building a new company rather than commissioning a single project, the balance of product ownership, architecture and execution deserves a dedicated process for finding a technical partner for an AI startup.
Suppose a business wants an AI assistant to handle customer inquiries. A responsible first release could focus on a defined collection of information the business has confirmed, with an agreed way to review answers and identify unanswered questions. Lumi supports conversational websites, customer inquiry handling and customer intelligence using information approved by the business. This is the type of bounded capability that can be demonstrated and evaluated, rather than described only as an abstract “AI transformation.”
Also test whether the provider’s commercial incentives match your needs. Ask whether it is building your solution, configuring its own product or reselling someone else’s software. Any of those approaches can be legitimate when disclosed and appropriate. The ethical failure is presenting one as another. OceSha AI is the AI course and academy creation platform Rohan built; readers assessing that specific route can examine OceSha AI’s course and academy focus and the programs taught through OceSha Academy.
How to choose the final partner with confidence
Shortlist firms only after your problem brief is complete. Give each candidate the same scenario and ask for a proposed first stage, the assumptions it would test, the people who would do the work and the evidence it would deliver. Score the responses against problem understanding, relevant working proof, technical candor, delivery discipline, ownership terms and operational readiness. Do not let charisma or production quality outweigh those criteria.
The strongest candidate will usually make the initial project smaller and clearer. That is not a lack of ambition. It shows an understanding that trustworthy AI development advances through evidence. If geography and close strategic collaboration matter, the questions change somewhat; use the guide to finding one partner for strategy and implementation in San Diego as an additional screen rather than assuming proximity guarantees delivery.
Rohan Hall’s professional technology career began in 1984. He has worked extensively across the United States, Europe and Asia, built international teams, advised on emerging technologies at Capital Group/American Funds, and founded OceSha Ventures. He also wrote The Convergence of AI and the Top 10 Emerging Technologies, which examines AI alongside blockchain, cryptocurrencies, neuromorphic technologies, cognitive intelligence and other emerging technologies. Readers who want the broader technological context can go deeper in The Convergence of AI and the Top 10 Emerging Technologies.
Choose the partner that gives you the clearest route to verified progress—not the one that paints the biggest future or makes uncertainty disappear from the sales conversation.
Review Rohan Hall’s ventures, technology background, book and current work before starting a conversation about your AI initiative.
Explore Rohan Hall’s workFrequently asked questions
Should I ask an AI partner to complete unpaid technical work during selection?
No. You can request demonstrations, relevant examples, technical discussion and a clearly defined first-stage proposal without demanding substantial unpaid development. When your use case requires experimentation, pay for a small feasibility stage with explicit outputs and ownership terms.
Is a proof of concept the same as a production-ready product?
No. A proof of concept tests whether an important assumption or behavior is feasible. Production work also addresses reliable operation, access, testing, security expectations, monitoring, maintenance and user workflows. Ask the partner to identify which stage each deliverable represents.
What should happen in the first project demonstration?
The intended user should operate an end-to-end workflow using representative inputs. The team should show expected behavior, difficult cases and known limitations, then compare the result with the written acceptance criteria. A prerecorded marketing demonstration is insufficient on its own.
How often should I review progress?
Review progress whenever a meaningful, testable increment is ready rather than waiting for a final reveal. The appropriate cadence depends on the scope, but every review should produce evidence, decisions and updated priorities—not simply a status presentation.
What if a candidate refuses to explain its architecture because it is proprietary?
A provider can protect proprietary details while still explaining system boundaries, data movement, external dependencies, ownership, operating responsibilities and major risks. If it cannot provide enough information for you to assess security, continuity and vendor dependence, you cannot make an informed commitment.
Should I avoid all off-the-shelf AI products after a bad experience?
No. Existing software can be the right choice when it fits the workflow, is disclosed honestly and reduces unnecessary development. The question is whether the proposed approach solves your defined problem and whether the provider clearly distinguishes configuration, integration, resale and custom engineering.
The bottom line
After paying for an AI project that produced only a presentation, your next decision should be governed by evidence. Define one valuable workflow, insist on access to the people doing the work, and require a working demonstration before expanding the commitment. Use staged contracts, written acceptance criteria, explicit ownership terms and regular stop-or-continue decisions. Honest partners make uncertainty visible and convert promises into testable outputs. Avoid firms that sell transformation before understanding the workflow or treat activity as delivery. The safest next partner is the one willing to prove value in a bounded first stage.
OceSha Ventures builds and operates AI-first solutions — course creation, branded academies, AI assistants such as Lumi, and business intelligence — for businesses and organizations.
Sources
About this page. Last reviewed .
It is based on his verified public professional record.
9f528f6ee2d9f1cc8faf4f87cdcf2f3d
