TypeScript
TypeScript is the default language for everything we ship on the web. The type system pays for itself within weeks: AI-generated code is more reliable when it compiles, refactors don't need an army of test cases to be safe, and onboarding engineers find the code self-documenting. Particularly for AI applications — where we're routinely passing structured data between LLM responses, RAG systems, and downstream automation — end-to-end type safety from the model output to the UI prevents a class of production bugs that JavaScript silently allows. We use strict TypeScript on every project; no `any` smuggled in unless explicitly justified.
What you get
Real examples
Type-safe AI agent with Zod validation
Illustrative scenario: a SaaS embeds an in-product AI assistant with 6 tools. Each tool defined as a TypeScript function with Zod-validated inputs and outputs. The LLM calls return data is validated at the boundary; downstream code is never reached with invalid data. Zero runtime type errors in production over 6 months.
Multi-site monorepo with shared packages
Illustrative scenario: a consultancy operates multiple brand sites with shared services. Turborepo + TypeScript packages provide compile-time guarantees across boundaries. Refactor a shared API client; the compiler flags every dependent site automatically. (This is how the Horizon Labs platform itself is structured.)
Legacy JavaScript modernisation to strict TypeScript
Illustrative scenario: a client has a 5-year-old Node.js codebase with no types. We migrate incrementally — add tsconfig, allow JS files, type the most-critical paths first, expand strict-mode incrementally. Six months in, the codebase is 90% strict TypeScript and the team can refactor confidently for the first time.
Common questions
Why insist on TypeScript over JavaScript?
Three reasons. One, the maintainability gain compounds — refactors are safer, onboarding is faster, AI-generated code is more reliable. Two, AI applications pass structured data through many layers; types catch the boundary errors that silently corrupt data in production JS. Three, the productivity dip during the learning curve is real but short; teams are net-faster within 2-3 months.
Do you use TypeScript on the back-end too?
Yes, almost always. Node.js + TypeScript is our default for application servers (Next.js API routes, standalone services). For data-engineering / ML work we use Python (PyTorch / pandas live there), but anything not in the model layer is TypeScript.
What about strict mode — too strict?
Strict mode is non-negotiable on new projects. On legacy migrations we relax it temporarily and tighten incrementally — fix the lowest-hanging type errors first, then enable progressively stricter rules. Within 6 months a converted codebase usually reaches full strict mode.
How do you handle types for LLM outputs?
Always Zod schemas at the LLM boundary. The Vercel AI SDK's generateObject + a Zod schema gives you compile-time AND runtime type safety on the model's structured output. No JSON.parse + try/catch; if the LLM returns malformed data, the SDK catches it before the application sees it.
Can you upskill our team on TypeScript?
Yes — this is a common part of modernisation engagements. We pair with in-house developers during the migration, write the first few hundred type definitions together, then progressively hand over. Most teams are productive in TypeScript within a month of focused work.
Ready to get started?
Tell us about your project and we'll tell you honestly how we can help.
Get in Touch