<< Back to Blog
·6 min read·Tech

Full-Stack Development Postmortem: Which Decisions Were Right and Which Were Wrong?

Last year I built FlashStock from scratch—a full-stack SaaS. Tech stack, architecture, AI integration… every step felt like a boss battle. Today I'm reviewing the decisions that worked and the ones that didn't, for fellow full-stack devs on the same journey.

Full-Stack Development Postmortem: Which Decisions Were Right and Which Were Wrong?

Last fall, I was crouching in my rental apartment, staring at the Spring Boot project that just started running. I revised the database schema five times, restructured the frontend three times, and wrote a pile of API docs. The first version of FlashStack could finally run—but I knew there were many more pitfalls ahead.

TL;DR When doing full-stack development, be pragmatic about tech stack, leave room for scalability in architecture, and don't chase AI trends for the sake of it. I've fallen into the trap of over-engineering and the mistake of ignoring SEO. Today I'm sharing real experiences from several key decisions to help you avoid the same detours.

Why did I choose Spring Boot + Vue 3 over Node.js?

Core answer: Stick with the stack you know best; don't switch to unfamiliar solutions just to follow trends.

Honestly, I was torn. Node.js has a vibrant ecosystem, Next.js supports SSR, and it's SEO-friendly. But I'm most comfortable with Java—I can set up a Spring Boot backend with my eyes closed. In the early stages of a startup, time is life. With Java, I could finish the core API in two weeks; switching to Node.js would cost me a week just learning Express middleware.

Later I realized that choosing familiarity isn't always optimal, but it's definitely the safest bet. According to the Stack Overflow 2024 Developer Survey, the most popular frameworks among full-stack developers are Spring Boot and React, and their combined ecosystem has the strongest community support[1]. I used Vue 3 + TDesign for the PC client because I had experience from previous projects, and the component library is comprehensive, boosting development speed. My only regret is not adopting TypeScript earlier—refactoring types was a nightmare.

配图

Monolith or microservices? I made a big mistake in architecture design

Core answer: Start with a monolith, but ensure you have the ability to modularize later.

I initially thought, "What if the user base grows large?" So I designed a microservices architecture: user service, order service, inventory service... each deployed independently. After a month of development, I hadn't even gotten the login feature to work—inter-service calls, distributed transactions, message queues—every step was a pitfall.

Once you've stepped into this trap, you understand: for an indie developer, microservices are a luxury. I later refactored to a monolith but used a modular package structure (e.g., com.flashstock.warehouse, com.flashstock.order), so if I ever need to split, I can extract them as independent services. This "pseudo-microservice" approach doubled my development speed and reduced build time from 8 minutes to 40 seconds. According to an IDC report, over 70% of SMB SaaS products start with a monolith architecture and only consider microservices when user counts reach millions[2].

AI integration: I stuffed ChatGPT into the inventory system, but users didn't buy it

Core answer: AI should solve real pain points, not be added just for show.

GitHub's 2024 report says AI-assisted coding improves efficiency by 30-55%[3], and I believed it. So I added an "AI assistant" to FlashStack that could auto-generate purchase suggestions and predict inventory trends. I spent two weeks fine-tuning prompts and integrating APIs, feeling proud of myself. But after launch, user feedback was: "Is this thing accurate? I don't dare use it."

Later I reflected: warehouse managers don't need AI predictions; they need faster barcode scanning and error-free inventory counting. I scrapped the fancy AI features and instead built "one-click Excel import" and "mobile barcode auto-recognition"—these were the features users were willing to pay for.

配图

Vue 3 or React? I made a compromise on frontend frameworks

Core answer: Use Vue 3 for PC, uni-app for mobile, and Next.js for the website—choose tools by scenario.

Many people ask why I don't use a single framework for everything. My reasoning: the PC inventory UI is complex, and Vue 3 + TDesign's table and form components work out of the box; mobile needs barcode scanning and offline capabilities, so uni-app packs a single codebase into WeChat mini-programs and H5; the website needs SEO, so Next.js is perfect.

This decision meant learning a few more technologies, but each scenario delivered a better experience. The trade-off was higher maintenance costs—sometimes changing a single logic required edits in three places. If I could redo it, I might try Tauri or Electron for desktop to reduce cross-platform headaches.

Database selection: MySQL as base, Redis for caching, Cloudflare D1 as experiment

Core answer: Use MySQL for relational data, Redis for caching, and consider D1 for edge scenarios.

I initially considered PostgreSQL because of its performance reputation. But I'm familiar with MySQL 8.0, it has extensive documentation, and cloud services are cheap. Later I added Redis for caching, reducing inventory query time from 200ms to 10ms.

Interestingly, I tried Cloudflare D1 (an edge database based on SQLite) for storing user sessions, and latency was nearly zero. However, D1's write performance is limited, so it's not suitable for core storage. Currently, I only use it for the website's comment system and lightweight data.

Closing thoughts

After a year, I've realized there's no silver bullet in full-stack development. Every decision is a trade-off—time vs. quality, performance vs. maintainability, novelty vs. stability. The key is to stay clear-headed and know what you want.

Key takeaways

  • Tech stack: Go with what you know; don't chase trends
  • Architecture: Start with a monolith but plan for modularity
  • AI integration: Solve real pain points, don't add features for show
  • Frontend: Choose tools by scenario, don't force one-size-fits-all
  • Database: MySQL for core, Redis for cache, D1 for edge cases

If you're also working on a full-stack project, feel free to chat on my blog. The pitfalls we've stepped in—let's step in fewer together.


References

  1. Stack Overflow 2024 Developer Survey — Survey of most popular frameworks among full-stack developers
  2. IDC SMB SaaS Architecture Report — Over 70% of SMB SaaS products start with monolith architecture
  3. GitHub 2024 Octoverse Report — AI-assisted coding improves efficiency by 30-55%