Avatar

Isaac Levine

Software Engineer

[frontstep.ai] Migrating from Vercel to Railway

What is frontstep.ai?

Frontstep.ai is a platform that allows real estate agents and property managers to qualify new leads on autopilot. It integrates directly with Zillow and upon receiving a new Zillow lead for a property, instantly reaches out to the lead via SMS or Email, and qualifies them through natural back and forth conversation, based on the qualification questions that the realtor has configured for the property or for their team. It automatically detects when qualification questions have been answered, checks them off, and notifies the realtor when all qualification questions have been answered, and the lead is ready for a showing.

Starting Point

I built frontstep.ai with the now-classic Vercel, Next.js, and TypeScript stack. I chose this stack mainly because of how easy the development experience is, and without too much concern because I still didn't know exactly what I wanted frontstep.ai to be.

  • frontstep is an extremely low traffic (for now) app but with an actual pretty low latency expectation (real-time)

Limitation

Where things started to break down was live chat.

WebSockets don’t play well with serverless:

  • Cold starts add unpredictable latency
  • Connections can drop because there’s no persistent server to “own” the state
  • Maintaining a long-lived, bidirectional channel between client and server is basically impossible

I thought about faking it with polling, but that would have been wasteful and still not instant, especially with the low traffic that we have now.

Decision

So, I decided to migrate from Vercel to Railway.

The frontend stack (Next.js, TypeScript, Tailwind) stayed exactly the same, but the backend shifted from ephemeral, stateless functions to a server that I control. That gave me:

  • Stable WebSocket connections that don’t die after a few minutes
  • Lower latency and more predictable performance
  • A much easier time building features like presence indicators, typing indicators, and reliable message delivery

On top of that, moving to a serverful architecture has also been a better fit for the growing number of webhook integrations we’ve been adding (Zillow, CRMs, calendars, etc). With serverless, handling these webhooks meant unpredictable cold starts and scaling issues, which could cause dropped or delayed events. With a persistent server on the other hand, webhooks land immediately, get processed reliably, and can maintain context between related events (e.g. several new messages come in within a few minutes from the same conversation).

Lesson Learned

Serverless is great. Vercel makes it insanely easy to get something live fast, and I think that’s a huge win for anyone testing an idea. For early prototypes or apps that don’t need real-time connections, it’s pretty much perfect. Even this website is a NextJS app deployed to Vercel.

But I also think a lot of people (myself included) reach for serverless by default when they don’t really need it. Most apps don’t need global edge deployments or scale-to-zero functions. A basic server often does the job just fine, and it’s usually simpler to run and reason about, especially when you're just starting out and the cost differences are negligible.

For frontstep.ai, starting on Vercel helped me move quickly at the beginning, but long-term, running on Railway makes more sense.