Building the best tech stack

Definition of Tech Stack

A tech stack is the collection of technologies, frameworks, libraries, and tools that work together to build and run your application.

For developers, it might mean Turbo, Convex, Next.js, and Tailwind CSS. For marketers, it could be beehiiv and Typefully, along with some attribution software.

Both are valid interpretations, but they serve completely different audiences with different needs. For this wiki, we're focusing primarily on the development stack. The code, frameworks, and infrastructure that make your app tick.

Why you should care

Whether building a weekend side project or enterprise-grade software, the tech stack matters. But, probably not for the reasons most think.

The specific tooling matter less than how thoughtfully fundamental principles of system design are applied.

You can have a cracked developer build unstable applications with cutting-edge tech while another will vibe code a rock-solid system with outdated tools.

The difference?

Understanding system design principles that transcend whatever framework is trending on social media this week. And yeah, we used that word.

As described in Kleppmann's influential work Designing Data-Intensive Applications, successful systems balance several fundamental dimensions that become even more critical in today's AI-powered development landscape.

Foundational principles for modern systems

The best tech stack is built on timeless principles that prioritize long-term stability over short-term convenience. These principles become even more crucial as applications increasingly incorporate AI capabilities:

• Scalability without sacrifice: Systems must handle growth in data volume, traffic, and complexity without degrading performance. Design should focus on clean interfaces between components that allow independent scaling, enabling teams to address bottlenecks without destabilizing the entire system.
• Reliability through redundancy and isolation: Systems should continue working correctly even when things go wrong. With AI agents now executing thousands of operations per second, partial failures are inevitable. Implementing fault isolation, circuit breakers, and timeouts prevents cascading failures.
• Maintainability through simplicity: Systems live far longer than expected and must accommodate changing requirements. When faced with a choice between a clever, complex solution or a straightforward one that's slightly less optimal, simplicity typically proves more valuable in the long run.
• Deterministic guarantees: Modern tech stacks must provide strong guarantees about data consistency and processing outcomes, especially when offloading work to background processes. Even as systems become more distributed and AI-driven, they must maintain deterministic behavior that developers can reason about and trust.
• Data models as foundation: The choice of data representation fundamentally shapes what's possible. Document models offer flexibility for rapid iteration, relational models enforce consistency, and graph models excel at connected data. The rise of AI means data models must support both human and machine consumers with equal effectiveness.

Plan for problems before they happen

In case you can't tell, we're big fanbois of the smart folks over at Convex. This section borrows heavily from their wisdom. We highly recommend every technologist watch this session on their Databased podcast.

1. Prepare for the worst days, not just normal ones: Every system will face heavy traffic, slow responses, and failures. What happens when traffic jumps 10x during a sale? When an API goes down? Good systems bend but don't break. Bad planning leads to "congestion collapse." When too many requests crash a system, users retry, and everything gets worse in a downward spiral.
2. Track how data flows from start to finish: Every part of a system connects to others. Mapping the complete journey of data through your architecture helps spot potential bottlenecks and failure points before they affect users. This end-to-end view reveals dependencies that might not be obvious when examining individual components.
3. Begin with solid rules, then add flexibility later: It's easier to relax strict rules than to add them after launch. Systems should start with strict data validation and reliable transactions. This creates a strong foundation before adding convenience features that might introduce occasional edge cases.
4. Define data before actions: Systems should be built around things like data structures and entities rather than actions. When designing features, clear definitions of the underlying data should precede code to manipulate it. This makes systems more consistent and code more maintainable. State should be the north star. Defining what's being changed before worrying about how it changes.
5. Aim for zero errors in data: Well-designed systems implement verification checks that constantly ensure data accuracy at each step. These checks should compare inputs and outputs to guarantee that transformations maintain data integrity. Such verification mechanisms often catch hidden bugs before users encounter them, saving many hours of troubleshooting.

Architecture principles that stand the test of time

• Single responsibility: Each component should do one thing well. Separating core business logic from authentication and billing makes systems easier to maintain. When something breaks, teams know exactly where to look.
• Extensibility: Systems should be open to extension but closed to modification. Applications built with plugin architectures allow adding new features without changing core code. This approach significantly reduces regression bugs when adding functionality.
• Security: Security must be built in from day one, not added as an afterthought. Authentication, authorization, and data protection systems should be designed with security principles first. The cost of retrofitting security later is always higher than implementing it correctly initially.
• Resilience: Systems should recover gracefully from failures. Design should account for failure at every level, network issues, service outages, unexpected inputs. API interactions built with retry mechanisms and fallbacks prevent cascade failures when dependencies slow down.

And sometimes, the best approach is to just iterate to greatness.

Projects often begin with simple utility modules for basic functionality. As needs grow, these can evolve into more sophisticated components with specialized capabilities.

Although it sounds ironic in the context of this article, do what you can to avoid over-engineering things up front.

Tools are secondary to principles

The reality? Whether a team uses Turbo, Convex, and Tailwind or Tanstack Start, and vanilla CSS doesn't matter nearly as much as how they apply the principles above.

Modern stacks work for teams because they enable efficient work while maintaining important guarantees. But, WordPress powers more than a third of the web, and teams can build perfectly solid systems on that too if they understand the underlying principles.

Here's a checklist for evaluating technologies:

1. Does it solve a real problem the team has?
2. Does it create more problems than it solves?
3. Will it still be maintained in 3 years?
4. Does the team have the skills to use it effectively?
5. Does it integrate well with existing tools?
6. Does it follow the principles the team cares about?

