From a Generic ERP SaaS to a Vertical Industry System: A Practical Guide to Engineering Asset Reuse

Background

The first ERP SaaS project reached a stable iteration stage and accumulated a set of enterprise‑grade core capabilities such as backend services, PC admin console, mini‑program, permission system, data dictionary, product management, procurement, sales, inventory, import/export, reporting, and subscription mechanisms, together with a full suite of development standards and AI collaboration processes.

These include backend services, PC admin, mini‑program, enterprise permissions, menu configuration, data dictionary, product management, procurement, sales, inventory flow, import/export, operational reports, subscription system, and the surrounding development conventions and AI workflow.

When a client requested a vertical customization, the author first catalogued the existing assets, evaluated which could be reused, which needed trimming, and which required redesign, before writing any code.

01 Why Not Start From Scratch

Enterprise systems share many low‑level capabilities despite apparent business differences. Common infrastructure such as accounts, organizations, roles, permissions, menus, logs, data dictionaries, basic data, import/export, reports, approvals, and configuration appears in almost every system and must eventually be completed once the project enters real business scenarios.

The vertical project still required login, permissions, menus, product, customer, order, inventory, and reporting—capabilities already validated in the first ERP, so a full rewrite was unnecessary. However, reuse is not simple copying; business assumptions behind code may no longer hold, and blindly transplanting logic can increase maintenance cost.

02 What the First Project Left Behind

The first ERP left a relatively complete engineering organization rather than isolated pages or code snippets.

Engineering structure: Backend was layered following DDD principles; the frontend adopted a similar layered approach, preventing code sprawl as features grow and giving AI a clear insertion point.

General capabilities: User, role, permission, menu, data dictionary, system configuration, basic data, import/export, and reporting modules have high reference value across projects.

Business experience: Domain knowledge about products, procurement, sales, inventory, document flow, and accounts‑payable/receivable aids domain modeling, state flow, data consistency, and boundary splitting in new contexts.

Documentation standards: PRD, DDD, ADR, specs, API contracts, coding conventions, and AI Rules provide the context needed for both developers and AI to understand the project.

AI collaboration process: A cycle of requirement clarification, domain modeling, task breakdown, code generation, code review, and manual verification was established in the first project and proved more valuable than raw code copying for the second project.

03 Reuse Is Not Copying

The key question is not "which code can be moved" but "which capabilities remain valid in the new project." Core capabilities such as login, permission, menu, basic data, import/export, and reporting can be retained. SaaS‑specific features like subscription, payment, self‑service onboarding, and package limits are trimmed because the vertical project focuses on custom delivery rather than a full SaaS commercial flow.

New business models—headquarters‑partner ordering, centralized distribution, localized pricing, and CRM‑style course consumption—require re‑modeling. While the underlying procurement‑sales model can be referenced, the added partner coordination, data isolation, and permission boundaries demand fresh design.

04 What AI Did in This Migration

AI’s role shifted from generating initial drafts in a greenfield project to assisting the reuse process.

AI read the old project’s structure, listed modules, and identified boundaries (generic support vs. business‑specific vs. legacy).

AI produced draft PRD, domain models, ADRs, and specs for the new project based on existing documentation—useful as discussion starters but not final artifacts.

AI handled repetitive migration tasks such as renaming packages, adjusting directory layouts, updating interface names, DTOs, scaffolding pages, and CRUD scaffolds, achieving high efficiency when specifications are clear.

AI assisted code review by checking layer conformity, naming consistency, documentation‑implementation alignment, and spotting obvious omissions; final judgments remained human‑driven, especially for business rules, data consistency, permission boundaries, and exception flows.

05 Key Takeaways

Define boundaries before reuse. Separate generic infrastructure, original business logic, and features not needed in the new context.

Documentation fuels AI understanding. Clear PRD, domain models, API contracts, and task descriptions are essential for AI to provide accurate assistance.

Complex business cannot rely solely on page generation. UI scaffolding is fast, but state machines, data integrity, permission scopes, and error handling must be designed manually.

Reusable assets go beyond code. Directory layout, naming conventions, interface style, exception handling, permission model, review workflow, and task decomposition are all part of the engineering asset pool.

Vertical customization vs. standard SaaS have different priorities. SaaS emphasizes self‑service onboarding, packaging, payment, and scalability; vertical projects focus on specific scenarios, delivery speed, and end‑to‑end processes.

Conclusion

AI can dramatically boost development efficiency, but if every project starts from zero, valuable experience never accumulates. Preserving a clear engineering structure, reusable capabilities, documentation standards, and collaborative processes turns each project into a foundation for the next, reducing redundant effort and improving overall productivity.