The initial phase of the project was marked by slow communication and a lack of visible progress.

Despite providing full designs, an existing repository, hosting (Supabase/Vercel), API keys, and a working foundation, the project was effectively rebuilt from scratch. This was not clearly communicated at the outset, and I did not fully appreciate that this approach would render much of the existing setup redundant.

As a result, when I checked progress during development, I was frequently met with non-functional builds. Pages often had missing buttons, incomplete layouts, and little to no working functionality. This made it difficult to assess progress and created a recurring sense that the project was not moving forward in a structured or usable way.

Overall, the early stages lacked clarity, continuity, and working checkpoints, which led to frustration and reduced confidence in the development process.

We are now approaching 12 weeks into a project that originally had a clearly defined 6–8 week delivery timeline.

The expectation from the outset was a slick, AI-focused MVP built on the existing infrastructure I had already set up. I provided full designs, along with access to Supabase, Vercel, and GitHub (including API integrations), with the intention of building and iterating quickly on a lean, modern stack.

What was not made clear at the beginning was the impact of the single line in the agreement referencing “Backend: Laravel.” In practice, this has resulted in a complete architectural shift to a traditional server-based system that:

* Requires an always-on backend (Compute Engine or equivalent)
* Relies on a managed SQL instance rather than a usage-based database
* Introduces ongoing DevOps and maintenance overhead
* Carries a baseline running cost of approximately $100–$150/month before any users

These implications were not communicated upfront.

Most importantly, it was not made clear that:

* The existing Supabase/Vercel-based structure would effectively be abandoned
* The new architecture would significantly increase both cost and complexity at the MVP stage
* Reverting or pivoting back to a lighter-weight setup would not be straightforward

This has resulted in a solution that feels misaligned with the original goal of delivering a fast, lean MVP for validation.

At this stage of product development, simplicity, speed of iteration, and minimal fixed cost are critical. The current implementation introduces infrastructure and operational overhead that is typically associated with a more mature, scaled product rather than an early-stage MVP.

Greater transparency around these architectural decisions and their implications would have materially impacted the direction taken at the start of the project.