Build in Public Day 10: Project Refactoring — Preparing for Backend and Database

Before adding real functionality, we need to reorganize the project. Refactoring now — with a relatively small codebase — is dramatically easier than it will be later when we've added features, API routes, and database connections.

Why Refactor Now

Lovable generates a Vite/React single-page application. That structure is great for prototyping, but for a production SaaS we need a clear separation between frontend and backend code, plus room for backend technology and a database. Reorganizing the project structure now sets us up for everything that comes next.

The principle is simple: it's much easier to restructure a small codebase than a large one. Every day we wait, the refactoring cost increases.

The Refactoring Plan

The restructuring involved three moves. First, move all frontend/React code into a `/client` folder — this is everything that gets served to the browser. Second, create a `/server` folder for the backend. Third, set up the backend technology.

For the backend, I chose Python — it's one of my preferred languages and excellent for the kind of data processing and API work this application will need. The choice of backend language is personal preference, but pick something you're comfortable with and that has strong library support for what you're building.

Using the AI Agent for Refactoring

I gave Cursor's agent (running Opus 4.5) a specific prompt: refactor the project and folder structure by moving everything related to the frontend into a client folder, creating a server folder, and setting up a Python backend. The AI handled the file reorganization, path updates, and configuration changes.

AI is particularly good at this kind of structural refactoring — it's systematic, it can track all the file references that need updating, and it's less likely to miss something than doing it manually.

The Result

After refactoring, both the client (React frontend) and server (Python backend) were running simultaneously. The frontend still worked exactly as before — no regressions from the restructuring. The backend was running but empty — no functionality yet, just the server framework ready to receive API routes, database connections, and business logic.

With both terminal windows running, I can see output from both client and server. As we add backend functionality, debugging information and request logs will appear in the server terminal — critical for development.

What Comes Next

The next step is adding database technology. I typically use PostgreSQL, and for this project I'll likely use Supabase as the service provider. With the project structure clean and the backend in place, we're ready to start prioritizing the feature backlog and building real functionality.

Your Takeaway

Refactor early, before the codebase grows. Separate frontend and backend cleanly into their own directories. Use AI to help with structural changes — it's particularly good at systematic reorganizations. Set up your backend technology framework before you start building features. Then commit the clean structure to GitHub as your new baseline.

---

What's Next: Database setup with Supabase, feature backlog prioritization, and the beginning of real feature development.

Tags: Build in Public, Refactoring, Clockless, Cursor, Python, Project Structure, Bootstrapping