After More Than a Decade in Backend Engineering, Why I Started Building SaaS, AI Products, and Global Websites

For more than a decade, most of my work has been in enterprise backend systems.

Java, Spring Boot, microservices, high-concurrency systems, data consistency, and operational stability formed the foundation of my engineering practice. That work trained me to care about system boundaries, failure handling, performance, maintainability, and the way complex business software survives over time.

It also made one thing increasingly clear:

A technically correct implementation does not automatically become a product people understand, adopt, or continue to use.

A product that can create value needs more than a backend. It needs sound problem selection, clear positioning, usable workflows, deliberate delivery, operational ownership, and feedback after launch.

That is why I started independently building SaaS products, AI systems, and websites for global markets.

This is not a move to frontend. It is ownership of the complete product

I am not moving from backend to frontend, and I am not replacing more than a decade of experience with a new set of technology labels.

The real change is one of responsibility. Instead of owning only one layer of a system, I am taking responsibility for the complete product outcome, from defining the problem to putting a usable version in front of real users.

In a mature team, product, design, frontend, backend, testing, and operations are shared across specialized roles. As a backend engineer, I focused primarily on business models, service boundaries, data consistency, performance, and reliability.

Those concerns remain essential. Independent building simply adds more decisions to the same loop:

• Is this problem worth solving?
• What belongs in the first version?
• How will a user understand and operate the product?
• How should the interface and backend support the same workflow?
• How will the product be deployed, operated, and improved?
• What evidence should determine whether to continue, change direction, or stop?

Next.js, React, and TypeScript are not new identity labels for me. They are tools that let me deliver the whole product.

My backend experience has not become less relevant. It helps me control complexity while I build SaaS products, AI systems, and global web experiments that need to remain understandable after the first release.

Why I want to build complete products independently

In a highly specialized organization, an engineer can do excellent work on one part of the system without seeing the entire path from an idea to market feedback.

Independent building places technical decisions inside a larger set of constraints. Time is limited. Budget is limited. User attention is limited. In many cases, the demand itself has not yet been validated.

Engineering then includes deciding what not to build. A focused first version that can launch and produce evidence is usually more valuable than a feature-rich system that never reaches users.

The capability I want to strengthen is this full delivery loop: clarify the problem, control scope, design the architecture, implement and test the product, deploy it, and learn from what happens next.

Why SaaS

SaaS connects engineering decisions directly to recurring business workflows.

A product that people rely on over time usually needs identity, permissions, billing, workflow state, operational tooling, notifications, audit history, and integrations. These may look like separate features, but they are connected systems questions:

• Where are the business boundaries?
• Which workflow must remain extensible?
• How do we keep data trustworthy?
• How much complexity is justified in version one?
• How do we move quickly without creating an immediate rewrite?

This is continuous with my backend and architecture experience.

I also want to turn recurring engineering problems into reusable assets: authentication, permissions, admin operations, billing, audit, and notification modules. They may become my own SaaS or template products, and they may also help other founders reach a credible first release faster.

Why I am building AI systems, not just calling a model

My interest in AI products is not about adding a chat box to a website or wrapping a model API in an impressive demo.

Useful AI needs to enter a real workflow. It must work with trusted data, use controlled tools, complete multi-step tasks, and make its execution observable, evaluable, and interruptible.

From an engineering perspective, the model is one reasoning component inside a larger system. Several distinct layers determine whether that system can be used in practice.

RAG: grounding the model in the right business knowledge

RAG is more than uploading documents and asking questions.

A credible retrieval pipeline involves ingestion and refresh, document parsing and chunking, vector indexing, keyword and vector hybrid retrieval, reranking, context assembly, permission filtering, source citations, and evaluation of both retrieval and answer quality.

If the retrieved material is wrong, stale, or inaccessible to the current user, fluent generation does not make the answer trustworthy.

The purpose of RAG is not simply to make a model “know more.” It is to let a model reason with information that is relevant, current, attributable, and inside the correct permission boundary.

Agents: allowing the model to move a task toward a goal

Traditional applications usually encode each step of a process in advance.

An Agent can use the current goal and execution state to decide which tool to call next, whether it needs clarification, and when it should stop or return control to a person.

That does not mean every AI feature should become a fully autonomous Agent. Predictable, high-risk processes are often better implemented as deterministic workflows, with models responsible only for the parts that require interpretation. Agentic behavior becomes valuable when the path cannot be fully enumerated and the model genuinely needs to choose actions based on changing context.

The important architecture decision is:

Which steps are controlled by code, which are delegated to a model, and which actions require human approval?

An Agent depends on more than model quality. Tool contracts, context and state management, exit conditions, timeouts, retries, cost limits, and failure recovery all shape whether it can operate reliably.

