More of our customers are reaching for platforms like Supabase and Vercel to accelerate their development. We specialise in AWS, so the natural instinct might be to stay in our lane. But that is not how we operate. When customers adopt new tools, we want to understand those tools well enough to provide real guidance - not just point to the AWS alternative and move on. So for this Hack Day, we set the team a challenge: go build something on these platforms, experience the developer workflow firsthand, and come back with honest observations about where they shine, where they fall short, and what it all means for the hybrid stacks we increasingly support.
Reading documentation only gets you so far. To properly evaluate these platforms, we needed to push them harder than a tutorial ever would.
We kicked off with a practical tool - a PaaS Navigator designed to help teams evaluate when Supabase and Vercel make sense versus AWS-native services. It included a service comparison matrix, a decision wizard with weighted scoring, and a cost calculator. The app used Supabase Auth with magic link sign-in, Edge Functions for server-side logic, and Row-Level Security across all tables. Building it exercised a broad surface area of the platform, and it worked as advertised.
But the real stress test came from an unexpected direction: multiplayer games. The thinking was that real-time multiplayer is one of the hardest problems you can throw at a backend, so if Supabase Realtime can handle game state synchronisation, it can probably handle most application workloads.
The first attempt was a turn-based artillery game with destructible terrain and ballistic physics for 2-4 players. Supabase Realtime handled the state sync between players without needing a dedicated game server. That worked well enough to justify going further.
By the end of the day, the team had built a competitive real-time tower defense game - two players, six tower types with distinct behaviours, five drone variants, A* pathfinding, procedurally generated maps, and a drone factory mechanic. All game state was synchronised through Supabase Realtime broadcast channels. The game included a leaderboard backed by Supabase's database with RLS (public read, insert-only - trivial to set up), an achievement system, and procedural audio generated entirely through the Web Audio API with zero asset files.
The fact that a real-time multiplayer game of this complexity could be built and deployed in a single day - with Supabase handling all the backend concerns - says something meaningful about what these platforms can do. The deploy cycle from local to live on Vercel was around 35 seconds via Docker and the CLI, which kept the feedback loop tight throughout the day.
Another experiment tackled a question that often comes up when teams adopt PaaS tools: what happens when you outgrow the platform, or when you need to bring the deployment pipeline under your own control?
To test that, we took an existing app built with Lovable (another PaaS tool in the rapid-development space) and migrated it to Vercel with a managed Supabase backend. The migration involved adding a vercel.json configuration with a Nitro preset, overriding output paths, setting up a Dockerfile, creating a GitHub Actions workflow for CI/CD, and writing Supabase migration scripts.
The takeaway was that migration is possible, but it is not seamless. PaaS platforms optimise for their own deployment paths, and pulling an app out of one ecosystem into another requires understanding the build and configuration layers that the platform normally abstracts away. This is exactly the kind of work where having an infrastructure partner who understands both sides of the stack adds value.
The most operationally interesting project was a hybrid disaster recovery demo. The setup used Supabase as the primary database for a ticket management application, with changes replicating continuously to DynamoDB in AWS. A Vercel-hosted application managed the replication pipeline.
This is the pattern we expect to see more of. Customers will not wholesale abandon AWS for PaaS platforms, nor should they. What they will do is use Supabase for rapid application-layer development while keeping critical data replicated into AWS services they already operate and monitor. The question for us is not "PaaS or AWS" but "how do we make the hybrid work reliably?" The demo proved that continuous replication between Supabase and DynamoDB is achievable and gave us a reference architecture to build on.
We came into this Hack Day knowing what these platforms offered on paper. The point was to get hands-on and form our own opinions. What we confirmed is that the developer experience is fast - the path from sign-up to deployed application removes a lot of the friction that AWS workflows still carry.
But a good developer experience is not the whole picture. Supabase is still a young platform compared to AWS. The managed services work well for common patterns, but the ecosystem around observability, compliance tooling, fine-grained IAM, and operational maturity is not in the same league. When something goes wrong at 2am, the depth of logging, tracing, and support options you get with AWS services is not something these platforms can match yet. For teams building anything that needs to meet serious operational or regulatory requirements, that gap matters.
Getting onto a PaaS platform is also easier than getting off one. The abstraction layers that make the initial experience so smooth are the same ones that make portability harder down the line. Teams should think about migration paths before they need them, not after.
The most useful framing we came away with is that this is not a PaaS-or-AWS decision. Our customers are layering these platforms on top of existing AWS infrastructure, and the interesting work is in making that hybrid stack reliable - monitoring, disaster recovery, security, and operational support across both worlds. These platforms do real things well, but they are best understood as a complement to AWS, not a replacement for it.
This Hack Day shifted our perspective. Rather than viewing PaaS platforms as competitors to AWS, we now see them as part of the stack our customers are building on. Understanding them firsthand means we can have better conversations, offer more complete support, and help our customers make informed decisions about where each platform fits.
Facing the same PaaS-or-AWS question? Let's talk it through - we've done the homework, so we can bring it straight to your stack.