You're searching "AI application development services" because you need to ship something. A customer chatbot. An internal data pipeline. An agent that runs procurement. You've talked to three vendors. They all say the right things. One of them is probably right. One is definitely wrong. The third is somewhere in the middle. The difference is in the details you haven't asked yet.

This checklist is not theoretical. It's built on contracts we've signed, proposals we've rejected, and post-launch fires we've helped teams put out because the contract didn't define what they were actually building. Read this before you sign. It will cost you three hours now or $200,000 later.

One thing no proposal warns you about: production code is not the public branch. When we audited a client's mobile application, the app version visible during demos was not the version in the live store. The actual shipped build was separated by dozens of commits - including commented-out subscription event tracking that had never made it to production, and a type casting error that was silently dropping every ad attribution event on iOS. Neither issue was visible on the branch the vendor presented. Buyers should always request access to the actual deployed artifact - the app in the store, the model weights in prod, the API endpoint serving real traffic - not the repository the vendor curates for sales calls. "We'll show you the code" is not the same as "we'll show you what's running." A vendor who cannot point to the production artifact is selling you a version of reality they control. This risk surfaces most clearly when attribution, compliance, or performance gaps become relevant after the contract is signed. The client we work with doesn't care about prompts or architecture. He cares: "Is my team doing less manual work?" That is the only number that matters - and it must be measured against the production system, not the demo.

The 5 questions before you sign any AI development contract.

Question 1: What's the evaluation methodology? And who defines "working"?

Every vendor will promise accuracy. Ask them: how will you measure it? If they say "we'll test it against your data" without defining a test set size, coverage distribution, or refresh schedule, they don't have a methodology yet-they have a hope.

Demand this in the SOW: "Baseline eval: 500 examples covering X, Y, Z use cases. Success criteria: 92% accuracy on held-out test set. Post-launch eval: monthly audits on 100 production examples." Numbers. Written down. Measurable.

The red flag: "We'll figure out the success criteria as we build." That means scope is undefined. When scope is undefined, you pay for the discovery twice.

Question 2: Who owns the models and your data?

This is the legal question everyone forgets until it matters. Ask: Does your vendor own the model they train? Do they own your training data? Can you use the model after the contract ends? Are there additional licensing fees if you want to fine-tune it yourself?

The right answer: You own the fine-tuned model. The vendor provides it on disk. Your data stays yours. You can continue to run the model without paying ongoing licensing fees. If you see anything else in the contract, negotiate it before signing. Ownership disputes after launch are expensive.

Question 3: What's post-launch support actually mean?

Every vendor offers "support." Most of them mean "we'll respond to your email." Demand specifics: response time (4 hours? 24 hours?), what's covered (model drift? integration bugs? API changes?), and the timeline (30 days? 90 days? indefinite?).

Include this language: "Post-launch, vendor provides bug fixes for 60 days at no additional cost. Model drift (defined as accuracy degradation >5% month-over-month) triggers re-evaluation and model tuning within 2 weeks." If they won't commit to a timeline, they won't care when your model breaks.

Question 4: How will they integrate this with your existing systems?

Integration is where most projects slip. Ask: Will they build the API integration or will you? Who handles the database connections? What if your system can't handle the model's latency requirements (the model takes 2 seconds to respond and your system needs answers in 500ms)?

Get this in writing: "Vendor provides API endpoint that responds in <500ms with >99% uptime. Vendor is responsible for integration testing on client's staging environment. Client is responsible for production deployment and monitoring." Clear lines of responsibility prevent blame-shifting.

Question 5: How do you handle scope expansion after launch?

You will want to expand scope after launch. Every client does. The contract should define the process and the cost. "We want this model to handle X as well" sounds simple. It requires re-evaluation, potential re-training, and new integration work. That's not a feature request. That's a change order.

Include: "Scope expansion requires: written request, 2-week evaluation period on the new use case, updated success criteria, amended SOW with additional fees (if any), and vendor sign-off." This keeps scope creep from eating your budget.

