For investors and executives
1C modifications from a task description — without a programmer in the queue
The user describes the task in words. The system clarifies requirements, writes code, builds the file with 1C tooling on the client's base and delivers a ready result.
Status: reports and processors proven in internal tests on live exchange orders (v0.1.0-mvp); since Oct 11–14 the report is actually formed on a demo base before delivery — an execution check; the readiness threshold of 18 out of 20 is not met, we charge customers no money · as of October 15, 2026
Problem
Why small 1C modifications cost disproportionately much
- 01
The programmer queue
A “stock by warehouses” report waits its week alongside big tasks.
- 02
Specification costs more than code
Half the time goes into finding out what is actually needed — and into rework after the first version.
- 03
Entry threshold
Small business has no 1C developer at all, and contractors do not take every small task.
- 04
Generic AI does not help
Chatbot code knows nothing about the specific configuration and is never compiler-checked — a human still finishes it.
- 05
Configuration knowledge does not scale
Every base is modified differently; without its structure, advice stays generic.
- 06
Data cannot leave
Exporting the configuration and business logic to an external service is unacceptable for many.
What the product does
Full cycle — from a Russian sentence to a file that opens in 1C
Description
The user states the task in their own words
Clarification
The system asks questions and fixes the requirements
Generation
Code is written in the 1C built-in language
Compilation
Built on the client's real base
Result
A ready report, data processor or print form
A compile error is never shown to the user: the service retries the fix within the agreed limit.
The result is a file, not text: an external report (.erf) or an external data processor (.epf), including BSP print forms.
In development — honestly
Extensions and the AI-developer
47 of the 89 profile tasks in the corpus are extensions — that is the sample's structure, not a market share. No extension has been delivered to clients yet.
Extensions (.cfe)
The assembler takes objects, modules, layout-free forms, custom attributes, tabular sections and enums from the standard configuration; verification runs on our demo base (UNF). Assembler v2 on live 1C (Oct 7): scenarios A, B, C, D1, D2 passed; D3 (form layout copy) did not.
The AI-developer
Not one prompt but a loop: reads the docs and code of the exported standard UNF 3.0, searches modules, writes files, builds and verifies the extension. First full run on Oct 6: 31 steps, 852k tokens, ₽132.57 per file — one attempt, not the price of a client task. Tool issuance was then cut 3–4×. Currently an owner-only tool.
Decision of Oct 1: standard configurations only; verification on our demo bases; nothing is uploaded to the client base — the client installs the .cfe themselves. Whether an extension applies depends on the client's platform, compatibility mode and security profile.
The difference
Three things a generic AI assistant does not have
Verified by the 1C build
The artifact is built by a real Designer against the client's real configuration. Not “probably working” code.
Knows the specific configuration
The system works with the object set of this exact base — including modifications and installed extensions no standard configuration has.
The configuration never leaves the perimeter
The build runs on the client's machine. Only the structure goes out — object and attribute names, without module texts.
Independent from any single AI vendor
Adapters for ten providers are connected — two in production
The rest are groundwork. The user chooses a mode, not a vendor: auto, cloud or local only.
Foreign cloud
Adapters for Claude, OpenAI, DeepSeek, Kimi, Zhipu, Qwen. In production: Qwen (primary) and DeepSeek — the AI-developer and failover are tuned to them.
Russian
YandexGPT and GigaChat are connected — for when data must not leave the country. Not used in the main flow right now.
Local
Ollama and LM Studio are connected, but on our hardware generation came out at ~1 token/s — local generation rejected for now.
Failover in battle
The backup chain fired for the first time on Aug 31: Qwen timed out, DeepSeek picked up, the task survived. Failover is enabled on all three pipeline steps.
Per-answer cost tracking
Provider, model and price recorded as fact — unit economics visible per model, not only at wallet debit.
Task presets (skills)
What turns a chat into a tool
Disciplinary presets: role, rules, context budget, plan-level access.
Ready-made presets
A 1C consultant, a requirements analyst and reviewer, Vanessa Automation test-scenario generators.
Custom presets
Users create their own through a step-by-step wizard; the count depends on the plan.
Paid access
A preset can open on a higher plan or be bought as a one-off temporary access.
A preset knows the contents of an entire configuration without storing it in the prompt — for the standard “Managing our firm” (3.0.14.159) that is an index of 8,750 objects. Contents load per question against a budget; cost depends on the task, the model and the number of iterations.
Monetization
Built in, not postponed
The mechanics are implemented in code; prices are placeholders, and there is no revenue yet.
| Mechanism | How it works |
|---|---|
| Plans | Monthly token quota, rate limit, number of custom presets, level-based access |
| Wallet & overdraft | Quota exhausted — charges go to the balance if the plan allows it |
| One-off purchases | Temporary access to a single preset for a fixed amount |
| Guest mode | Trial access with a hard limit and no overdraft |
| Cost tracking | Rates per provider and model — margin computed as fact |
| Payments | A payment gateway is connected; without keys a stub handles testing |
Validation
Validated on other people's tasks, not our own examples
A corpus of verbatim task texts from three 1C freelance exchanges, and internal pipeline runs. Corpus markup is ours.
orders from 1CLancer, YellowHub and SpecPortal as of Oct 15, verbatim customer texts; the breakdown was counted at 281: 89 in the pipeline's profile; no profile orders among the 38 added on Oct 13–15
sample profile across the 281 marked-up orders: extensions, processors, reports, print forms — corpus structure, not a market share
orders on Aug 25 reached a file on a test Accounting base; on Aug 31 three more reached approval — the first real spreadsheet layout of a print form was compiled
The bottleneck is not code quality
Almost all failures in the internal run were “provider unavailable”, not invalid code. Hence the backup provider on all steps.
Defects were closed the same day
That is how pre-compilation query validation and the refusal to deliver stub reports appeared.
Configuration map from SpecPortal
339 cards: Trade 11 — 22.7%, Accounting 3.0 — 20.4%, UNF 3.0 — 19.5%. No public measurement of the standard-base share exists.
Readiness — honestly
The repeat measurement of Oct 14 on exchange orders
orders built in 1C (two Accounting 3.0 reports, one Trade 11 report, two UNF 3.0 processors); 1 of the 4 built without a single failed attempt
human-rated “yes” verdicts for this run so far; the Oct 9 run's three reports were rated “no” — the readiness threshold of 18 “yes” out of 20 is not met
tokens per order (538,308 across five); order 79375 failed after five build attempts — on the execution-check error
The execution check works — and catches what the build misses
Oct 10 review: three of five “compiled” .erf files were wrong — a build does not execute the query. Since Oct 11–14 reports are actually formed on a demo base: a query-schema error was caught on Oct 11, reports were formed on buh-demo on Oct 14. The 1C error text is condensed and sent to the model for regeneration; a provider outage does not burn a generation attempt.
Limits of the execution check
Processors are not covered yet; on the Trade 11 demo base it failed to start on Oct 14 — the cause is unknown. Extensions are not covered either.
Code checked against 1C standards
214 of 322 v8std standards read and reconciled with the prompts (Oct 12); a custom query parser in place since Oct 11. A DCS “ДатаОтчета” parameter was added (Oct 14) against debt-age truncation — no successful rerun after it yet.
We charge customers no money until the pipeline is ready
The owner's decision of Oct 9. Hence a pilot with our specialist in the loop, not self-service. Promo codes for a trial task (account, admin panel, a service runner with demo bases) were implemented on Oct 7–9 but are not deployed yet.
What already exists
A working system — plus two new directions in development
Backend
Streaming chat, provider routing, presets, billing, the task pipeline
Account
Tasks, files & source code, materials, custom presets, balance and operation history
Admin panel
Users, plans, providers and rates, presets, billing oversight; the AI-developer section
The 1C agent (runner)
A Windows service: base and extension structure export, build, check, result delivery
ConfigExplorer
A desktop tool: browsing exports and building files manually
Standard library
Trade 11, Accounting 3.0, UNF 3.0, Payroll 3.1 — start without exporting your base; ERP is groundwork only
Telegram bot (owner-only)
Chat with the analyst and programmer on standard UNF; voice and images in code, deployment unconfirmed
AI-developer (in development)
A tool loop on Qwen and DeepSeek with step confirmation in the admin panel; had a live run, none at clients
Brand “EdinyEs” and the @edinyes channel
The “UNF without guesswork” channel: 5 posts from the October plan published, the bot posts only after owner approval; no subscriber or reach metrics yet
One-script delivery
WAR, site and admin build plus drop into the Publicator incoming folder with a single deliver.bat; the script uploads nothing to the server — the owner does
Risks and the near-term plan — what is honestly not closed
- Extensions (.cfe) and the AI-developer are in development, untested at clients. Assembler v2 passed live 1C partially; no end-to-end task through backend and frontend yet.
- Safe mode: whether an extension applies depends on the client's platform, compatibility mode and security profile. Posting modifications via extension are promised only after environment-specific verification.
- The share of “correct” results is unproven: the Oct 14 measurement on five exchange orders — 4 of 5 built, human-rated “yes” 0 of 5, the readiness threshold of 18 out of 20 not met; order 79375 exhausted five attempts, and the execution check does not cover processors and Trade 11. The build success rate is measured only on samples; no frozen-set measurement exists.
- The support scope is deliberately narrowed: only supported standard configurations; ERP and UNF 1.6 are out of scope; modified bases need a separate compatibility assessment. No public measurement of the standard share exists.
- The business model is not confirmed by numbers: no revenue yet, plans are placeholders, unit economics unmeasured, the agent's task cost (₽132.57 for the first full run) is not fitted into a plan.
- Next steps: bring the human “yes” share to the 18-of-20 threshold → extensions to an end-to-end task → client pilot → plans and sales.
Summary
In short
Mass demand for small 1C modifications among companies without their own developer
A ready file for the specific base, verified by the build — not chatbot text
For reports and processors, data stays with the client; extensions are verified on our demo base
Reports and processors: the Oct 14 measurement — 4 of 5 built, reports actually formed on a demo base; the 18-of-20 threshold not met. Extensions and the AI-developer — in development
Plans, quotas, overdraft and per-provider costs already in the system
Bring the human “yes” share to the 18-of-20 threshold and go into a client pilot