SaaS ERP

Two years of development, two pairs of hands, 95.71% test coverage, and not a single day of real work at either of the two factories the owner has standing by.

The problem is not the quality of the engineering. The quality here is high, and the audit measured it. The problem is that getting into the system costs more than the owner is willing to pay, getting out of it has never once worked with real people, and the team learns about a failure only when someone writes in Telegram.

The goal is wider than a launch: both of the owner's factories, then productizing the system and selling it as SaaS to outside clients stakeholder. Seen that way, the cost of loading data stops being a one-off obstacle and becomes the unit economics of every new client.

What was examined, and when: the main repository as of 2026-08-12, the Telegram export for 2024-05-13 → 2026-08-10 (5,735 messages), and a web review on 2026-08-13. The tests were run and coverage measured on 2026-08-13 against a separate database. There was no access to GitHub Actions or to the mobile app's repository; where that changes a conclusion, the report says so. One piece of testimony from inside the team was added later. On 2026-08-19 the author presented the report to the BE developer, and on 2026-09-08 asked him for feedback stakeholder. What that conversation changed is recorded in the Decision Log, in K14what the conversation with the BE developer changed.

Every claim in the report carries a provenance mark. This keeps a confidently worded guess from passing itself off as a finding, and the meter above counts these marks rather than eyeballing them. Behind the marks is a working graph, kept since the first hour of the audit: 71 claim nodes with a source reference, each backed by a file with the evidence that holds it up.

Almost half of the claims rest on what was read in the code, the git history and the chat export, and another fifth on web sources. For questions of fact that is a solid base. The weak spot is elsewhere: the audit did not interview the owner of the factories, the main actor in this story. Stakeholder words here have two sources. Most come from the author of the audit, who is close to the project but not a member of the team. The rest, dated 2026-09-08, come from the BE developer, to whom the report was presented on 2026-08-19.

Start Here

This section exists so the rest of the report can be read without prior knowledge of the project. If you already know the material, go straight to Policies & Operations.

What SaaS ERP is

It is an ERP for garment manufacturing: a system that carries an item from order to shipment and calculates the seamstresses' piece-rate pay. Not a web shop, not bookkeeping: it runs the shop floor.

Technically it is a monorepo of four parts observed:

• Rails 8.1 API — 138 models, 86 controllers, 442 migrations. It holds all of the domain logic.
• frontend/ — the first web interface, built on antd. Retired in July 2026; it stays in git as reference material.
• frontend_v2/ — the second web interface, React 19 + an in-house design system. The main line of work since February 2026. observed
• docs/ — a documentation site on Next.js with PRDs, user stories and ADRs. observed

Plus a mobile app on React Native in a separate repository, and that is the one that carries the product's promise.

The product promise

The author of the audit stakeholder put it this way: a worker on the shop floor has a mobile app, walks up to a printed document with a QR code, scans it, and gets the list of operations she has to do today.

This is not decoration. It is what the factory pays for: real-time management instead of after-the-fact bookkeeping.

The cast

• The owner — not from IT, but with the domain expertise of a production technologist: dictates the data model, thinks in 1C concepts, lists the canonical documents of garment manufacturing from memory observed. Has two operating garment factories to start from stakeholder.
• The FE developer — frontend. 2,553 commits (79% of all). observed Built both web interfaces, the mobile app, CI, the documentation, the ADRs, the e2e suite and the agent harness. In practice commits to the backend more than the backend developer does.
• The BE developer — backend in Ruby. 692 commits observed. Owns the Heroku infrastructure stakeholder.
• The author of the audit — does not work on the project: has no commits, does not write in the working channel observed. The author set the direction of the research, proposed hypotheses and corrected conclusions as the work went on.

This distinction matters for how the report reads. Everything marked as stakeholder words was said by the author of the audit, who is close to the project but not inside it. The thesis about onboarding friction, the frame "this is a factory, therefore clockwork reliability" and the phrase "no adult" belong to the author. They are a view from outside: not a position documented in the project, and not the team's assessment of itself.

How to read the marks

Register codes

PL policies · S strategies in force · RC root causes · R risks · D debts · C credits · E easy wins · B bets · K decisions · P pre-mortem · Q open questions. Every mention of a code carries a one-line memo, so you never have to look up what it means.

Timeline

Policies & Operations

This is the decided layer: rules that should govern every later decision of their class when the strategist is not in the room. Every row below is in the state “proposed”: a policy is accepted by the person running the project, not by the audit.

