Back to all articles
Build in Public

Build in Public Day 9: Local Server — Getting Everything Running

This is the day where building in public gets real. Not everything went according to plan — and that's exactly the point of showing the full process.

March 9, 20264 min read
Build in Public Day 9: Local Server — Getting Everything Running

This is the day where building in public gets real. Not everything went according to plan. And that's exactly the point of showing the full process.

The Objective

The goal was straightforward: get the local development server running so it matches the functionality we currently have in Lovable. Once that's working, we can start layering in real features.

What Actually Happened

It didn't go smoothly. There were dependency issues, configuration problems, and things that simply didn't work on the first attempt. This is normal when you're moving a project from one environment to another. Lovable's internal environment handles a lot of configuration automatically. Your local machine is a different story.

Debugging with AI

Here's where Cursor's AI capabilities proved their value. I used "ask mode" — where instead of having the agent make changes directly, I asked it to help me diagnose what was going wrong and suggest fixes.

The workflow looked like this: describe the error, let the AI analyze it, evaluate its suggested fix, learn about the underlying issue, implement the fix if I'm comfortable with it, and test. This iterative cycle — AI diagnosis, human evaluation, implementation, testing — is how you solve problems efficiently without blindly accepting whatever the AI suggests.

One key fix involved a dependency configuration issue. The AI helped me understand what was wrong, why it was wrong, and what the correct configuration should be. I learned something new about the tooling in the process. That's the ideal outcome — the problem gets solved and your understanding deepens.

The Real Lesson

Building in public means showing what goes wrong, not just what goes right. If you're building software in a custom way, things will break during setup. The skill isn't avoiding problems — it's diagnosing and resolving them efficiently.

By the end of the session, the local server was running with hot module reloading (changes reflect automatically without restarting the server), matching the Lovable functionality. The development environment was fully operational.

Starting the Backlog

With the environment running, I began outlining the development backlog. The approach: take the UI design and break it down into modules and features, then prioritize which to build first. This becomes the roadmap for the technical work ahead.

The Dev Environment Setup Playbook

Step-by-step guide to transition from Lovable to a real development environment with GitHub, Cursor, and Claude Code.

Your Takeaway

Expect things to break during setup. Don't panic. Use AI to help diagnose issues — Cursor's ask mode is excellent for troubleshooting. Learn from each fix rather than just applying it blindly. Document everything. And once your local environment matches your prototype, commit that working state to GitHub before changing anything else.

---

Next in the series: Day 10 — Project refactoring to prepare for backend and database.

Tags: Build in Public, Local Development, Clockless, Cursor, Debugging, AI-Assisted Development, Bootstrapping

Ready to Build Your Own SaaS?

Learn how to go from idea to launch in my free 5-day email course — no coding or big budget required.

Start the Free Course