I Almost Lost Commerza: The Brutal Reality of Building an Ecommerce System Without a Framework

I am 19 years old. I set out to build a production-grade e-commerce system from scratch. No Laravel. No React. Just raw PHP, MySQL, and a lot of stubbornness.

I call it Commerza. It is a security-first storefront and operations panel with 238 files of pure, custom architecture.

But I almost killed the entire project before anyone even saw a single line of code. This is the story of how relying too much on AI almost wrecked my system, and how the rebuild forced me to become a real software engineer.

The Code Red: A 9,800-Line Disaster

Like many developers today, I leverage AI tools. Gemini, Claude, Copilot — they act as a sounding board to accelerate development. But they are tools, not architects. I learned that the hard way.

Nearing what I thought was the “completion” phase of my backend, things had gotten messy. I had files ballooning to anywhere between 6,000 and 9,800 lines of code. The logic was tangling. Instead of doing the hard work of refactoring it myself, I got lazy. I asked GitHub Copilot to logically split those massive files into modular components.

It did not split them. It butchered them.

In a matter of seconds, Copilot scrambled the logic and outright deleted 40% of my backend. Critical functionalities vanished. My custom API endpoints, my image compressor, the parser feature, and several core JavaScript files were just gone.

I sat staring at the screen. I was ready to turn off the computer, delete the folder, and abandon the project completely.

The Biggest Mistake Was Not the AI

It took me two days and roughly 9.6 hours of pure screen time to manually stitch the backend back together.

Why did I have to do it manually? Because of the ultimate rookie mistake: It wasn’t on Git.

If I had been committing my code properly, a simple git restore . would have saved me. Instead, I paid in blood and time.

The Hard Truths About Version Control:

• Push constantly: A local copy is not a backup. A Git repository is.

• Protect your secrets: Never, ever share your .env file or database credentials on GitHub. I spent hours analyzing the difference between public and private repositories and utilizing .gitignore and git filter-branch to ensure my commit history was scrubbed of any leaked SMTP or database passwords before going public.

# Environment secrets
.env
.env.*
!.env.example

# Temporary local maintenance scripts
.history-scrub.ps1

# Dependency directories
node_modules/
vendor/
!frontend/assets/vendor/

# Local runtime artifacts
*.log
*.tmp
*.cache
*.out
*.pid
*.seed

# Package manager / test artifacts
npm-debug.log*
yarn-debug.log*
pnpm-debug.log*
coverage/
.phpunit.result.cache

# OS noise
.DS_Store
Thumbs.db
Desktop.ini

• Own your code: AI can write syntax, but it cannot hold the context of your entire system. If you don’t understand the architecture, you can’t fix it when the AI breaks it.

The Frontend-First Trap

Not using Git wasn’t my only architectural sin. I made the massive mistake of building the frontend first.

I designed the UI using .html files and relied on hardcoded JSON fetching to populate the data. It looked great, but when it was time to actually connect the PHP backend, the data mutation flow was a nightmare. I had to rip out the static HTML, convert everything to server-rendered .php templates, and entirely rebuild how the client communicated with the server.

Always build the engine first. Paint the car later.

Rising from the Wreckage: The Architecture of Commerza

After the 9.6-hour rebuild, my mindset shifted. I stopped coding like a hobbyist and started coding defensively. I didn’t just rebuild the APIs; I built a fortress.

Here is what the architecture looks like today:

commerza/                  # Example
├── admin/                 # Restricted operations UI and Auth
│   ├── api/               # Admin-specific backend endpoints
│   └── frontend/          # Admin dashboards and management views
├── backend/               # The Engine
│   ├── core/data.php      # Shared bootstrap and DB connection
│   ├── security/          # Argon2id, CSRF, and CAPTCHA models
│   ├── payment/           # Stripe verification and COD logic
│   └── jobs/              # Cron-based automation scripts
├── frontend/              # Storefront static assets (CSS, JS, media)
├── .env.example           # Secure environment template
└── .htaccess              # Apache routing and security gatekeeper

Engineering for Production

Building without a framework means you have to write your own security, performance, and SEO layers. I couldn’t just run an artisan command.

1. Database Safety & Concurrency I implemented strict transactional locking. When an order is placed, the system executes a SELECT ... FOR UPDATE lock on the database row. This prevents race conditions, double-orders, and negative stock if two users try to buy the last item at the exact same millisecond. Every user-facing query uses strict prepared statements to eliminate SQL injection.

2. The Anti-Bot Layer The login and checkout flows are protected by a layered CAPTCHA model. It attempts a silent reCAPTCHA v3 verification first. If it detects suspicious behavior, it degrades to a v2 checkbox, and finally to a custom mathematical fallback challenge. Combined with strict CSRF tokens and rate limiting, brute-force attacks are neutralized at the door.

3. Identity & Access Passwords are hashed using Argon2id. But security isn’t just about passwords. I built a sub-admin lifecycle where, if a staff member is suspended or their permissions are altered, their session is immediately revoked server-side. No waiting for a cookie to expire.

4. Performance & Dual-Theme UI The frontend is highly optimized. I configured .htaccess to handle static asset caching and clean-routing for SEO (turning messy PHP queries into clean URLs). The UI features a native, zero-dependency Dual-Theme system. Users can toggle between a high-contrast Dark Mode (OrangeRed + Black) and a clean Light Mode (NavyBlue + White), with the preference persisting via local storage.

5. Payments Checkout handles both Cash on Delivery (with configurable OTP limits for high-value orders) and Stripe card payments, with server-side PaymentIntent verification to ensure no transaction is manipulated on the client side.

The Final Lesson

Frameworks are incredibly useful, but they abstract the hard parts of engineering. By avoiding them, I crashed my own system, lost my code, and had to learn the raw mechanics of web security, transactional databases, and server routing.

It was brutal. But because of that Code Red, I don’t just know how to use a tool — I know how to build the machine.

Explore the Codebase: You can view the full repository, including the [SECURITY.md](https://github.com/ahmershahdev/commerza?tab=security-ov-file#) and detailed documentation, on GitHub: ahmershahdev/commerza

Live Deployment: The production environment will be officially live between 15 to 20 May 2026 here: commerza.ahmershah.dev

Connect With the Author