Moving to the Cloud: Why We Left Squarespace and Vercel for Google Cloud

This is Part 2 of a series on building FuelRoute Pro — from a green methanol spreadsheet to an AI-integrated platform.

• Part 1 — The Spark
• Part 2 — Moving to the Cloud: Why We Left Squarespace and Vercel for Google Cloud (this article)
• Part 3 — The API: From Proof of Concept to Production Platform
• Part 4 — The Interface: Integrating with Claude and the Model Context Protocol
• Part 5 — What’s Next: The Future of FuelRoute Pro [Coming soon]

The first version of FuelRoute Pro worked. A Squarespace site handled the marketing and positioning. A single-page application on Vercel handled the actual calculations. For a proof of concept, it was the right call — fast to deploy, cheap to run, and good enough to validate whether anyone actually needed what we were building.

They did. And that’s when the architecture started to strain.

When “Good Enough” Stops Being Good Enough

The split between Squarespace and Vercel made sense when FuelRoute Pro was a demonstration. Squarespace gave us a polished marketing presence without touching code. Vercel gave us serverless deployment for the app with minimal DevOps overhead. But as the product matured, the seams between these platforms became the problem.

The first issue was data. FuelRoute Pro’s cost calculations depend on fuel pricing data, routing information, and a growing library of cost parameters for different fuel types and transport modes. On Vercel, we were managing this through a combination of API calls and baked-in data — an approach that works until you need to update pricing frequently, store historical calculations, or let multiple services share the same data layer.

The second issue was the backend. What started as a simple calculation endpoint was becoming a proper API with authentication concerns, rate limiting, logging, and the need to integrate with external data sources for real-time fuel pricing. Vercel’s serverless functions are excellent for request-response patterns, but we were outgrowing a model where every function is stateless and isolated.

The third issue was operational. With the marketing site on Squarespace, the app on Vercel, and data scattered across services, every deployment involved coordinating across platforms. Monitoring meant checking three different dashboards. When something went wrong at 2 AM, figuring out where it went wrong was the first challenge.

Why Google Cloud

We evaluated the major cloud providers and landed on Google Cloud for a few specific reasons.

Cloud Run was the biggest draw. We wanted containers — real, portable containers we could run locally for development and deploy to production without rewriting anything — but we didn’t want to manage Kubernetes clusters. Cloud Run gave us container-based deployment with automatic scaling, including scale-to-zero, which matters when you’re a startup watching every dollar. Our backend could handle a burst of route calculations during a client demo and scale back down to nothing overnight.

The data story was the second factor. Cloud Storage for the fuel pricing data we were collecting from public exchanges like the EIA, Nasdaq Data Link, and NREL’s Alternative Fuels Data Center. Firestore or Cloud SQL for structured data. BigQuery waiting in the wings for analytics as the dataset grew. Having all of this in one ecosystem with a unified IAM model simplified the security story enormously.

Security was the third factor. Google Cloud’s IAM model and its security features meant that we could implement a robust security model without having to build it from scratch. Firebase and Firestore would provide a robust authentication and authorization layer that we could add on to secure our application.

The cost story was the fourth factor. We were paying for Squarespace, Vercel, and various data services. Moving to a single cloud provider with pay-as-you-go pricing and scale-to-zero compute could actually reduce our costs while giving us more control and more capabilities. It was a bet that we could get more for less by consolidating.

AI and ML integration was the forward-looking bet. Google Cloud’s Vertex AI and its generative AI services meant that when we were ready to add intelligence to the platform — and we knew we would be — the infrastructure would already be there. We didn’t know exactly what form that would take yet, but we knew that having our compute, data, and AI services in the same cloud would eliminate a category of integration headaches.

The Migration

We took an incremental approach rather than a big-bang migration. The backend moved first — the Express.js API server that handled routing calculations and cost modeling deployed to Cloud Run with Docker, a Cloud Build trigger connected to our GitHub repository, and a CI/CD pipeline through GitHub Actions. Merge into release branch, build the container, deploy to Cloud Run. Simple, repeatable, and identical from dev to production.

The fuel pricing service came next. We’d built a separate Node.js service that pulls pricing data on a schedule from various public exchanges — EIA for diesel and natural gas, Nasdaq Data Link for commodity benchmarks, NREL’s AFDC for hydrogen station pricing, and web scrapers for methanol and ammonia market assessments. This service deployed to its own Cloud Run instance, triggered by a Google Cloud Workflow on a schedule, storing results in Cloud Storage. The pricing data became a shared resource that the main API could query rather than something embedded in the application.

The frontend migration was the final step. The single-page React application moved from Vercel to Cloud Run as well, served as a static build behind the same load balancer. The Squarespace marketing site eventually merged into the main application, giving us a single domain and a unified experience.

What We Gained

The migration wasn’t just about moving boxes around. It fundamentally changed what we could build.

A real data pipeline. Fuel pricing data now flows through a proper pipeline: collection services pull from multiple sources, normalize and transform the data, store it in Cloud Storage with versioning, and make it available to the API through a consistent interface. When a user asks FuelRoute Pro for a cost estimate, the commodity pricing component reflects actual market conditions rather than static assumptions.

Infrastructure as code. Our entire deployment is defined in Terraform — the Cloud Run services, the Cloud Storage buckets, the service accounts and IAM bindings, the Cloud Scheduler triggers. A new engineer can understand the entire system by reading the infrastructure files. More importantly, we can spin up a complete staging environment that’s identical to production with a single command.

Operational clarity. One platform, one set of logs, one monitoring dashboard. Cloud Run’s built-in logging and Cloud Trace give us end-to-end visibility. When a route calculation takes longer than expected, we can trace it from the HTTP request through the routing engine to the database query and back without switching tools.

Cost efficiency. This one surprised us. Despite moving to “enterprise cloud infrastructure,” our monthly costs actually went down compared to the Squarespace plus Vercel setup. Cloud Run’s scale-to-zero means we’re not paying for idle compute. Cloud Storage is pennies per gigabyte. The Squarespace subscription alone was more than our entire Cloud Run bill in a typical month.

Extensibility. Google cloud gives us a rich ecosystem of tools and services. With the backend, data, and frontend all in one cloud, we can now add features that would have been difficult or impossible before. We no longer have to cherry pick from multiple service providers for features we need. We can add a machine learning model to predict fuel prices, integrate with third-party APIs for real-time data, or build a custom analytics dashboard — all within the same ecosystem. The platform is now ready for the next phase of development.

Lessons Learned

If I were advising someone making a similar migration, I’d emphasize a few things.

Start with the backend. The frontend can stay on its existing platform while you migrate the services it depends on. This reduces risk and lets you validate the new infrastructure with real traffic before moving the user-facing layer.

Containerize early. We wrote our Dockerfile before we had a Cloud Run project. Being able to run the exact same container locally and in production eliminated an entire class of “works on my machine” problems.

Don’t underestimate the data migration. Moving code is straightforward. Moving data — especially data with implicit assumptions about file paths, connection strings, and access patterns — takes longer than you think and breaks in ways you don’t expect.

And finally: the migration isn’t the goal. The goal is what the migration enables. In our case, that was the evolution from a single-page web app into a proper API platform — which is where the story gets interesting.

Next in the series: Part 3 — The API: From Proof of Concept to Production Platform

FuelRoute Pro is built by Thampico LLC.