From Solo AI Experiments to Enterprise SaaS: Practical Lessons on Building a Commercial Product

Background

I started experimenting with AI in 2024 and began large‑scale testing of various large language models in early 2025. Initially I only built demos and small utilities, which felt like "castles in the air". To turn AI into a real employee, I decided to develop an enterprise‑grade inventory management product using Vibe Coding, combining AI, operations, and a standard SOP.

Motivated by a family business model, I first used ChatGPT and Gemini to generate industry knowledge and an initial business model. After two months I delivered a mini‑program MVP, followed by a one‑month PC admin portal, both built from scratch with the latest stack and a DDD‑inspired layered architecture for the front‑end.

Customer feedback quickly revealed that real workflows differed from my assumptions, leading to extensive incremental development. Early payments were made via personal WeChat and permissions were granted manually, highlighting the gap between MVP and a production‑ready product.

After more than six months of iteration, the product’s logic and framework stabilized, and the first paying customers appeared.

My View on Product Commercialization

Without a clear path to revenue, a product will likely be abandoned. The biggest mistake I made was designing the early version for personal or small‑team use; only after an enterprise client showed interest did I pivot the product toward a full ToB solution.

If I could redo the launch, I would develop the backend, PC admin, and mini‑program simultaneously, though limited personal capacity makes this difficult. As a backend TL/architect, I first became a full‑stack developer to review AI‑generated front‑end code and ensure production readiness.

I prefer native technologies for better user experience, but postponing mobile (iOS/Android) development until the core product stabilizes inevitably leads to some customer churn.

01 Multi‑Platform Product Shape

In an ideal commercial scenario I would ship backend, PC admin, and mini‑program together; a mobile client is optional due to the steep learning curve.

Learning front‑end web technologies was essential because I needed to evaluate AI‑generated UI code for production suitability.

02 Enterprise‑Grade Permission System

Enterprise customers require granular role‑based access control (RBAC) across all clients. The backend should expose a flexible permission model that can be extended with dimensions such as department, while the admin and mobile clients enforce menu visibility, route guards, element‑level controls, and data permissions.

03 Business‑Process Capability

Unlike personal bookkeeping, enterprise systems must model end‑to‑end workflows: each document passes through a responsibility chain, requiring audit mechanisms, status transitions, and traceability.

04 Enterprise Data Capability

Once processes are defined, businesses demand a complete data‑closed loop. I organize data capabilities into three layers:

Reporting – e.g., sales profit overview, receivables/payables.

Export – allowing raw documents and analytics results to be extracted for reporting or archiving.

Import – bulk initialization and maintenance of master data.

Performance must be considered; large data volumes can easily overwhelm servers.

05 Commercial Capability

The first step to SaaS commercialization is a configurable subscription system: tiered pricing based on employee count, feature‑based differentiation, and backend‑driven configuration rather than hard‑coded limits.

In China, integrating WeChat Pay and Alipay covers most needs; third‑party aggregators are costly and risky unless you are a pure individual user.

06 System Configuration Capability

Hard‑coding logic works for early delivery but quickly becomes a bottleneck in enterprise settings. Configurable workflows and data rules enable per‑customer customization without code changes, dramatically reducing delivery cost and increasing scalability.

My View on AI Usage

I spend at least eight hours daily using AI tools, often for months on a single tool, giving me practical authority on their strengths and weaknesses.

01 Choosing AI Tools

Claude Code / Codex are the core productivity tools, followed by Cursor / Google Antigravity, then domestic alternatives.

This ranking reflects personal experience; other tools can work if circumstances differ.

When Cursor offered 500 free tokens per month, it was sufficient for early development. After Cursor switched to token‑based billing, I combined it with Trae (600 free tokens) and began using SDD (Specification‑Driven Development) to split tasks. Eventually I adopted a CLI‑based workflow for maximum efficiency.

Do not waste time on free‑wheel tools; prefer official direct APIs, and choose a paid coding plan once usage scales.

02 SDD + DDD for Complex Business

I am a strong DDD advocate, applying it even to solo projects. With AI, I enforce rules and memory documents to tightly constrain code output, extending DDD’s layered architecture across all clients, which improves readability and fits a monorepo design.

SDD can draw from Spec‑kit or OpenSpec; extract only the core parts needed for the project. Customization to the actual project is essential—blind reuse leads to unnecessary overhead.

The essence of complex systems is structural generation, not raw code generation; start with domain modeling before letting AI write UI or forms.

03 Git and Review Are Mandatory

All AI‑generated changes must be committed to a Git repository first, enabling diff comparison with the latest code. Without this, AI‑produced code mixes with human code, making review impossible.

Human review remains the final safeguard, though AI‑to‑AI review can be used as an intermediate step. Small, incremental commits are crucial.

04 Define Boundaries Before Coding

AI excels at fast production but can generate massive amounts of incorrect output if the problem definition is vague. Top‑level architecture design (technology stack, layered architecture, permission design, data modeling) remains a human responsibility.

My experience shows AI struggles with payment gateway integration and complex inventory logic, forcing me to revert to “old‑school” development for those parts.

05 Stable, Replaceable AI Workflows

AI should only handle well‑defined deliverables that can be verified. I split development into clear stages with explicit inputs, outputs, and acceptance criteria (e.g., PRD, UX mockups, domain models, architecture diagrams, tech‑stack selection, rule files, task breakdown, code development, review, refactoring, testing, and operations).

When each stage is well‑specified, swapping model A for model B does not break the pipeline, similar to swapping senior and junior developers.

Conclusion

Heavy AI usage can make a single developer feel like a “Iron Man” with amplified capabilities, enabling rapid end‑to‑end delivery that previously required multiple people. However, core software engineering challenges—system boundaries, architecture, business abstraction, stability—remain and cannot be fully automated.

Programmers who fail to adopt AI will likely be left behind; the competitive edge will come from leveraging AI to build faster, more stable, and reproducible production processes.

Appendix

Images illustrating the product architecture, permission system, business process flow, data capability layers, subscription model, Git workflow, AI boundary definition, and stable AI workflow are included in the original article.