When people ask what makes building an AI product difficult, the answer is usually model latency, hallucination, or keeping vector databases fast. Those are real problems, but they are predictable engineering problems. You can write tests for them, profile code, and tune your prompts.
On SolutionPath, an automated publishing SaaS I built from scratch, the hardest part of the entire project had nothing to do with AI. The core application logic and translation pipelines took about six weeks to build. Getting Google Cloud to approve our OAuth scopes took almost three months.
The product itself was designed to solve a specific publishing challenge: taking structured chapter outlines and turning them into complete, multi-language books. Writers and content creators often keep their outlines, character notes, and chapter summaries inside Google Sheets. Asking them to manually copy and paste hundreds of rows into a web form is a terrible user experience, so the entire workflow was designed around Google Workspace.
A user would sign in with their Google account and paste a link to an outline in Google Sheets. The backend parsed the spreadsheet dynamically, pulling out chapter titles, scene beats, tone guidelines, and word counts. Through a React and Vite interface, the author could choose which chapters to run, assign specific writer personas, set length targets, and pick anywhere from one to eight target languages.
Generating a full book takes time. If you run that over standard HTTP requests, the connection will drop long before the first chapter finishes.
To keep the system reliable, I set up FastAPI with Celery workers backed by Redis and PostgreSQL. When a user started generation, the outline and configuration were stored in the database, and the generation job was handed off to Celery in the background. The engine generated the book chapter by chapter in the primary language first, running structured prompts against OpenAI models. Once the primary text was ready, the system spawned parallel background jobs to translate the chapters across all selected secondary languages.
Throughout the run, the frontend streamed live status updates so the author could watch chapters finish in real time. Once everything was complete, the user could export the formatted chapters directly as new Google Docs inside their own Google Drive account.
Architecturally, everything worked cleanly. I containerized the services with Docker, set up migrations with Alembic, and verified that jobs recovered gracefully if an external API call failed.
Then we submitted the application for Google Cloud OAuth verification.
Because the app needed to read a user's Google Sheet and write newly generated Google Docs, we had to request restricted Google Drive scopes. If you only build tools for internal company accounts, Google does not ask many questions. But if you want any public user with a Gmail or Google Workspace account to log in without seeing terrifying security warning screens, you must pass Google's Trust & Safety review.
Google's review team insisted that we drop our requested permissions and use the more restrictive drive.file scope instead. On paper, that recommendation sounds reasonable. In practice, it completely broke how the app was designed to work.
The drive.file scope only grants access to files that your specific application created, or files opened through Google's native file picker modal. It does not allow an application backend to open an existing Google Sheet that a user simply links from their Drive. If we had complied with their initial demand, users would not have been able to paste their outline links, which was the entire foundation of the product.
Resolving this turned into a multi-month back-and-forth process. I had to map out every single data boundary in the system, write technical compliance documentation explaining why narrower scopes were technically impossible for our use case, and record screen walkthroughs demonstrating how user data was handled and discarded after processing.
Every revision took days to hear back on. You wait, receive a canned response asking for clarification, explain the architectural necessity again with clearer diagrams and videos, and wait again.
Eventually, our justification was accepted, and Google granted full production verification for our required scopes. We deployed the stack onto a Linux VPS behind Nginx, configured SSL and DNS, and launched without security warning screens blocking users at the door.
Building the AI pipeline was the exciting part of the project, but getting through verification was the real test. When you build software that connects to major platforms, platform compliance is not an afterthought you deal with on launch day. It is an architectural constraint that can shape your timeline more than your code ever will.