The Apptitude Stack: Tools and Frameworks We Actually Use to Build Apps

No Buzzwords. Just the Actual Tools.

Every agency has a "tech stack" page that reads like a buzzword bingo card. We'd rather just show you exactly what we use and why. These are the real tools and frameworks behind the 100+ products we've shipped since 2012 — not aspirational choices, but battle-tested decisions refined over 14 years of production experience.

Frontend: React Native and Astro

Mobile Apps: React Native

We build mobile apps with React Native. Not Flutter, not native Swift/Kotlin, not some cross-platform framework du jour. Here's why:

• One codebase, two platforms. We ship iOS and Android from the same TypeScript codebase. For most apps, this cuts development time by 35–40% compared to building native for each platform.
• Production-proven at scale. React Native powers apps at Meta, Microsoft, Shopify, and Discord. It's not experimental — it's the industry standard for cross-platform mobile.
• Huge ecosystem. When a client needs push notifications, biometric auth, camera access, or offline storage, there's a mature library for it. We're not writing native bridges from scratch.
• Developer availability. When our clients build internal teams post-launch, finding React Native developers is straightforward. Finding Flutter developers or maintaining separate iOS and Android teams is harder and more expensive.

We use Expo as our React Native framework for most projects. It handles builds, OTA updates, and a ton of device API integrations out of the box. The days of wrestling with Xcode and Gradle for every build are mostly behind us.

When we don't use React Native: Apps that require intense 3D rendering, real-time audio processing, or deep hardware integration sometimes need native development. We'll tell you upfront if that's the case.

Marketing Sites and Web Apps: Astro

Our marketing site (the one you're reading right now) runs on Astro 5. We also use it for client projects that need fast, SEO-optimized web presence.

Why Astro over Next.js or Remix:

• Zero JavaScript by default. Astro ships pure HTML and CSS unless you explicitly opt into client-side JS. This site scores 100 on Lighthouse performance because there's almost nothing to download.
• Framework-agnostic. Need a React component for an interactive widget? Drop it in. Need the rest of the page to be static HTML? Done. Astro doesn't force you into a single rendering paradigm.
• Content-first architecture. For marketing sites, blogs, and documentation, Astro's content collections and Markdown support are exactly what you need without the overhead of a full React framework.

For complex web applications with heavy client-side interactivity, we use React with Vite. But for most marketing and content sites, Astro is the right tool.

Styling: Tailwind CSS

We use Tailwind CSS 3 for virtually every project. This isn't controversial anymore — Tailwind won. But here's specifically why it works for an agency:

• Consistency across projects. Every Apptitude project uses the same utility-class approach. When an engineer moves between client projects, there's zero ramp-up time on styling conventions.
• Design-to-code speed. Translating a Figma design into Tailwind classes is dramatically faster than writing custom CSS. A component that takes 45 minutes in traditional CSS takes 15 minutes in Tailwind.
• Small bundle sizes. Tailwind purges unused styles at build time. Our production CSS files are typically 15–25KB.

Backend: TypeScript Lambda on AWS

Our API architecture is opinionated and intentionally simple.

Language: TypeScript

We write everything in TypeScript — frontend, backend, infrastructure. One language across the entire stack means:

• Engineers can work on any part of the system without context-switching languages
• Shared types between frontend and backend eliminate a whole category of bugs
• Hiring is simpler — we need TypeScript engineers, not TypeScript + Python + Go engineers

Runtime: AWS Lambda

Our API runs on AWS Lambda with a vanilla TypeScript router — no Express, no Fastify, no framework. Just a handler function that pattern-matches routes.

Why no framework:

• Lambda functions have a different lifecycle than long-running servers. Express middleware patterns add overhead that doesn't make sense in a serverless context.
• Our router is about 100 lines of code. It handles routing, CORS, and error responses. There's nothing to update, nothing to patch, nothing that breaks with dependency conflicts.
• Cold starts are faster without framework initialization overhead.

We use Zod for request validation. Every incoming request is validated against a schema before the handler runs. This catches malformed data at the edge and produces clear error messages.

Database: PostgreSQL

We use PostgreSQL for every project that needs a relational database, which is nearly all of them. Not MySQL, not MongoDB, not DynamoDB.

• JSON support. Postgres handles JSON columns natively, which gives us document-style flexibility when we need it without giving up relational integrity.
• Full-text search. For most apps, Postgres's built-in full-text search eliminates the need for Elasticsearch or Algolia.
• Reliability. Postgres doesn't lose data. It doesn't have weird eventual consistency gotchas. It does exactly what you expect, every time.

We use the pg driver directly with typed queries — no ORM. ORMs add abstraction that makes simple queries verbose and complex queries impossible. Raw SQL with TypeScript types gives us full control and full type safety.

Email: Resend

Transactional email goes through Resend. Simple API, great deliverability, reasonable pricing. We switched from SendGrid in 2024 and haven't looked back.

Infrastructure: AWS CDK

Our infrastructure is defined in code using AWS CDK 2 with TypeScript. Every resource — API Gateway, Lambda functions, Cognito user pools, Secrets Manager entries — is defined in a CDK stack.

Why CDK over Terraform or Pulumi:

• Same language. CDK uses TypeScript, so our infrastructure code is in the same language as our application code. No HCL to learn, no YAML to debug.
• AWS-native. We're all-in on AWS. CDK has first-class support for every AWS service with sensible defaults and type-checked configurations.
• Construct library. CDK's higher-level constructs handle security best practices (IAM roles, encryption, VPC configuration) by default. You have to actively opt out of security, not opt in.

Our typical infrastructure stack includes:

• API Gateway — HTTP API with custom domain and CORS configuration
• Lambda — Node 22 runtime, ARM64 architecture for cost savings
• Cognito — User authentication when the app needs user accounts
• Secrets Manager — Database credentials, API keys, and other sensitive configuration
• RDS or Aurora — Managed PostgreSQL with automated backups

Hosting and Deployment

• Web apps: Netlify for static sites and Astro projects. Git-push deploys, automatic preview deployments for PRs, and edge caching.
• APIs: AWS via CDK deploy. We run separate dev, staging, and production environments.
• Mobile apps: Expo EAS for iOS and Android builds. OTA updates for JavaScript changes, app store submissions for native changes.

Development Workflow

• Version control: Git with GitHub. Feature branches, pull request reviews, and linear commit history.
• Package management: npm with workspaces for monorepo projects.
• Code quality: TypeScript strict mode, astro check for web projects, and automated type checking in CI.
• AI-assisted development: We use AI coding assistants daily for code generation, review, and documentation. This isn't a gimmick — it genuinely accelerates development by 20–30% for routine tasks.

Why This Stack Works for Clients

The boring answer is that this stack works because it's boring. There's nothing experimental here. Every tool has been in production across multiple client projects for years. When something breaks at 2 AM, we know exactly where to look and how to fix it.

The practical answer is that this stack is fast to build with, cheap to run, and easy to hand off. When a client's project graduates from our team to their internal engineering team, they inherit a codebase built on mainstream, well-documented technologies that any competent TypeScript developer can maintain.

That's the real test of a tech stack: not how impressive it sounds on a capabilities slide, but how easy it is for the next team to pick up and run with.