Background
TypeScript became part of my workflow at KnausDev as the projects I delivered grew in complexity. When you’re building multi-tenant SaaS platforms, API layers, and Vue 3 frontends for clients like E-wire and Dadooo.ai, the type system stops being overhead and starts being the thing that keeps a growing codebase manageable. Every JavaScript project I ship today runs through TypeScript.
From optional to standard
The shift happened gradually. Early on I used JavaScript for everything and treated TypeScript as a nice-to-have. But once I started building systems where multiple engineers touched the same API contracts, or where a frontend consumed dozens of endpoints, the type safety paid for itself immediately catching integration bugs at compile time instead of in production. Now it’s the default for every new project at KnausDev.
How I Use It
TypeScript is the typed layer that sits across my entire JavaScript stack. On the frontend, it powers Vue 3 component interfaces for client projects like E-wire, Exlink, and Dadooo.ai. For content-driven sites, it defines Astro content collection schemas and SSR endpoints, including this site.
What I build with TypeScript
- Vue 3 frontends: typed component props, composables, and state management for enterprise UIs
- Astro sites: content collection schemas, typed API routes, and component props
- API contracts: shared type definitions between frontend and backend, Zod validation schemas
- AI integration pipelines: typed LLM response parsing and data transformation layers
- Build tooling: Vite configs, custom plugins, and CI/CD scripts
TypeScript is particularly valuable on the platform engineering and product development projects I deliver, where the codebase needs to stay maintainable over months of iteration.
Status
Active: default language layer across all JavaScript-based projects.