Two developers spent two years building an ERP for sewing factories, funded from the owner's pocket, with two working factories ready to use it. The code is mostly great. The engineering process around it barely existed, and all of that is fixable. What is not fixable by the team is the owner's unwillingness to commit to a real production run.
Two developers spent two years building an ERP for sewing factories. Funded from an owner's pocket, with two working factories ready to use it. He is hoping to scale it into a nationwide or even global SaaS solution. The code is mostly great and does the job. The engineering process around it barely existed: no issue tracker, zero observability, no clear engineering leadership.
But all that can be fixed. What is not fixable, and what can lead to failure, is the owner's unwillingness to commit to a real production run.
Cold Opening
This is the second published example of the Engineering Strategy Framework. The previous one was the open source e-commerce framework Solidus: the essay and the full audit. This one is a real world struggling product I audited, so the product and the people are anonymised.
The product is a Ukrainian ERP for garment manufacturers built with Rails and React, and its promise is what the industry expects: a worker walks up to a printed specification on the shop floor, scans its QR code with a phone, and gets the list of operations to do today. Piece-rate pay is counted as the work is done, and the owner sees the factory floor in real time instead of reconciling it at the end of the month. The real world implementation of Kaizen. I like Kaizen, so that is why I decided to help.
The team: two inexpensive contract engineers (one full time frontend developer, one part time backend developer), and the owner, who probably has no clear understanding of how to administrate building a SaaS product but knows the garment production industry very well. An ambitious combo that represents a real world bootstrapped startup: they still don't know what they are doing, but at least it is cheap and can be funded from their own pocket.
I had the git repo and its history, and the Telegram chat history, because they have no issue tracker… 5,735 messages over 27 months. The fact they managed to build and organise this far without using Kanban or similar is truly miraculous!
Two years of development, and not a single working day on either of the owner's two factories.
The Code is Not the Problem
Obviously, the first thing I checked was the code.
Despite never being measured before and never running in CI, the backend had 95% line test coverage (rspec) across 6,114 examples. The frontend SPA had end-to-end browser tests: 303 of them, covering 80% of the frontend and 79% of the backend through the API, and it had a working CI observed. The SPA also had written ADRs, PRDs, CLAUDE.md and other traces of modern Harness Engineering. The backend didn't have all that, but introducing it and fixing such problems are easy wins, not massive code migrations.
Neither is the Process (Although it is Messy)
My second guess was everything around the code. It was truly messy.
- No tracker. The working chat is the backlog. Is this feature ready? Is it tested? What is missing? Scroll through chat messages at best; at worst, try to remember what was said in a Google Meet call.
- A test suite that guards nothing. CI exists and runs the browser tests, but the BE rspec suite never runs in CI. The backend developer runs it on his own machine stakeholder. Does the FE developer run it too when he delivers BE features guided by an LLM agent? Probably. But a green CI is the best guardrail, and it's missing.
- No error reporting. There is no error tracking in any client. No persistent logs either: Heroku keeps a rolling buffer of about 1,500 lines web. A sudden bug in production can stop a factory, and there is no way to react fast.
- A habit of rewriting. In February 2026 the frontend rewrite began, and refactoring commits are permanent residents of their git history observed. When adoption stalls, the team rewrites.
I spent the first half of the audit on this list, because every item on it is measurable. But the team can fix all of them, fast. The chat becomes an issue board in one mechanical pass by an agent. The test suite needs one additional job in a CI that already exists. Error tracking is a purchase. A harness for the coding agents is a few files offloaded from the BE developer's agent memory. Rewrites can simply stop. None of it needs significant money investments beyond what is already being spent, and all of them can be repaid quickly.
All of that is the second loop of continuous improvement: making the machine that builds the product better. The major problem sits in the first loop — finding out whether this is the product worth building at all.
What Only the Owner Can Do
No matter how the team upgrades the delivery machine, refactors the already good enough code, or adds new features, it can't change the only deciding factor of a successful product startup: discover what your real customers want and how to sell it before you run out of money. The owner literally owns two real factories which can validate the whole product promise, find valuable insights, collect feedback, figure out integration costs and GTM. All of this is unused.
Run the system for real, on a factory floor, with real workers and real pay, and keep running until it breaks somewhere. Go break stuff, this is how you learn!
Every attempt to set up a real production run ended up in expected friction. Nobody expects that a new ERP system integration goes smoothly. The only pilot on live workers, back in August 2025, broke in five places observed. But instead of the classic "pivot or persevere", the owner decides each time that they need one more feature, one more rewrite to properly launch. Coding features that nobody validates is vanity. They might be valuable. But that is just the owner's assumption. There is no learning in the loop, and this is a textbook expensive mistake to make.
Everything the team controls is fixable. The one thing that decides the product's fate is the owner's commitment to a real production run.
The Coping Strategy
Without real feedback, the team does what good engineers do best: invents and adds new features, finds bugs, rewrites code, iterates. Yes, it makes the product feature rich. Yes, it improves the code. But it moves the product in a direction nobody measured it should be moved. No real pains have been solved yet. Just assumed ones.
This is a classical boiling frog position: it is painful to integrate the solution into real factories, and it is comfortable to keep adding features and refactoring existing code. But the water is boiling: no budget is unlimited, no competitor is toothless.
The Market is There to Conquer
What about competition? There is a nationwide adopted de-facto industry standard, the Shveika 8 system. It is claimed that more than 550 Ukrainian factories use it web. It already ships the same shop floor loop the product promises: barcode scanning of an operation at the moment the work is done. And it sells onboarding as a product — a two-month paid pilot, credited towards the purchase web.
Fortunately for SaaS ERP, Shveika 8 is a BAS (ex 1C) submodule, and it is sold only together with it: UAH 13,500 for Shveika 8 plus UAH 15,600 for BAS Small Business, per workstation web. BAS is banned for the state sector and critical infrastructure in Ukraine, because the platform underneath it is treated as technologically akin to Russian 1C web. It was cheap and old enough that it received general adoption before the Russo-Ukrainian war. Probably every Ukrainian business is happy to leave BAS if they can. They usually can't. Either there is no product for a similar price, or the friction of changing ERP is too big, so they take the risk of using a system that may be banned for private use — a bill extending the ban, with fines up to 2% of annual turnover, is registered but not adopted web — or steal valuable business data any day.
Replacing BAS in Ukraine is a goldmine problem many people are trying to solve every day. The SaaS ERP product must be better, have a faster GTM and less friction than the competition.
What I Would Do
On the team's side, do the cheap things anyway, because they lower the price of the owner's decision. Make failure visible and safe first: error tracking in every client, a timeout on the reservation, an idempotent scan. About a week of work, and it removes the owner's most reasonable reason to wait. Then turn the chat into an issue board, put the test suite in CI, and stop starting rewrites.
On the owner's side, there is the whole plan: pick a date, one factory, one garment, six weeks, running in parallel with the factory's existing books and compared every day, and do not stop at the first failure. There is no time to make new features. Persevere on what you have and iterate from real factory feedback. Frictionless onboarding is the top priority. You can't test the onboarding friction without doing real onboarding. Then find paying customers. After that you can even seek funding to boost development, marketing and sales. The competition won't wait for your second frontend refactoring.
The rest I wrote down as Policies & Operations. Six proposed policies. I tried to make them easy to automate and as frictionless as possible:
- The chat history becomes an issue tracker, and error tracking files issues on its own.
- The main branch is guarded by the green test suite that already exists, and every run publishes coverage.
- A factory pilot runs only in parallel with the existing books.
- Seventy percent of the team's capacity goes to the launch, and a weekly table shows where it actually went.
- The product promise has a named owner and a check date; if the check does not happen, the promise is retired in writing.
- No new rewrite starts until its reason, its exit criterion and its date are written down.
Stakeholder Answered and the Risk Fired
I presented the report to the BE developer on 19 August 2026, and asked him for feedback on 8 September.
The owner was stuck on onboarding friction and decided to postpone the launch again. This time it was how to group the factory's equipment — and he is right that it matters, because in the model equipment maintenance is tied to the equipment subgroup stakeholder. Instead of fixing the friction, the team does another rewrite (the mobile app v2) and another feature (role based authorisation) stakeholder.
That was the risk I had described, and it fired. A rewrite of the mobile app, a new feature, with no factory running, is the same pattern again.
From the team's side, it is a comfortable place to be for as long as the money lasts. From the product's side, it is a losing strategy. The team will keep building features and rewriting them, earn nothing, and learn nothing, because the only thing that teaches a product like this is feedback from a real factory, and there is no factory in the loop. The frog is boiling.
The arithmetic makes it sharper. Roughly USD 100k has already gone into development inferred. My assumption is that reaching outside customers will take at least another USD 50k in marketing and sales assumed. And the one asset that could turn all of that into a product, the two working factories and an owner who knows the domain better than anyone on the team, is sitting unused. The team can build everything else. Only the owner can start the run.
If anyone involved reads this: corrections are welcome. Every claim above is sourced in the full audit, and the open questions are listed at the end.