"You can't build anything that works in a week" is an objection we hear at every other demo. It's fair. For custom development. When a system is written from scratch, half a year is an optimistic timeline, and Kazakhstani companies have already confirmed this on their own pilots. A prototype on the platform works differently: we write nothing from scratch, we configure ready-made blocks for your scenario. Hence the one week.
Where the time goes in a custom project
Break any AI project down into its parts and you'll find that the "intelligence" is the smaller share of the budget. 70–80% of the time is eaten by the plumbing: integrations with the CRM, the accounting system and telephony, permission controls, task queues, failure handling, logging, control interfaces. All of this takes months to write and has nothing to do with how smart the model inside is.
On the platform, the plumbing is already built. Agents can connect to systems through APIs, and where there is no API, they work through the interface, like an employee, with buttons and forms. Events – a new call, an incoming document, a new row in the database – trigger processes on their own. Every step is written to the action log. For a specific client, all that remains is to configure the scenario: what the agent should learn from your examples, where its checkpoints are, what counts as the correct result. That is the week of work. The list of ready-made blocks is in the description of the platform's capabilities.
What's included in a one-week prototype?
A prototype is not a presentation and not a "demo on test data". It is a working agent, limited in scope:
- one scenario, for example parsing incoming calls or checking a document package;
- your real data: 30–100 examples that you hand over at the start of the week;
- a configured agent with the logic of your process and your terminology;
- a control run on examples the agent didn't see during configuration;
- a demo with an error review and quality figures.
What the prototype doesn't include: connection to live systems, the full volume of data, and uptime commitments. The limitation is deliberate. The point of the week is for you to see the quality on your own examples before anyone spends serious money.
How the week goes, day by day
| Days | What happens | Your involvement |
|---|---|---|
| 1 | Kickoff call: we lock in the scenario, the metric and the data list | 60–90 minutes, process owner and IT |
| 2 | Data handover, we spin up an isolated working environment | 2–3 hours of an IT specialist's time for the export |
| 3–4 | Configuring the agent, first runs, clarifying questions for the owner | Two or three 15-minute calls |
| 5–6 | Control run on held-out examples, quality measurement | Not required |
| 7 | Demo: results, errors, the economics of the scenario | 60 minutes, the whole working group |
On the calendar, the week sometimes stretches to nine or ten days, almost always because of getting the export approved on the client's side. That's normal: the bottleneck here isn't the technology, it's internal procedures.
What you'll see at the demo
The demo isn't slides, it's a screen with your data from yesterday. Friday, 10:00, an engineering equipment supplier from Astana. On the screen: 38 sales-team calls from Wednesday. For each one the agent assembled a call summary, determined the next step, filled in the deal card; it flagged five calls as "needs a human", and the action log shows exactly why. The department head opens three records at random, listens, cross-checks. We find two errors together: the agent was confusing prepayment with postpayment in Kazakh-language dialogues, we fix the instruction right there in the meeting and rerun. The demo answers questions no presentation can close: how the agent behaves with your terminology, with a mix of Kazakh and Russian, with your exceptions. We covered similar scenarios in the solution for sales teams.
Why a prototype if you can go straight to production
Because the prototype removes the risks before the contract, not after. Quality is verified on your data, including bilingual dialogues and industry specifics. Employees see the agent in action and stop waiting for the catch. The economics are calculated on measured figures, not on the contractor's promises. A decision about a subscription starting at 12 million tenge a year is easier to make after a week that cost nothing.
Why is the prototype free?
Cold calculation, no charity. A week of configuration costs us less than three months of pre-sales with meetings, presentations and requirement-spec approvals. The prototype quickly answers the main question: is there an effect or not. If there's no effect, both sides find out in a week rather than in a year. If there is, the project moves forward on the numbers, without draining arguments about "whether it will even work at all".
What happens after the prototype
If the numbers are satisfactory, the scenario is rolled out into production, from eight weeks: connecting live systems, access rights, checkpoints, team training, support arrangements. The data stays inside the company's perimeter throughout. The platform subscription starts at 12 million tenge a year and includes the scenarios that follow; in our experience the first scenario pays back the subscription in 6–9 months. What data to prepare for the start of the week we covered in a separate article: there's less of it than people tend to assume.
Frequently asked questions
How much time will the prototype take from our team?
Five to six hours over the week in total: the kickoff call, the data export by IT, two or three short 15-minute clarifications, and the demo. Most of the questions go to the process owner, who is the one explaining what counts as the correct result.
What happens to our data after the prototype?
By default we delete it after the demo, with a formal deletion record. The work happens in an isolated environment, only the configuration team has access, and a confidentiality agreement is signed before the start. For sensitive industries such as healthcare, the data is additionally anonymized.
And if the quality at the demo isn't good enough?
You pay nothing and walk away with useful knowledge: exactly where the scenario gets stuck: in the data, in the framing, or in the exceptions. In roughly one case in five, after the demo we change the scenario and do a second iteration, now understanding what didn't work. How to pick a scenario more likely to take off is a checklist of seven questions.