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 on live exchange orders (v0.1.0-mvp), the report is formed on a demo base before delivery; extensions and the AI-developer — in development, extensions already delivered to customers on real requests · as of October 22, 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
48 of the 95 profile tasks in the corpus are extensions — more than any other category; the “reports first” priority is not confirmed by this set. Extensions are already delivered to customers on real requests.
Extensions (.cfe)
The assembler takes objects, modules, layout-free forms, custom attributes, tabular sections and enums from the standard configuration — and since Oct 21, custom catalogs and constants; no registers, scheduled jobs or HTTP services yet. v2 on live 1C (Oct 7): the standard form layout copy fails — form fields are placed in code. v3 (Oct 22, UNF demo): custom catalogs and constants loaded, applied and deleted; working with their data and registering .epf in BSP are unverified.
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 on the demo base — extensions and, since Oct 20, external processors (.epf, registered in BSP since Oct 21). First full run on Oct 6: 31 steps, 852k tokens, ₽132.57. Task price on Oct 20: ~₽159 for 32 steps while the agent guessed the form format, and ~₽7.7 for 3 steps once it was documented — two cases, not a measurement. 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.168) that is an index of 8,779 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 22, verbatim customer texts; 95 in the pipeline's profile (our markup)
sample profile: extensions, processors, reports, print forms — corpus structure, not a market share; demand leans to modifications
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
exchange orders built in 1C on our demo bases — the measurement series since Oct 9 (Accounting 3.0 and Trade 11 reports, UNF 3.0 processors)
human-rated “yes” verdicts in the same series — the readiness threshold of 18 “yes” out of 20 is not met
tokens per order (538,308 across the five orders of Oct 14); one order 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.5, Accounting 3.0, UNF 3.0, Payroll 3.1, Retail 3.0 (on the UNF tree) — 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: extensions and external processors (.epf, BSP-registered), built on the demo base; step confirmation in the admin panel; currently an owner-only tool
Brand “EdinyEs” and the @edinyes channel
The “UNF without guesswork” channel: first post Sep 30, ten posts between Oct 1–22; 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) are already delivered to customers on real requests, but remain in development: the success rate is unmeasured, and there is no end-to-end task through backend and frontend. v3 (Oct 22): custom catalogs and constants load, apply and delete; working with their data and registering .epf in BSP are unverified. Custom objects rebuild standard tables (~85 objects on the UNF demo, 15–23 s) — install like a configuration update, in a maintenance window; unmeasured on a large base.
- 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: in the measurement series since Oct 9, 6 of 8 orders built, human “yes” verdicts — 0 against the readiness threshold of 18 out of 20; 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: in the series since Oct 9 — 6 of 8 built, reports actually formed on a demo base; the 18-of-20 threshold not met. Extensions are delivered to customers on real requests, success rate unmeasured; 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