Module 3 uses a separate Vite dev service for tight feedback, then builds static assets to keep production down to one simple container. It's a great approach, though heavy scaling often requires splitting services for independent deployment and fault isolation. #aidevtools

7/ Connected frontend to FastAPI (in‑memory). Added CORS, implemented ApiWaitlistService with fetch, kept mock for tests. Verified every flow with curl (guest join, staff login, queue ops, table CRUD, large‑party) before SQLAlchemy. Integration first, persistence next. #aidevtools

6/ The backend was generated against openapi.yaml: routers, schemas, services, in-memory repository, seeded demo data. A small script compares app.openapi() with the spec to catch drift early. 52 tests cover auth, guest flows, staff operations, and tables. #aidevtools

5/ Table management started as “show tables” in the UI. Extending it to CRUD + availability states (available / occupied / needs_tidying) required changes in: service interface, mock, OpenAPI, and later backend. Small feature, but a clean end-to-end slice. #aidevtools

4/ The product spec described “what Table Ready should do”. The real API contract came from the frontend’s WaitlistService interface: one method per operation, with explicit request/response types. That interface, not the spec text, drove the OpenAPI design. #aidevtools

3/ The mocked service layer was more than a way to avoid building the backend. By centralising backend calls, it created a seam where the mock could later be replaced by a real API client without rewriting the UI. #aidevtools

2/ I prepared the Lovable prompt before opening Build mode: frontend only, mocked service layer, no backend, no database, no integrations. That discipline mattered, especially with limited AI-builder credits. Clear constraints are cheaper than rework. #aidevtools

Module 2 of AI Dev Tools Zoomcamp starts with a frontend-first approach. It's not just a UI preference: it's a fast way to test whether the product idea and specification make sense before building the database and API around them. #aidevtools

6/ Splitting a coding task into PM, engineer, and QA roles is really just "don't grade your own homework" applied to agents. Independent verification catches what a single session, however capable, tends to miss. #aidevtools