MCP: a standard boundary for external capabilities

As Agents connect to files, databases, code repositories, internal systems, and third-party services, writing a bespoke integration for every combination creates repeated work.

MCP provides a standardized protocol boundary through which AI applications can discover and use Resources, Tools, and Prompts. Resources provide context and data, Tools expose executable queries or actions, and Prompts provide reusable interaction templates.

MCP addresses connection and capability discovery. It does not replace RAG, an Agent, or the business workflow around them.

Not every AI product needs MCP. Direct tool integration may be simpler for a small number of stable internal APIs. MCP becomes more valuable when a system needs to connect to multiple sources and tools, or when the same capabilities should be reusable across different AI clients.

The hardest production problems still sit outside the model

Put together:

• RAG determines what information the model can rely on.
• An Agent determines how the model moves a task toward its goal.
• MCP provides a standard way to discover and connect external resources and tools.

But production readiness still depends on engineering outside the model: authentication and authorization, prompt injection and tool-use risk, execution state, timeouts and retries, idempotency, failure recovery, human approval for sensitive actions, token and latency budgets, tracing, logs, test sets, and continuous evaluation.

These concerns are closely connected to the boundaries, state, security, reliability, and observability I have worked with in backend systems for years.

I am not building AI because backend engineering has become obsolete. I am building it because once AI moves beyond a demo, mature systems engineering becomes necessary again.

I am currently building an AI Business Agent Console to explore how knowledge systems, Agent workflows, MCP tools, human approval, execution logs, and quality evaluation fit together as an operational AI system.

It is still Building. I will document the real decisions and implementation, but I will not present unfinished capability as a mature product.

Why global websites are part of the same direction

A focused website can validate a market question at a lower cost than a complex SaaS product.

It can test whether people search for a problem, where current solutions fall short, which explanation users understand, and whether the direction deserves more investment.

Not every idea should become a large product. Some are better as small tools, some as content sites, some may grow into SaaS, and some should stop after initial research.

Choosing not to build is also a useful result.

I want to use global websites and small product experiments to develop a more evidence-based way of making product decisions: ship a focused version into a real environment instead of discussing the market entirely from imagination.

Why I am documenting the process publicly

Yuzhe.dev is not only an online resume, and it is not only a site for overseas client work.

It is the public entry point to my work: products in progress, completed cases, technical decisions, and the path from an idea to a released product.

Building in public does not mean publishing daily evidence of being busy. It means leaving a record that can be checked: why a direction was chosen, what version one included, which features were removed, how the product was tested and deployed, what happened after launch, and why the project continued, changed, or stopped.

These records help me think more clearly. They also help product users, potential collaborators, and other developers understand how I work.

If I eventually create SaaS templates, a course, or a community, they should grow from repeated practice. The sequence matters: build and deliver first, solve real problems more than once, and only then package the durable parts into a product or body of content.

The three tracks I am developing

The first track is complete product delivery: helping founders and solo entrepreneurs turn an idea into a launchable web application, SaaS product, operations system, or AI feature, with a controlled first-version scope.

The second track is owned products and experiments: global websites, SaaS products, and reusable templates. Not all of them will work, but each should produce evidence and a clearer decision.

The third track is public content and long-term assets: writing, X, and video about product judgment, system design, AI engineering, independent development, and market validation.

Together, these tracks can form a personal brand, but that brand has to be supported by real work and sustained delivery.

The rules I want to keep

• Finish a version that can be validated before expanding scope.
• Clearly distinguish Live, Building, and Experiment.
• Never invent clients, revenue, traffic, users, or outcomes.
• Make technical choices serve delivery, operations, and maintainability.
• Document stopped directions and Build / Skip decisions, not only successes.
• Build templates, courses, or communities only from real and repeatable practice.

These rules may produce less impressive short-term marketing. They are more useful for building long-term trust.

What comes next

Yuzhe.dev will be the common entry point for this work.

StudioOps Admin and the AI Business Agent Console are still in development. Global website experiments, SaaS products, and templates will be published when they reach an honest stage worth showing.

I will not assume that every project succeeds, and I will not write the outcome before it happens.

The question I want to keep exploring is more practical:

How can an experienced engineer extend technical capability into product judgment, delivery, and market validation, then turn that work into a sustainable independent business?

This article is the beginning of that public record.

If you are also building SaaS, an AI product, or a global website, feel free to reach me through X, WeChat, or email. If you are considering a launchable first version of a product idea, you can also prepare a Project Brief so we can decide whether a conversation makes sense.

Further reading

• Model Context Protocol architecture
• Anthropic: Building effective agents
• OpenAI: A practical guide to building AI agents