- AI projects fail most often because talks with developers start while the problem is still vague. Picking the wrong developer is a less common cause.
- If the problem is vague, each vendor will propose something different, and you won't be able to compare prices at all.
- Before you invite proposals, have a one-page document that states the problem, who will use the system, what data you have and how results will be measured.
1. Get the company ready before you look for a vendor
When you build a house, you don't walk up to a contractor and ask, “What kind of house should I build?” You first tell them how many people will live there, what your budget is and how wide the plot is. Software projects work the same way.
Appoint a Business Owner who has the authority to change the process and can answer questions. Don't leave IT or an executive assistant to act as the only coordinator, because the key decisions concern rules, risk and KPIs. Without an owner, the developer gets slow answers and fills the gaps with assumptions.
Gather baseline data: volume of work, time per step, errors, cycle time, headcount and cost. If you don't have the numbers yet, ask for a Discovery Phase to collect them. Don't ask for a price on a full system based on a description like “we want AI to help the company,” because each proposal will interpret it differently and you won't be able to compare them.
Set a budget range and a timeframe, along with your constraints: data must be stored in the country, existing systems must be used, customer data must not leave the company, or there are critical peak days. Being open about this lets vendors propose an architecture that fits, instead of one that is over-designed or falls short of what you need.
2. Write a one-page Business Brief before you write a feature list
A single page that says what the problem is, who will use the system, what data already exists and how results will be measured makes every vendor propose against the same problem, so you can genuinely compare their proposals.
Start with the problem and its impact, for example: “Six admin staff process 4,000 orders a month, taking 12 minutes each on average, with a 3 percent error rate, and we have to hire one more person every time volume grows 20 percent.” Then write the target outcome, such as cutting touch time to 4 minutes and handling 50 percent more volume without adding staff.
Describe the current workflow, the data channels, systems, people involved, exceptions and the damage done when something goes wrong. State what is out of scope, for example no payment approvals yet, no change to the ERP, or no automatic replies to customers yet. Writing down what is excluded keeps the project from growing midway.
Avoid locking in a technology too early, as in “we must use an AI Agent,” when the job is really moving data according to rules. The vendor should explain which parts use automation, which parts use AI, and why. A less clever solution is often cheaper and more stable.
3. Prepare your data and systems so developers can assess them
List your data sources: CRM, ERP, databases, email, file storage, spreadsheets, manuals and external data. Note the owner, format, volume, update frequency, quality and access rights of each. Be honest about personal files and steps that happen outside the system, because these are often the biggest integration cost.
Prepare a varied set of samples, at least 50 to 100 of them, covering typical cases, incomplete data, messy language and exceptions, along with the correct answer for each or a way to check it. Without ground truth, the model can't be evaluated and the demo will only pick the easy cases.
Check the requirements that apply to personal data, trade secrets and customer contracts. Decide which data can be used for development, whether it must be masked, how long it is kept, and whether the model provider uses it for training. Don't send production data to a vendor before an NDA, access rights and a suitable channel are in place.
| Data item | Question | Effect on the project |
|---|---|---|
| Quality | How complete, accurate and up to date is it? | Accuracy and preparation time |
| Access | Is there an API, or can it be exported? | Integration cost |
| Permissions | Who can read, write and delete? | Security design |
| Volume | How much per day, and at peak? | Infrastructure and running costs |
| Retention | How long are logs and outputs kept? | Compliance and cost |
4. Define the pilot scope and KPIs before you ask for prices
The pilot's job is to test the main risk, so it doesn't need a full set of screens. Define one or two input channels, one main output and only the integrations you need. State the number of users and the test volume. Ask vendors to price Discovery, Pilot, Production and Maintenance separately so you can see the commitment one stage at a time.
For the development team · Technical metrics
KPIs should cover business, quality, technical performance and cost, for example: 60 percent less time per item, 98 percent accuracy on mandatory data, a P90 response under 10 seconds and a cost of no more than THB 5 per item. Define the acceptance test and who decides whether it passes.
- Who uses it, and when the system's work starts and ends
- Where the data comes from and where results are written back
- Which cases the AI handles and which need human approval
- What counts as an error, and which dataset it is measured against
- What is delivered at the end of the pilot, and who owns it
5. 15 questions to ask an AI development company
- Can you explain our business problem and KPIs in your own words?
- Which parts should use AI, which should use ordinary automation, and why?
- How will you measure accuracy with real data, and who defines the ground truth?
- How does the system handle incomplete data, conflicting instructions and out-of-scope cases?
- Which models and providers will be used, and will our data be used for training?
- Which country or region will our data be sent to, how is it encrypted, and how long is it kept?
- How are the permissions of the agent or system restricted, and where does human approval come in?
- How do you prevent prompt injection, data leaks and duplicate actions?
- What logging, monitoring, budget alerts and incident response are in place?
- If the model API or a source system goes down, how does the business keep running?
- What is the cost per item and per month at low, medium and high volume?
- Who owns the source code, prompts, workflows, data and outputs?
- How hard would it be for us to switch models, move hosting or change vendors?
- After handover, who takes care of the SLA, security patches and evaluation, and what does that cost?
- Can we see a similar production system, and hear the lessons from projects that didn't succeed?
The quality of the answers matters more than the confidence behind them. A good vendor admits what it doesn't know yet, asks for data to make an assessment, and proposes trials that reduce risk. A seller who guarantees high accuracy without having seen your data, or who says the AI learns everything by itself, deserves closer scrutiny.
6. Read past the word “AI” to see what a proposal really contains
For the development team · Feature list
A proposal should include the process flow, architecture, data flow, roles, assumptions, deliverables, timeline, acceptance criteria, security, cost model and exclusions. A list of features and some screenshots are not enough to assess a production system. Ask the vendor to show how data moves when things succeed, when they fail and when an external system goes down.
For the development team · Technical detail
Compare proposals on the same scope and the same scenarios. Don't choose on the final lump-sum price alone: some vendors include Discovery, deployment and support, while others price only a prototype. Build a 24-month total cost table covering API, hosting, maintenance, licenses and the changes you can foresee.
For the development team · Technical detail
Check whether the timeline leaves room for data work, integration, user testing, a security review and a parallel run. A promise to build fast may hold for a demo, but production means testing the exceptions and preparing people for the change in their work. Don't force a go-live to meet a marketing date if the guardrails haven't passed yet.
7. What matters in the contract and in ownership
For the development team · Technical detail
Spell out the rights to the source code, configuration, prompts, evaluation dataset, generated data, documentation and custom connectors. Separate what is newly built from the vendor's existing assets. If open-source components or external services are used, their licenses and limitations must be disclosed.
For the development team · Technical detail
Define data processing, confidentiality, subprocessors, where data is stored, retention, deletion at the end of the contract and incident notification. State the audit rights, or the standard evidence the vendor must provide. For important data, there should be a separate environment, and production data must not be used for testing without approval.
For the development team · Technical detail
Build an exit plan from the start: the format in which data and logs are exported, how credentials are handed over, whether there are deployment documents and a runbook, how many days the vendor will help with the transition, and whether the system keeps running when the contract ends. Some lock-in may be acceptable if it saves money and is clearly understood, as long as you chose it deliberately and didn't discover it later.
For the development team · Technical detail
Tie milestone payments to deliverables and acceptance, with time as only one factor: for example, a Discovery report, a pilot that passes the test set, production readiness and go-live stabilization. Define how change requests are handled so that every new requirement doesn't turn into a dispute.
8. A selection process that is fast without being risky
- Shortlist 3 vendors: Look at relevant experience, integration capability and understanding of your business.
- One shared briefing: Give everyone the same data, scope and KPIs. Run a Q&A in which important answers are shared with all vendors equally.
- Solution workshop: Have the vendor's actual team work through the process and its exceptions with you. Pay more attention to how they think than to their sales slides.
- Paid Discovery/Pilot: For complex problems, pay the vendor to prove the risky parts using protected data, instead of asking for a superficial unpaid demo.
- Reference check: Ask existing customers about life after go-live, the actual costs, incident response and knowledge transfer.
- Scorecard: Score business fit, technical ability, security, team, cost and exitability, with the weights set before you open the prices.
These weights are only an example. Regulated businesses should give more weight to security and compliance. Don't leave end users without a say, because a system that is cheap but hard to use creates shadow processes and doesn't actually reduce headcount.
9. What you should see in the first 30 days
For the development team · Technical detail
Week one should confirm the baseline, process map, owners, data access and risk register. Week two should produce a prototype of the main path and the first evaluation set. Week three tests real data in shadow mode, and week four delivers comparative results with a decision on whether to move to production or revise the assumptions.
Hold a short weekly decision meeting, with demo, metrics, risks and decisions kept separate, and spend little of it reporting activity. The owner must clear data or rule blockers quickly. If the company's own team doesn't deliver samples and feedback on time, the vendor cannot make up for it with technology.
Start planning the change to people's work in the first month. Define the new SOPs, the reviewers, the fallback systems and how value will be captured, for example by stopping overtime or not filling new positions. If you wait until the system is finished to talk about people, the company will have one more AI system while keeping all its old steps and costs.
In short: Choosing an AI development company starts with your own readiness as the client. Write down the problem and the KPIs, prepare real data, define the pilot scope, ask about errors, permissions, costs and the exit plan, and then tie the contract to results. The right developer will do more than produce a fast demo: it will help you get a system that works in practice, can be measured, is secure and can be maintained by your company.
Get the problem and the data ready before you invite proposals from developers
We wrote this article so you can talk to every developer on equal terms, including us. The most common reason projects fail is starting the conversation while the problem is still unclear, more often than choosing the wrong developer. Each vendor then proposes something different and the proposals can't be compared. The knowledge of your processes and data sits with your team. What DNA Maker can help with at this stage is asking the right questions and helping you put together a one-page Business Brief that sets out the problem, the users, the scope, the data you have and how results will be measured.
What to have in hand before you talk to anyone
Once the problem is clear, development can start with a clear direction. We usually suggest beginning with a short feasibility phase at a clearly stated price, so both sides see real data before committing for the long term. It comes with agreements on ownership of the code, data and documentation, so you can change developers in the future without being locked in. If you are about to issue a request for proposals, send us your draft brief and we'll help you find the gaps, even if you end up working with someone else.
SOFTWARE ENGINEERING GLOSSARY
Software engineering glossary
These terms make development proposals and contracts easier to read.
| Term | What it is | A simple example | What executives should ask the development team |
|---|---|---|---|
| Business Brief | A short document stating a project's problem, users, scope and success criteria | A one-page document that every developer uses to prepare a quote | Are all the vendors proposing against the same problem? |
| Statement of Work | A document setting out the scope of work, the deliverables and the acceptance conditions | States what this phase delivers and when it counts as done | Are the acceptance conditions written down clearly yet? |
| Acceptance Criteria | The agreed criteria for what kind of work counts as a pass | The system must read documents in this format correctly, to the agreed standard | Who decides whether it passes, and with which dataset? |
| Source Code Ownership | The agreement on who owns the code and documents that are developed | The company owns the code and keeps it in its own systems | If we change developers, what do we take with us? |
| Handover | Handing over the system, documentation and knowledge to the team that will maintain it | Manuals, the system structure and full access rights are all handed over | After handover, who maintains it, and on what terms? |