Those five questions define a solid engagement. But contracts have secondary language that kills projects. Watch for these.

Three red flags in AI development proposals.

Red flag 1: Vague deliverables.

"We'll build you a machine learning model." That's not a deliverable. It's an intention. A deliverable is "a fine-tuned GPT-4 Turbo model on your domain data, deployed to AWS Lambda, with latency <1s and accuracy >90% on the test set, available via REST API."

If the proposal uses words like "optimize," "enhance," or "improve" without numbers attached, they're not promising results. They're promising effort. Don't pay for effort. Pay for outcomes.

Red flag 2: No evaluation loop between build and launch.

Vendors who say "we'll build it and test it at the end" are planning to fail. The eval loop should start in week 2, run every sprint, and include your team. "Testing at the end" means surprises at the end. Surprises at the end mean delays or scope cuts.

Demand: "Weekly eval meetings. Real outputs tested on your test set. Success criteria reviewed each sprint. If drift is detected, immediate re-training window." Continuous feedback prevents last-minute disasters.

Red flag 3: "We'll figure out the stack as we go."

The vendor should have a technology decision before the contract is signed. What model architecture? Which fine-tuning method? What deployment infrastructure? "We'll decide based on your data" is code for "we're going to explore expensive options on your dime."

The proposal should say: "We'll use GPT-4 fine-tuning on your customer data with QLoRA for memory efficiency, deployed to your AWS account in a containerized API." Specific. Defensible. Predictable cost.

What a good statement of work actually contains.

Here are the 4 elements that separate amateur SOWs from ones that prevent disputes:

  1. Success criteria (in numbers): "92% accuracy on the held-out test set, latency <800ms on production queries, uptime >98% for the first 30 days."
  2. Milestones with deliverables: Week 2: data analysis report. Week 4: baseline model and eval results. Week 6: refined model. Week 8: API integration complete. Each milestone has a specific output and acceptance criteria.
  3. Roles and responsibilities: "Vendor handles model development and API deployment. Client handles production infrastructure, monitoring, and escalation to end-users." No ambiguity about who owns what.
  4. Scope boundaries: "This engagement covers custom classification on support tickets. It does not include sentiment analysis, entity extraction, or multi-language support. Scope expansion requires written change order."

A good SOW is boring. It doesn't promise the moon. It promises specific things that can be measured and defines exactly when the vendor's job ends.

Why JAAX structures engagements differently.

We've learned this the hard way. Most AI development services are structured around phases: discovery, build, test, deploy. That's waterfall for AI. It doesn't work because AI is unpredictable. You can't know if an approach will work until you've prototyped it.

We run 14-day sprints instead. Each sprint delivers a working model, real eval results, and a decision point. Continue? Pivot the approach? Expand the scope? The client sees code and metrics every two weeks, not a finished product on week 12. That visibility prevents $200,000 mistakes.

Sprint-based engagement also forces the clarity we just outlined. You can't do vague sprints. You can't "figure out the stack" mid-sprint. You can't skip evals. The methodology enforces rigor.

The final check before you sign.

Read the contract as if the vendor will disappear the day after launch. (That's not a risk-it's an assumption.) Can you operate the model without them? Do you have the code? The weights? The documentation? Will their API still work if they go out of business?

If the answer to any of those is "I don't know," don't sign. Ask them. The vendor who won't answer that question is selling you dependency, not capability.

You have a 2–4 week window to ask these questions. Use it. The difference between a $80,000 engagement that delivers and one that becomes a $240,000 write-off is in the questions you ask before you sign. Ask all five. Watch for all three red flags. Demand all four SOW elements. Then you'll be in the 40% of AI projects that actually ship something usable.

If you're evaluating multiple vendors and want a second opinion on scope, eval structure, or the contract language itself, our AI development company guide has a vendor vetting framework. Or reach out directly-we've reviewed hundreds of these contracts. We know what works and what doesn't.