One condition shapes all six. No one in the project holds a mandate: the owner has no technical expertise; the BE developer, by his own admission, does not take on improving the machine or engineering leadership; the FE developer is the best candidate to lead but lacks deep BE expertise, and he is the one who just asked about looking for a job RC2technical leadership vacuum. So no policy here relies on anyone insisting. The ones that must work for certain are built as CI gates: they do not ask permission. The ones that cannot become gates are deliberately weakened to a recommendation. A prescriptive policy that no one will carry out is theater of agreement, not strategy.

Business Context: Less Money Than It Seems

The assumption that the owner's budget is unlimited is not supported by the evidence. There is no direct answer, and it remains an open question Q4how many more months can be funded, but the traces are sufficient.

Payment is planned in advance (“I plan to make the 1,750 c.u. payment by 5 March”), there is a quantity called “earned but not paid out” (the BE developer accidentally overwrote the formula that computes it in the shared Google spreadsheet), and arrears are real enough that clearing them gets its own announcement: “No arrears outstanding” observed. The amounts fluctuate: UAH 85,386 for one month to one developer in August 2025 (≈USD 2,000), 1,750 c.u. in February 2025, 500 c.u. in June 2026. Receipts arrive in pairs roughly monthly, with a gap of almost five months between April and September 2025.

This reading has a stated limitation: the receipts in the chat are an incomplete record, payments could have gone around the channel, and the spreadsheet with the real account is not available to the audit. So the conclusion is inferred, not fact.

But the rough arithmetic deserves attention: ≈USD 2,000 × 2 developers × 27 months gives about USD 100k already spent. That roughly equals the grant the FE developer found in December 2025, whose condition was “to already have at least some launched basic version of the product (ideally with revenue)”. So the external money that could double the project's resources sits behind the same door as the launch.

One cost ahead appears in no spreadsheet: reaching external customers will require marketing. The audit's author estimates it at no less than USD 50k assumed. This is an order-of-magnitude estimate, not a calculation, but it shows the scale: before the product reaches the market, at least another half of what has already been invested must go in.

A startup grant of up to USD 100k requires a launched version of the product, preferably with revenue. The thread lived for a week in December 2025 and died after a meeting was rescheduled. Over the following seven months the word “grant” does not appear in the export once.

Product: A Promise Tested Once

The promise is this: a worker walks up to a printed route sheet, scans the QR code and gets her list of operations for the day stakeholder.

The implementation matches. QR codes appear on the two documents that belong to the batch, the route sheet and the cutting card, each with a { id, type } payload on a 100 × 50 mm label together with the code, product, color, size and planned quantity observed. The specification has no QR and should not: it is a product template, not a job for a specific batch.

So intent and code agree here. What diverges is what happens after the scan.

The loop was tested once, in August 2025, on real workers. It broke in five independent places.

The remaining three: after a label is generated, the print sequence breaks; during scanning, part of the previous menu stays on screen; the QR carries a binding to a location, so a route sheet created in one department would not open in a shift of that same department. Server-side validation of the equipment-to-department binding arrived on 2026-07-23, eleven months after the owner wrote about it.

One more condition, which the owner named back in March 2025: the loop requires two scans (the equipment and the document) plus an open shift in the right department. “Scanning the same thing every time isn't practical.”

In May 2025 the developer designed a “fallback function so the admin could manually enter data about completed processes”. In June 2026 it got full CRUD for shift processes on the web and seven e2e specs. The mobile half of the loop, the half that carries the promise, has not been tested on people since August 2025.

Organization: No Adult in the Room

The phrase belongs to the author of the audit stakeholder, not to the factory owner or to anyone on the team. It is an outside assessment: someone looking at the project from outside sees no one in it who holds the engineering direction. That person is absent from the table below, which lists only the three people who divide the roles between them.

The roles, set against what the project needs:

Three things follow from this, and all three are structural, not personal.

The ceiling on prescription is low. No one both holds a mandate and is willing to apply consequences. So a prescriptive policy that relies on human persistence fails the enforceability test by definition. That is why PL2main protected by green rspec takes the form of gates that don't ask permission.

The infrastructure and the will to improve it are in different hands. Heroku belongs to the BE developer; by his own admission, continuous improvement of the machine is not his area. Any policy that requires changes to deployment or CI must either move to the FE developer together with the access, or not be carried out.

