The 2026 SaaS Stack We Actually Ship On

The SaaS stack conversation has become noise. Everyone’s list looks like a screenshot of their open browser tabs. We’re going to tell you what we actually use when we’re shipping products for Australian founders-the decisions we make, the ones we regret, and what we’ve killed off entirely.

We ship MVPs in 28 days. That constraint changes everything about tooling decisions. Speed matters. Reliability matters more. Vendor lock-in matters a lot when you’re moving fast and your product is still figuring out what it wants to be.

The Backend Layer: Not Everything Deserves Kubernetes

We’ve moved away from the complexity-for-complexity’s-sake approach. Most of our early-stage builds run on either Vercel (for full-stack Node/React work) or Railway for anything that needs more control without the ops burden.

For a 28-day ship, managed platforms beat bare metal. You’re paying roughly 2-3x what raw infrastructure costs, but you’re not paying an engineer to babysit deployments at 2 AM. The maths works when your time is worth AUD 100+ per hour.

We’ll use AWS Lambda for specific workloads-usually async jobs or scheduled tasks that don’t need to run constantly. It’s cheap per invocation, and it integrates cleanly with the rest of the AWS ecosystem if you’re already there. But we’re not building entire applications on it anymore.

Database choice is simpler than it was. PostgreSQL for relational data, full stop. If you’re a founder and you’re considering something else for your startup MVP, stop. PostgreSQL has 30 years of battle-hardening, an enormous community, and it runs everywhere. We host it on Railway, AWS RDS, or Fly.io depending on the project. Picking the database manager is less important than picking a database.

Redis goes in when caching starts to matter, not before. That’s usually after your first performance test, not during architecture design.

Frontend: React Is Still the Default, But With Boundaries

React dominates because it’s boring in the right way. The ecosystem is mature enough that you’re not rewriting your router library every 18 months. We use Next.js for most projects because it handles the server/client boundary pragmatically and includes routing, static generation, and API routes in one package.

We’ve stopped reaching for Tailwind on every project. It’s brilliant for speed when you’re building alone or in a very small team. For larger interfaces where design consistency matters, we use a combination of Tailwind for utility work and a light component library (usually shadcn/ui or Headless UI) for structured components. This keeps us from CSS-in-JS complexity while avoiding the “everything looks like Tailwind” aesthetic trap.

TypeScript is mandatory. Not because it prevents all bugs-it doesn’t-but because it’s the difference between a codebase that’s navigable at 4 weeks versus one that’s chaotic at 4 months. The time cost of setting it up is paid back in the first sprint.

AI and Automation: Where the Leverage Actually Lives

This is where 2026 is different from 2024. We’re integrating LLM APIs (OpenAI, Anthropic Claude, sometimes Groq for speed) as standard features, not experiments.

The stack looks like this:

1. LLM API calls (usually Claude for reasoning, GPT-4o for reliability)
2. Vector database for retrieval-augmented generation (we use Pinecone or Supabase’s pgvector)
3. Prompt management and testing (we’ve moved from janky string templates to structured tools like Anthropic’s Workbench or LangSmith, depending on complexity)
4. Job queue for async processing (Bull on Node, Celery on Python)

The mistake founders make is treating AI as a feature to bolt on. The question isn’t “should we add AI?” It’s “where does AI actually reduce friction or cost in our specific problem?” A customer support bot that hallucinates is worse than no bot. Content generation for a B2B SaaS that needs to be accurate is different from content generation for marketing copy.

We budget for at least two iterations on any AI feature. The first draft never works well enough to ship to real users.

Data and Analytics: Only What You’ll Actually Use

We see founders spend thousands on analytics tools they check once a month. That’s money that should go toward product development.

Here’s what we implement:

• Basic event tracking (Posthog or Mixpanel) for feature adoption-essential for knowing what people actually use
• Server-side error tracking (Sentry) so you know when things break before customers tell you
• Simple funnel analysis, not elaborate dashboards
• SQL access to your data warehouse if you’re past MVP stage

We skip Datadog, NewRelic, and enterprise APM tools until you have a scaling problem that justifies the cost. That’s usually not month one.

Amplitude and Heap are overbuilt for most early-stage products. You don’t need retroactive event capture. You need to know: Did people sign up? Did they use the core feature? Did they come back? Posthog answers all three with a free tier that’ll cover you for the first 50,000 events per month.

The Tools We Actually Cut

This matters as much as what we’ve kept. We’ve stopped using:

• Webpack in favour of Vite (faster builds, saner config)
• GraphQL for most projects (REST + TypeScript is faster to ship and debug than the GraphQL indirection layer)
• Micro-service architecture at startup stage (one well-designed monolith ships faster than six services glued together with uncertainty)
• Docker Compose for local development unless the project genuinely needs distributed services locally
• Premium email delivery services unless deliverability testing shows it matters (SendGrid/Mailgun for <AUD 20-50/month solves it for most products)

The pattern is: we remove complexity that doesn’t directly enable faster shipping or better product quality.

How This Comes Together

A typical 28-day build for us looks like: Next.js frontend, PostgreSQL on Railway, Vercel for deployment, Claude API for any AI work, Posthog for analytics, Sentry for errors, and Stripe for payments if it’s commercial. That’s six paid services. Total cost: roughly AUD 200-500 for the first month before any scaling charges hit.

We’re not trying to be clever. We’re trying to get working software in front of real users as fast as possible so you can learn what actually matters.

The tooling conversation matters less than the decision-making discipline: choose tools that save you time *right now*, not tools that might save you time in an imaginary future at 10x scale. You’re not at scale yet. Optimize for shipping, measure what matters, and change your mind when the data tells you to.

If you’re building a product and you’re trying to decide what to build on, or you want to talk through the technical decisions, talk to Amora about your build. We spend our days making these calls, and we’d rather you got them right than guess.