If something passes these tests, it's likely a good fit. Technology choices should be pragmatic. Good engineering is good engineering, regardless of which GitHub repository it comes from.

Future-proofing your stack

The future of software is increasingly agentic. Systems that can act on behalf of users without constant direction. Whether it's AI assisting with content creation or automations that handle routine tasks, modern stacks need to support these capabilities.

Tech stacks should have clear integration points for AI services and the performance characteristics to handle real-time processing. When architecture includes extension points for AI services, teams can integrate capabilities like content optimization without major refactoring.

Before, teams would add AI features as distinct service calls. Now, AI capabilities are woven throughout the entire stack.

Architecture needs to accommodate this shift or teams will be rebuilding from scratch within a year.

Collaborative software development

Modern applications are inherently collaborative. Both between humans and increasingly between humans and AI.

This requires real-time data synchronization, conflict resolution, and sometimes presence awareness.

When evaluating tech stacks, teams should consider how they handle:

• Real-time updates
• Optimistic UI updates with conflict resolution
• Offline-first capabilities where appropriate
• Multi-user editing and permissions

Stacks should make collaboration "just work" instead of becoming a features checklist that requires implementation from scratch.

Evaluating frameworks partially based on their collaboration primitives can save significant development time and headache.

These capabilities are pretty hard to add retroactively.

Evaluating modern frameworks

Backend-as-a-Service (BaaS) options like Convex, Firebase, or Supabase can dramatically simplify stacks by handling data storage, real-time synchronization, and authentication in one package.

They're worth considering if project needs align with their capabilities.

Others, like Next.js, Nuxt, Tanstack Start, and similar meta-frameworks provide sensible defaults and performance optimizations that would take significant effort to build independently.

The "boring" choice is often the right one here.

Velocity and developer experience

Ultimately, the best tech stack lets teams ship valuable features to users with confidence. Developer experience matters because it directly impacts iteration speed.

Choosing tools like Convex for its real-time data model and TypeScript integration can eliminate entire categories of bugs that teams would otherwise need to fix.

Monorepo solutions like Turbo can simplify management without excessive configuration files. Component libraries like shadcn or Tailwind UI save design time so teams can focus on solving actual customer problems.

These choices shouldn't be about trends. They should maximize velocity while maintaining important architectural principles.

The best tech stack for us

At Reply Two, we applied these principles to select a tech stack that considers both developer experience and system reliability:

• Turbo: Saved us from config hell in our monorepo setup
• Convex: Reduced tooling, gave us deterministic certainty, and everything's real-time
• TypeScript: Caught stupid mistakes before they hit production
• Next.js: Handled the boring parts of rendering so we could focus on features
• Sanity: Kept our content structured without driving editors crazy
• Tailwind CSS/UI: Let us build a consistent UI without fighting CSS specificity wars

This combination wasn't chosen because these tools had the best swag or appeared in trending X threads. Each technology solved specific problems we faced while upholding our core architectural principles.

Remember: the best tech stack is the one that lets teams build what matters while sleeping soundly at night, knowing their system can handle whatever tomorrow brings.

Some good resources

Reply Two Tech Stack

Convex on System Design

Ask Claude for help with Tech Stack

Copy and paste this prompt into Claude or the AI of your choice. Be sure to tweak the context for your situation.

<goal>
Help me select a tech stack that balances developer velocity with architectural stability for my specific application needs.
</goal>
<context>
* I'm building a [TYPE OF APPLICATION] (SaaS, e-commerce, content platform, etc.)
* Expected user base of [SIZE] with growth projections of [PERCENTAGE] over the next year
* My team consists of [NUMBER] developers with experience in [TECHNOLOGIES]
* Current pain points include [PAIN POINTS] (data synchronization, deployment complexity, scaling issues)
* We need real-time capabilities: [YES/NO/MAYBE]
* Our application requires collaboration features: [YES/NO/MAYBE]
* Timeline to MVP is [TIMEFRAME]
</context>
<output>
Please provide:
* An evaluation of 3-4 tech stack combinations that would fit my specific needs
* Tradeoffs for each approach (developer experience vs. operational complexity)
* Specific architectural considerations for my application type
* Recommendation on which components to prioritize vs. which can be added later
* Decision framework for evaluating "boring" proven technologies vs. cutting-edge options
</output>
<example>
For a collaborative SaaS application requiring real-time updates:
Option 1: Modern JavaScript Stack

Backend: Convex (provides real-time sync, auth, TypeScript integration)
Frontend: Next.js with shadcn/ui components and Tailwind CSS
Infrastructure: Vercel
Benefits: End-to-end type safety, minimal DevOps, built-in real-time capabilities

Option 2: PHP/JavaScript Hybrid

Backend: Laravel with Livewire
Frontend: Vue.js with FluxUI (the official Livewire component library) and Tailwind CSS
Database: MySQL with websockets for real-time features
Infrastructure: Laravel Cloud
Benefits: Mature ecosystem, extensive documentation, lower learning curve for PHP developers
</example>


<guardrails>
* Focus on architectural principles over specific technologies
* Consider maintainability over the next 3-5 years
* Account for team composition and learning curve
* Evaluate real costs (both financial and operational)
* Consider how each component handles:
  - Scalability without sacrifice
  - Reliability through redundancy
  - Maintainability through simplicity
  - Deterministic guarantees about data
</guardrails>