The knowledge gap runs one way and is total. The BE developer does not see the entire engineering superstructure: how CI is set up, the ADRs, the PRDs, the suite of 303 e2e tests, the 426-line harness stakeholder. Nothing is hidden in the other direction: the FE developer has committed to the backend 1,089 times and does so with his own agent. So almost all of the project's engineering assets were created by one person and are known only to him, and he is the same person who has just asked about looking for a job.

Engineering: High Quality With No Gates at All

The most important thing to say about this code: it is good. This is not a project with a low culture that needs rescuing. It is a project with a high culture whose results are connected to nothing.

• 95.71%backend coverage from rspec, 6,114 examples
• 79.05%backend coverage from e2e, 303 tests
• 80.72%frontend coverage from e2e
• 0of these had ever been measured before this audit

Coverage was measured with instrumentation the project never had: simplecov is not in the Gemfile, no coverage artifact is generated, Codecov is not connected. So no one on the team has seen any of these figures; they were all measured here for the first time. The audit author's starting thesis, that coverage is not recorded, is correct.

The two suites were measured separately. Rspec: 6,114 examples, 95.71% of lines and 82.12% of branches. E2e, measured in a single run on 2026-08-14 (303 passed): backend 79.05% of lines (7,193 / 9,099) and 45.56% of branches, frontend 80.72% of lines (21,634 / 26,800) observed.

They have to be read together. Browser tests covering 79% of backend lines is a lot: 303 tests drive real domain scenarios, not smoke checks. The gap in branches (45.56% against 82.12%) shows a healthy division of labor: e2e takes the happy paths, the unit specs take the error branches. So the backend is covered from two independent sides.

One clarification changes where the problem lives. E2e does run in CI: test.yml has an E2E Tests job that brings up the backend via docker compose, waits for the API to be ready, sets up the database and runs Playwright observed. So the backend is checked in CI, but from the browser, on happy paths, with 45.56% branch coverage.

What does not run in CI is rspec: the suite of 6,114 examples that holds 82.12% of branches never runs at all. The problem is not that the tests aren't connected. The suite that is worst at catching faulty branches is connected, and the one that catches them best is silent.

Getting to this figure produced a finding of its own. Two attempts failed, and each exposed a separate defect:

1. Bootsnap is incompatible with coverage instrumentation: all 308 files fail at load.
2. rspec does not start in the project's own test stack: the api service holds the same database that DatabaseCleaner cleans in before(:suite), and they block each other.

The first measurement after the workaround gave 47.94%, and it was false: not a single example ran, and the number reflected code executed while Rails was loading. The branch metric gave it away: 0.36%.

Observability

There is none. Checked Gemfile, package.json and frontend_v2/package.json: no Sentry, Bugsnag, Rollbar, Honeybadger, AppSignal, Datadog or New Relic observed, which the client confirmed stakeholder.

What exists: /up (the app came up); logs to stdout, tagged with request_id but not aggregated (Logplex keeps a buffer of ~1,500 lines for up to a week, so without a drain they disappear web); and a script that uploads source maps to S3 with no error receiver: groundwork for decoding stack traces that are sent nowhere.

The Mechanism That Stops a Shop Floor

This is the engineering section's most important finding, and it becomes visible only once you read the code as a factory's system. ProcessItem validates on creation:

def reserved_quantity
operation.process_items.where(sheetable_id:).where.not(id:).sum do |p_i|
  p_i.finished? ? p_i.actual_quantity || 0 : p_i.planned_quantity || 0
end
end

def allowed_quantity
@allowed_quantity ||= (sheetable.planned_quantity || 0) - (sheetable.defected_quantity || 0) - reserved_quantity
end

In plain terms: an unfinished process holds a reservation for its entire planned quantity. There are two ways to release it: finish the process or delete it. Deletion is gated by the processes:delete permission, so it is available to an administrator, not to a seamstress. There is no timeout and no automatic release.

There is no idempotency on creation either. A double scan (what a person does when the first scan produces no visible reaction, and what happened in August 2025) creates a second process and takes the reservation a second time.

Both scenarios have already happened: “A worker started 2 processes for execution at the same time” (2025-05-23) and, in July 2025, finished work that could not be closed: “it showed all five bundles of 50 and wouldn't let us close the work”.

A quantity reservation with no expiry stops the next person on the operation. Observability is zero. For a factory, time to detection equals downtime, and the detection mechanism today is the owner writing in Telegram.

