Building an AI‑Native B2B Software from Scratch: 6 Pitfalls I Learned

Pitfall 1: Ignoring Core B2B Needs for AI

At project kickoff the team fell into an "AI arms race", stuffing the demo with natural‑language interaction, intelligent‑ops agents, automated vulnerability fixing, and personalised workflow orchestration. When presented to government and state‑owned customers, they only asked three questions: where the large model is deployed and whether data leaves the domain, how AI‑driven resource permissions are controlled and who is liable for security issues, and whether the AI adds value beyond a few hundred‑thousand‑yuan cost.

Solution: We cut 80% of the flashy features and focused on a single core pain point – the difficulty of low‑level operations for infrastructure staff. We built an "Ops‑Safety Copilot" that runs all AI actions inside a trusted execution environment on domestic chips, with four‑layer controls (permission check → security audit → traceability → anomaly circuit‑break) that meet Level‑3 protection requirements. This became the main selling point.

Pitfall 2: Writing Only "Sunny‑Day" Flows, Ignoring Exceptions

The first PRD described only the ideal flow: user inputs a natural‑language command, AI executes correctly, and outputs the result. No exception scenarios were documented.

What if AI misinterprets a command and performs a high‑risk operation?

What if system resources are insufficient and the AI task crashes?

What if network interruption causes the large model call to fail?

What are the operation boundaries for users with different permissions?

Developers rejected the PRD, saying it described an ideal state while 90% of real situations are exceptions.

Solution: We rewrote the PRD to attach at least five exception‑handling rules to each main flow, defining a full‑chain logic of normal → warning → exception → circuit‑break → rollback, even detailing how AI should refuse and audit illegal commands. After release, customers praised the clear boundary between what AI can and cannot do.

Pitfall 3: Turning the PRD into a Technical Document Unreadable by Others

Being technically inclined, the initial PRD was filled with kernel‑mode, user‑mode, RAG, vector‑database, and trusted execution environment jargon, making it incomprehensible to front‑end developers, business stakeholders, and sales.

Solution: We split the PRD into three layers:

Core Business Layer – a flowchart and one‑sentence value statement for business and sales.

Product Logic Layer – prototype and state‑transition diagrams covering normal and exception rules for the whole team.

Technical Integration Layer – a table specifying interface contracts, data formats, permission rules, and security boundaries for developers.

Requirement review time dropped by 70% and no longer suffered from “developers can’t understand the PRD”.

Pitfall 4: Overlooking Compliance Requirements, Rendering Features Undeliverable

We initially chose the most effective open‑source large model, only to discover its training data violated domestic compliance, it could not pass Level‑3 protection assessment, and it was incompatible with domestic CPUs, OSes, and databases.

Solution: We created a “negative checklist” with three non‑negotiable rules: use a nationally‑registered model that supports full on‑premises deployment, ensure all AI functions meet Level‑3 protection and commercial‑encryption regulations, and achieve 100% compatibility with mainstream domestic hardware and software stacks. Every feature now passes this checklist before design.

Pitfall 5: Over‑ambitious MVP That Delivered Nothing

We planned ten features for a 30‑day MVP, assuming “more features = more customer choices”. After two weeks, two developers could not sustain the workload and each feature was only a superficial prototype.

Solution: Using a "User‑Pain‑Value" matrix, we filtered the ten ideas down to the "Ops‑Safety Copilot" alone, investing all resources to perfect its core scenario, exception handling, compliance adaptation, and user experience. The client later said this single feature solved a three‑year operational pain.

Pitfall 6: Treating Casual Customer Requests as Core Requirements

A maintenance manager casually asked for an AI‑generated weekly report. We built it in a week, but the client could not use it because the reports must follow a strict format and contain classified information, making AI‑generated content invalid.

Solution: We instituted a three‑level demand‑validation mechanism. A request proceeds only if it (1) addresses a core business pain with broader applicability, (2) delivers quantifiable value, and (3) aligns with our product positioning and core track. Only demands passing all three checks enter the development backlog, dramatically reducing wasted effort.