Most startup tech stack articles read like a wishlist. Someone strings together the trendiest tools from Hacker News, writes a Medium post, and calls it a "modern stack." Six months later, half those tools are abandoned, the documentation is three versions behind, and the founding engineer is rewriting everything on a weekend.
This is not that article. This is the exact stack we use at Veld Systems to ship production software, the tools behind products with real users, real payments, and real uptime requirements. Every choice was made for the same reason: it is boring, and boring works.
TypeScript Everywhere
TypeScript is the single highest leverage decision in our stack. Not because it is trendy, it has been around since 2012, but because it eliminates an entire class of bugs before your code ever runs.
When your frontend, backend, API layer, and database queries all share the same type definitions, you catch mismatches at compile time instead of in production. Rename a field in your database schema and TypeScript immediately shows you every file that references the old name. Ship a new API response shape and the frontend throws a build error before anyone pushes to main.
The practical benefit is even simpler than that: onboarding is faster. A new developer can read a TypeScript interface and understand exactly what data flows through the system. No guessing whether `user.name` is a string or might be null. No runtime surprises from a field that used to exist but got removed three sprints ago.
When we built GameLootBoxes, a provably fair loot box platform that has processed 50K+ openings, TypeScript caught dozens of type mismatches between the real time WebSocket layer and the animation renderer during development. Bugs that would have shown up as broken animations in production were compile errors instead. That matters when your users are watching a live loot box reveal and expecting sub 100ms responsiveness.
Next.js for the Frontend
We use Next.js for most web projects, and the reason is pragmatic: it handles the things you would otherwise spend weeks building yourself.
Server side rendering means your pages are indexable by search engines out of the box. No "wait for JavaScript to load" blank screens. No hydration flash. For any product where organic traffic matters, and it should matter to every startup, this is non negotiable.
File based routing means your URL structure mirrors your file structure. No router configuration files. No debugging why `/dashboard/settings` returns a 404. New pages are new files.
API routes let you build simple backend endpoints without spinning up a separate server. Webhook handlers, form submissions, server side API calls, they all live in the same codebase and deploy to the same infrastructure.
We do not pretend Next.js is the answer to everything. For heavy real time applications, think live dashboards with thousands of concurrent WebSocket connections, we will reach for Vite with React instead. Next.js's server rendering model adds overhead you do not need when every interaction is client side anyway. GameLootBoxes used a React SPA for exactly this reason: the entire UI was real time WebSocket driven animations, and server rendering would have added complexity with zero benefit.
The point is knowing when to break the rule, not blindly following it. Our real time architecture guide covers WebSockets, SSE, and polling in detail.
Supabase for the Backend
Supabase is PostgreSQL with batteries included: authentication, real time subscriptions, Row Level Security, Edge Functions, and file storage. We chose it over Firebase for three reasons.
First, PostgreSQL. Your data layer is the hardest part of your stack to migrate. Building on PostgreSQL means your data lives in the most battle tested relational database on earth,see our Supabase vs Firebase comparison for why this matters. If you ever outgrow Supabase, you take your schema, your data, and your queries to any PostgreSQL host. Try migrating off Firestore, you will be rewriting your entire data access layer.
Second, Row Level Security. RLS lets you define access rules at the database level, not in your application code. Forget to add an authorization check in your API? Does not matter, the database will not return data the user is not allowed to see. It is defense in depth, and it has saved us from shipping access control bugs more than once.
Third, real time without infrastructure. Supabase's real time subscriptions are built on PostgreSQL's `LISTEN/NOTIFY`. Subscribe to changes on a table and your UI updates instantly. No Redis. No message queue. No WebSocket server to deploy and scale.
For GameLootBoxes, PostgreSQL was the backbone of the provably fair algorithm, server side seed generation, cryptographic hashing, and verifiable randomness all running in SQL functions. The provably fair system needed transactional guarantees that a NoSQL database simply cannot provide. When real money is involved and users can mathematically verify every outcome, you need ACID compliance, not eventual consistency. We have written about why these foundational choices matter, choosing the wrong database is an architecture mistake that compounds forever.
The Pieces Most People Forget
The glamorous parts of a tech stack get all the attention. The infrastructure that actually keeps products running is invisible, and that is the point.
Stripe for payments. We have integrated Stripe on every project that handles money, including GameLootBoxes and Traderly. Webhook driven fulfillment, subscription management, dispute handling, Stripe has spent billions of dollars solving these problems. Rolling your own payment system is engineering malpractice.
Resend for email. Transactional emails, onboarding sequences, receipts. Resend has a clean API, excellent deliverability, and costs almost nothing at startup scale. We stopped fighting email infrastructure years ago.
Sentry for error tracking. If a user hits an error in production, we know about it before they do. Stack traces, breadcrumbs, release tracking. Sentry turns "the app is broken" into "line 247 of checkout.ts threw a null reference at 3:42 PM."
Vercel for hosting. Automatic preview deployments on every PR. Production deploys on merge. Edge network distribution. Zero downtime rollbacks. We covered this in detail in our CI/CD pipeline guide, the short version is that Vercel makes deployment boring, and boring deployment is the best kind.
These are not exciting choices. They are load bearing ones. Skip any of them and you are either reinventing something that already exists or flying blind when things break. For specifics on optimizing your site's performance once the stack is in place, we have a separate guide.
When We Break Our Own Rules
Intellectual honesty matters more than brand consistency. This stack is not always the right answer.
ML heavy workloads → Python. If you are training models, running inference pipelines, or doing heavy data processing, Python's ecosystem (PyTorch, scikit-learn, pandas) is unmatched. We will build the ML pipeline in Python and connect it to the TypeScript application via API. Using JavaScript for machine learning because "we are a TypeScript shop" would be dogmatic and stupid.
Legacy enterprise integration → Java or .NET. If your client's entire infrastructure runs on .NET and their team maintains it in C#, we are not going to hand them a TypeScript codebase. Meeting organizations where they are is more important than stack purity.
Simple marketing site → WordPress or even static HTML. Not everything needs React. A 5-page marketing site with a contact form does not need a build step, a component library, or a deployment pipeline. Sometimes the right tech stack is a $20/month WordPress install and a page builder. Recommending a $30K custom build for a brochure site would be dishonest.
The right stack depends on the problem. Ours happens to be right for the problems we solve most often: production web applications with real users, real data, and real revenue.
Build With a Stack That Ships
Technology choices are strategy decisions disguised as technical ones. The wrong stack does not just slow you down, it determines what you can build, how fast you can hire, and how expensive mistakes are to fix.
We have refined this stack across dozens of projects because it optimizes for the thing that actually matters: shipping reliable software fast. Not conference talks, not blog post clout, not resume driven development. Shipping.
If you are starting a project and want a team that has already solved the infrastructure problems,tell us about it →