Strategy Already in Force

Before proposing a strategy, the report documents the one that already governs decisions, whether it is written down or not. Here there is one, and it is consistent.

The rows assess one another. S4discipline is set by the frontend — the project's healthiest strategy — exists because one person took it on; S5backend context in private memory is its mirror image, an absence on the other side of the same codebase. And S2a known test failure is the norm is what makes S1quality is voluntary useless: an excellent test suite that nothing runs protects no one.

Root Causes

Getting into the system costs more than getting out of it; failure is silent and dangerous at the same time; the owner's complaint has nowhere to go; a known defect costs nothing to ignore; the promise is neither tested nor withdrawn; no one is responsible for the engineering machine and the sequencing of work. Rewriting code cures none of the six; all six are cured by decisions about where the signal goes and who reads it.

Risk Register

Ranked by harm × likelihood × noticeability × cost of recovery. Low noticeability raises the priority: a silent failure is more dangerous than a loud one of the same size.

This pair of coordinates gets its own picture, because it explains the order below. Horizontal: how likely the risk is. Vertical: whether you will notice it without someone coming to tell you. The dangerous quadrant is the bottom right, not the top: what will happen and stay silent.

Debt Ledger

A risk may happen; a debt is already being paid, every cycle.

Credit Ledger

Credits that pay back in every later cycle. A credit counts as confirmed only once it has been reused, so projected entries are marked separately.

Easy Wins

Small, fast, safe things that feed the machine. They do not compete with the bets for attention and take no slot in the quarterly selection; they should be run as a single batch.

Ten entries, ≈4 agent-days in total. Each closes a debt named in the report, and none needs a decision from the owner. Number E1 stays empty: that win was withdrawn, and numbers are not reused, so older references do not shift.

Strategic Bets

The bets are assessed against the accepted answer to the open question Q4how many months can be funded: we assume the runway is limited and short. This position is inferred from the available traces, not from a statement; if the owner answers otherwise, the order must be recalculated.

Selection: three bets for the quarter

We do B1make failure visible and safe, B2one product, a parallel run and B4appoint an owner of the engineering machine.

Why the rest wait:

B3agentic onboarding as a mechanism waits, and this is the main change of order relative to the original hypothesis. The audit's author set onboarding itself as the direction, and the evidence supports it more strongly than expected: the owner measured 30 minutes per specification personally and asked for a fix unprompted. But cheap entry into a system that can silently block work and cannot report it only gets you faster to an unprotected point of failure. Safety first, then the cost of entry. Minimal onboarding does not wait, though: it goes inside B2one product, a parallel run as the loading of one product. It becomes a mechanism after the loop has proven that it works, and is then scaled to the product range rather than built blind.

B7one-off QA consultation on the e2e suite needs a word on why it is one-off rather than a hire. There is no tester on the project: the owner is not one, and the developers even less so stakeholder. Under other conditions the recommendation would be obvious: bring on QA for at least a few hours a week. Here it should wait for now, and not only because of money:

• the budget is already limited R4the money runs out before launch;
• automated test coverage is high on both sides (C195.71% from rspec, C879% backend and 81% frontend from e2e), so the machine already catches the cheapest class of defects;
• and most important, there is no infrastructure for QA to work in. Without an issue tracker a tester has nowhere to put findings and nowhere to see the state of a feature or a bug D6Telegram as the task board. Hiring a tester into a project without a tracker means starting a fourth stream of messages in the same chat.

So a one-off consultation is the useful form: an experienced QA looks at the existing 303 tests and says two things that are invisible from the inside — whether the methodology is right and which critical paths are missing. e2e suites written by developers regularly contain fundamental gaps, obvious to any tester and invisible to their authors. This fits the budget, needs no tracker and gives the most per hour spent. After PL1chat history converted into the Issue Tracker the question of a permanent QA should be reopened: by then the infrastructure will exist.

B5the mobile app: audit or withdraw the promise waits for the result of B2a parallel run: the pilot will show whether the loop is alive, and learning that on the shop floor is cheaper than learning it from the code.

B6the v1→v2 migration is complete comes off the list: the team did it on its own and did it right. The migration had a named reason, quality gates at every phase and an explicit production cutover.

Easy wins do not take part in this selection; they run in parallel as a batch.

The broadest objection to the main bet

There is a strong counterargument against B1make failure visible and safe, and it deserves naming: this is engineering work again, and the project's illness is that it substitutes engineering for launch. A week on observability and timeouts looks just like those eighteen months when a refactoring appeared in place of auto-search. The risk that B1make failure visible and safe grows and swallows the quarter is real.

Why the bet still stays first: it is bounded by a date, not by scope. It exists only as a prerequisite for B2a parallel run, and the pilot is scheduled to start alongside it, not after it finishes. If the pilot has not started a week later, the bet has failed, however much code was written. That is its falsifier.

The second objection is stronger. Perhaps the parallel books remove risk R1the line stops and nobody finds out on their own, and then B1make failure visible and safe is not needed before the pilot. That is partly true: they do make failure non-fatal. But they do not make it visible. Without error tracking the team learns about a defect from the owner the next day, and on a two-week pilot the fix cycle will eat half the window.

Investment Priorities

The sequence matters more than the contents: make failure safe → prove the loop on people → make entry cheap → scale. Each step makes the next one possible, and none makes sense ahead of the one before it.

Evolution Strategy

Two capabilities the strategy rests on belong on the maturity axis, because the "build or wait" choice depends on how they drift.

Data extraction from documents: from custom to product and on to commodity, fast web. The market already offers ready-made solutions (OneSchema, Unstract, LlamaIndex's Spreadsheet Agent). The conclusion for B3agentic onboarding: do not build a parser. The only part that stays custom is "map it onto the SaaS ERP model", and it will stay custom, because the schema here is the product's own.

Observability: commodity for a long time. Building anything of our own here would be the classic "Build on a commodity" mistake, so E4Sentry in the backend and frontends is a purchase, not development.

Time standards for sewing operations (GSD and similar): product, licensed web. This project does not need them: the standards are already in the owner's head, and for one product they are already in the system. This is a rare case where an internal asset is worth more than the market one.

The market: the niche is taken, and more firmly than it seemed

Since the goal is to sell to external clients, here is the market this product is entering. Below is a web survey from 2026-08-14 web. It is not commissioned market research: the figures come from public sources and the vendors' own sites, so some of them are marketing rather than a measured result.

Global players built for the same job

The closest competitor does what SaaS ERP promises. Scan ERP targets small and mid-sized CMT factories (20–500 operators) and is built around batches, operations, piece-rate pay and QR scanning. The price is public and low: $5 per machine per month or $0.001 per tracked unit, whichever is cheaper, with no per-user fee and unlimited operators; implementation takes two weeks web. For a 50-machine factory that is about $250 a month.

Behind it stands a wider field: WFX Cloud ERP (mid-market, price on request only), Kladana (from $5 a month, with a free plan), Datatex, MRPeasy, the open-source ERPNext, and at the top Infor CloudSuite Fashion and NetSuite configured for cut-make-trim. For comparison, implementing SAP S/4HANA or Oracle in this industry costs from $50k and takes 6–12 months web.

The market is growing: apparel design and manufacturing software is valued at $2.95 billion in 2026 with a CAGR of about 11%, and the apparel management segment at $2.25 billion in 2025, forecast to reach $4.36 billion by 2034 web.

The Ukrainian context: who already holds this niche

A local industry solution exists, it is mature, and the niche is not empty. Shveika 8 covers the full cycle from tech card to sale, with a technologist's workstation, three modes of pricing operations, cutting orders, hand-off to the shop floor and distribution among seamstresses: the domain core of SaaS ERP. The vendor claims more than 550 Ukrainian enterprises among its users web.

Two clarifications should have come earlier, because they remove two imagined advantages of SaaS ERP.

First: shop-floor scanning is already there. The product page says so directly: “barcoding of technological operations is in the ready-made solution and is most often used in production facilities where the completion of an operation is recorded at the moment the operation is performed” web. This is the same loop SaaS ERP promises with its mobile app: the worker records an operation as it is performed. So the mobile loop R3the scan loop may still not work is not a differentiator. It is an expected feature, shipped by the competitor and unconfirmed in SaaS ERP.

Second: their onboarding is productized and paid. It is called “Prymirka” (“fitting”) and looks like this: 2 months, 10 hours of training across 6–7 remote recorded sessions, UAH 11,000, with an empty database on the client's server, the accounting scheme built together with the client, and an end-to-end example on the client's own data. The fee is credited toward the purchase: in full from 10 workstations, half for 3 to 9 web.

The product itself costs UAH 13,500, but Shveika 8 is sold only together with “BAS Small Business” at UAH 15,600, a total of UAH 29,100 per workstation web.

What BAS is and why the ban is weaker than one would like

BAS is a set of configurations on the BAF (Business Automation Framework) platform of the Polish company NetHelp, which appeared in 2018 and is described as “an approximation of the 1C platform for the Ukrainian market”. Systems that ran on 1C:Enterprise moved en masse to BAF after 2021 and took the BAS name web. BAS was built as an exit ramp from 1C, and that is why moving there is cheap: the same paradigm, the same integrators, the same accountant's habits, ready-made tools for transferring reference data and balances.

Then the exit ramp fell under the ban too. The chronology: NSDC sanctions against BAS products back in 2020; April 2023, sanctions against 1C for ten years, until 2033; 18 July 2025, bill No. 13505 banning hostile software products, with fines of up to 2% of annual turnover; on 9 January 2026 the State Special Communications Service published a list of banned software, and by the end of the month it held about 27 BAF-based products, including BAS ERP and BAS Accounting CORP. The grounds: “technological kinship” with 1C web.

The boundary has to be drawn precisely here, because whether there is a window at all depends on it. The ban applies to the state sector and critical infrastructure, not to every private enterprise. A private sewing factory does not fall under it. Bill No. 13505, which would extend fines more widely, is registered but not adopted web. So today no legal compulsion pushes a factory off Shveika 8; there is only a reputational and regulatory backdrop.

One more twist works against us. Migration from 1C goes smoothly on standard configurations and breaks on customized and industry-specific ones web. Shveika 8 is one of those. A factory on it is held there not only by habit but by the cost of leaving, and this lock keeps it from switching anywhere at all, SaaS ERP included. Stickiness works for whoever is already inside.

The state of the industry

It is shrinking, but reorienting. Employment in light industry fell from 133 thousand in 2019 to 91 thousand in 2025; since 2022, 128 enterprises have relocated to Zakarpattia; manufacturers complain of rising prices for electricity, fuel and raw materials. At the same time the industry association describes its strategy as “becoming Europe's atelier”: a move into contract manufacturing for European brands web.

Shveika 8 claims more than 550 Ukrainian enterprises, ships barcoding of technological operations in the ready-made solution, and sells a productized paid onboarding, “Prymirka” (2 months, UAH 11,000, credited toward the purchase). The mobile loop on the shop floor is not a SaaS ERP differentiator but an expected feature, shipped by the competitor and unconfirmed here.

The list of banned software from 9 January 2026 applies to the state sector and critical infrastructure; bill No. 13505 with fines has not been adopted. Meanwhile BAF was designed as an approximation of 1C, so moving 1C → BAS is cheaper than moving 1C → SaaS ERP, and most of the migration wave flows there.

What follows for the strategy

The niche is held by implementations, not by a platform. What keeps the competitor in it is 550 enterprises, a dealer network and shipped functionality, not the technology underneath. So a change in that technology's status frees nothing up on its own: the ban does not extend to a private factory, and even if it did, the cheapest exit for that factory would still be another product on BAF, not SaaS ERP.

The market sets the price, and it is low. $5 per machine per month at Scan ERP and UAH 29,100 one-off per workstation for Shveika 8 mean that the unit economics of SaaS ERP have to work at a few hundred dollars per factory per month.

Now the unexpected part, and the most useful in the whole section. A competitor that has worked in this niche for years spends two months on onboarding and charges for it. So the market does not treat long onboarding as a flaw: it treats it as a service. This directly corrects RC5entry costs more than exit. The problem with SaaS ERP is not that onboarding is long; by industry standards it is normal. The problem is that it has no defined end, no price and no fitness check. “Prymirka” has an empty database, six sessions, an end-to-end example on the client's data and an end date. SaaS ERP has none of these four.

This changes the substance of B3agentic onboarding as a repeatable mechanism. The bet stays, but its goal changes: not “reduce onboarding to zero” but make it bounded, measurable and sellable. The agent cuts part of the work; it does not abolish the process. Even a shortened process needs an end-to-end example on the client's data, because that example is the fitness check and the source of feedback.

So what do we differ on? Honestly, not a single differentiator has been verified. The candidates left after this section are web delivery with no server installation, against a desktop client on someone else's platform, and no per-workstation fee. Both are hypotheses about value to a buyer nobody has asked.

Where agentic onboarding should aim

Until now B3agentic onboarding as a repeatable mechanism was described as parsing what a factory keeps on hand: Excel, notebooks, PDF tech cards. This section gives grounds to change the target source, and the change alters the nature of the bet.

The realistic external client of SaaS ERP is not a factory that has automated nothing. It is a factory that already runs on Shveika 8: there are 550 of them in the niche, they already have structured data, and they already have a reason to look around. So agentic onboarding should be designed around a “migration from Shveika 8” arc, not a “parsing paper” arc.

The difference is not cosmetic. It decides whether this work is one-off or repeatable:

This is where the agent gives disproportionate value. The 1C/BAF platform's data structures are notoriously opaque: physical tables have technical names like SC327 and SP330, service fields are mixed with business ones, and a document consists of a header and several tabular sections web. For a person, writing such an importer is slow and tedious; for an agent it is the kind of task it does well: explore the schema, build the mapping, show the result on an end-to-end example. And unlike parsing PDFs, this mapping is written once for the whole niche.

A side effect deserves its own mention: this arc gives SaaS ERP the fitness check it lacks. A migrated database is someone else's data, someone else's operation names, someone else's rates. It shows at once where the SaaS ERP model does not match how the industry keeps its books.

Where this leads: two factories, productization, external clients

The owner's end goal is broader than the launch: to bring both of their factories onto the system, productize it and sell it as SaaS to real clients stakeholder. This changes the weight of one of the bets, so it should be stated directly.

What already exists for this. Multi-tenancy is working, not just declared: 45 of 114 models carry multi_tenant, the tenant is set from current_user.company on every request in base_controller, and creating a company triggers after_create hooks that seed default permissions, units of measure and the system material type “Fabrics” observed. So data isolation and basic provisioning of a new client are already written, which is rare for a project that has not yet launched.

What is missing. Self-signup: company creation is gated behind the superuser_check check observed. Billing, plans and everything else that makes SaaS a business are absent from the code entirely.

The main consequence, and it changes the priority. In the "one own factory" model, the cost of populating data is a one-off obstacle on the way to launch. In the SaaS model it becomes the unit economics of every client: 30 minutes per specification multiplies by the product range of every new factory, and either the client pays for it with their time or the owner with theirs. What now looks like an internal tool, B3agentic onboarding, is in this frame part of the product, and the part that determines how much it costs to connect the next client.

So the sequence from the priorities section does not change; it lengthens: safe failure → proven loop on one product → cheap entry → a second factory as the first test of repeatability → an external client. The second factory matters here not for its volume but because it is the first case where onboarding has to be done a second time, and that is where it will show whether onboarding is a mechanism or manual work done once on enthusiasm.

Decision Log

Pre-mortem

A year later, the plan has not worked. Here is how, from most likely down.

Watchlist

What We Don't Know

Ordered by impact on decisions: the first question moves the most.

Q6in what form and volume the owner keeps the data — in what form and in what volume the owner keeps their data. This determines whether B3agentic onboarding is two weeks of work or a product module. The numbers it needs: how many products are in the active range at each factory, how many operations per product, how many workers and machines. And the format: are the tech cards Excel, 1C, PDF or paper? The only sample the audit had turned out to be an export from the system itself stakeholder, so the audit has no sample of the owner's source data at all. In 27 months not a single Excel file was sent to the chat, so the assumption of "books in Excel" is still unverified assumed, and of everything unverified it is the most expensive.

Q8whether the scan loop is fixed and whether it was tested on people — whether the scan loop has been fixed and whether it has been run with people since August 2025. It moves R3the loop may still not work from unknown to low or high. The audit cannot answer: the mobile app repository is not on the machine. This is a named boundary of this report, not an omission. The mobile app has been under rewrite since September 2026 stakeholder, so the answer will concern the new app, and the loop should be run with people before the rewrite is declared finished.

Q4how many months the owner is willing to fund — how many months the owner is willing to fund, and what happens next. This answer alone decides whether the recommendation reads as "sequentially over two quarters" or as "one workshop, one product, six weeks, and no more."

Q7whether the startup grant track is alive — whether the startup grant track is alive. If it is, the launch gains a date and an amount from outside, and an external falsifier with someone else's calendar is more reliable than the internal discipline the project lacks.

Where to ask. Q6, Q4 and Q7 go directly to the owner, in the same Telegram group that remains the project's only live channel. Q8 goes to the FE developer, together with access to the Mobile/ repository.