TypeScript development services
TypeScript development that treats the type system as architecture, not decoration
· Average time to first merged PR: 12 to 15 days
Plenty of teams have TypeScript in their repo. Fewer actually use it. What you usually inherit is a wall of any, a tsconfig with strict mode disabled “for now”, and three developers quietly arguing about whether runtime validation belongs in the handler or the schema.
Siblings Software is a small Argentine firm that has been staffing TypeScript product teams since the language stopped being a curiosity. This page is written for the person comparing vendors: what the work actually looks like, what it costs, what we do well, and the situations where we would tell you to hire someone else.
Who actually hires a TypeScript team from us
Four buyer profiles account for most of our TypeScript engagements.
Product teams whose JavaScript codebase has outgrown itself
Two or three years in, the app works but nobody wants to touch the checkout. Refactors break in production. Onboarding a new engineer takes six weeks because the data shapes only live in someone’s head. You want TypeScript, and you want it without pausing the roadmap for a quarter.
Startups that want to start in strict TypeScript from day one
Seed or Series A. A designer, a rough API spec, a founder who has read enough post-mortems to know that “we’ll add types later” is a lie. You want a squad that will ship a Next.js product with Zod at the boundary, branded IDs, and a Storybook that stays in sync. You do not want to argue about what strict mode should be set to.
Scale-ups replacing a risky in-house framework
A custom Node framework from 2019 that three people understand. A front end stuck on an old Angular version. Leadership wants to stop the bleeding without a rewrite. You want TypeScript engineers who can introduce NestJS or Fastify at the edges, generate typed clients from the old API, and let new code be strict while the legacy keeps printing money.
Enterprises consolidating a fragmented JavaScript estate
Four internal applications, three of them JavaScript, one of them CoffeeScript somehow. A platform team that wants a single source of truth for types, tokens and API clients. You want a TypeScript squad that can stand up a Turbo or Nx monorepo, publish shared type packages, and give the other teams a reason to opt in instead of a memo telling them to.
If none of those describe you, we will still take the call, and say so in the first fifteen minutes if we are not the right fit.
What TypeScript engineers do day-to-day
Most service pages stop at “we do React and Node.” That is not useful if you are trying to decide whether to hire a team. The scope below is what a typical TypeScript engineer works on in a given sprint. The mix shifts per engagement, but rarely is it fewer than four of these areas.
Product surfaces in React, Next.js, Angular or Vue
Dashboards, onboarding, admin consoles, billing flows. Server components where they make the cost model better, not because the conference talk said so. Typed form state with React Hook Form plus Zod resolvers, typed routing, proper suspense boundaries. The component library is typed so that the wrong prop combination stops being a runtime surprise.
Node.js back end with types that survive the JSON boundary
NestJS, Fastify, Hono or plain Express depending on what the team already runs. Zod or Valibot at every boundary. Typed database access with Prisma or Drizzle. Queue consumers with discriminated-union message types so the compiler refuses to let you forget a case. The goal is that once the types compile, you can trust the runtime.
Type architecture that models the domain, not the database
Branded types for IDs, discriminated unions for state, literal-union enums instead of the other kind, generics used sparingly and with constraints. We lean on the official TypeScript handbook as common ground during reviews, and we write the architecture down so the next engineer does not have to reverse-engineer it from the call site.
Typed design system and component library
Design tokens as a typed package, component variants with literal unions, Storybook stories that double as type regression tests, and codemods for breaking changes. The boring governance part — deprecation notices, migration guides, accessibility lint rules — gets done on schedule, not when someone finally complains.
Testing and CI with type checks on equal footing
Vitest or Jest for unit, Playwright for end-to-end, tsc --noEmit as a first-class CI gate. ESLint with typescript-eslint strict rules, no-any configured, and Turbo remote caching so the pipeline does not become a punishment. The test suite knows the types; the types know the test fixtures.
Migration from JavaScript without freezing the roadmap
We do not pitch rewrites. We land tsconfig with allowJs and checkJs, enable strict mode one package at a time, and push features in parallel. By the time the migration is “done”, most of the product team has forgotten it was happening. Details are in the migration path section below.
Every senior we place has shipped at least one TypeScript codebase from scratch and migrated at least one JavaScript project into strict mode. Most have both, across SaaS, fintech, health and retail.
Engagement models and what they cost
We publish ranges because hidden pricing wastes everyone’s time. The final number depends on seniority mix, English fluency (some buyers pay a premium for engineers who are comfortable facing their own stakeholders), and whether you need specialists such as a staff-level type architect or a performance engineer.
TypeScript specialist
One senior engineer embedded in your team. Good when the engineering org is solid and you need one more pair of hands that already knows strict TypeScript. Pairs with your team on the hardest parts, owns one slice of the codebase, attends your stand-ups.
Price: USD 7,500 to 12,000 per month. Minimum: 3 months.
Product squad
Three to five engineers (senior and mid mix) with a tech lead, QA automation and part-time DevOps. Delivers features, owns the design system, keeps the CI honest. Works well alongside a dedicated TypeScript development team page for scope references, or combined with our React team and Node.js team for specific stack bias.
Price: USD 22,000 to 42,000 per month. Minimum: 4 months.
Migration and hardening squad
Two to four engineers focused on a bounded goal: take the JavaScript codebase to strict TypeScript, or retire a specific class of runtime bug. Often runs alongside your feature team, not instead of it. Hands over when the scorecard is green.
Price: USD 16,000 to 32,000 per month. Minimum: 3 months.
Numbers assume 40-hour weeks and include recruiting, benefits, laptops and local taxes. Third-party services — Vercel, Sentry, Datadog, Auth0, Stripe — stay on your accounts so you keep control of data and billing.
The JavaScript-to-TypeScript migration path we actually use
Full rewrites get pitched in sales decks and rarely survive contact with a roadmap. What works is incremental: the codebase stays green, the product team keeps shipping features, and TypeScript spreads package by package until the last ts-ignore comes out.
- Baseline audit (week 1). We catalogue the hotspots, circular dependencies, implicit-
anyclusters and boundaries that leak untyped data into the app. The output is a risk map per package: what to convert first, what to quarantine, and what to leave alone until the end. - tsconfig and allowJs boundary (week 1–2). A single
tsconfig.json(or base config in a monorepo) withallowJs,checkJsand path aliases. No strict mode yet. Turbo or Nx pipelines so the type checker runs on what changed, not the whole tree. - Slice-by-slice conversion (week 2–10). Packages are migrated in order of risk-vs-value: shared libraries first, then the back-end, then the feature-rich front-end modules. Strict mode goes on per package the moment the package is clean, not globally at the end.
- Contracts and lint tightening (week 8–12). Zod at the HTTP and queue boundaries, tRPC or OpenAPI-generated types between services, and
@typescript-eslintrules dialled up (no-unsafe-*, no-explicit-any, consistent-type-imports). At this stage a lot of latent bugs surface; this is expected, not a regression. - Escape hatches out (week 10–14). Remaining
ts-ignoreandas anyare tracked on a public scoreboard. Generics get their constraints tightened. Type maps are published to downstream apps. When the scoreboard is zero (or honest-zero, with a documented exception list), the migration is done.
Timelines above are for a 30,000 to 80,000 line codebase. Bigger monorepos mostly extend step 3. We have not seen a migration that required stopping feature work, and we would push back if a client asked for one.
TypeScript with us vs freelancer, in-house or generic offshore
Most prospects have already tried at least one alternative. Here is an honest comparison. If a row does not match what you have seen, say so on the first call and we will adjust.
Where a freelance TypeScript developer wins
Scoped tasks. A generic component that nobody can get quite right. A one-off migration script. A Stripe or Auth0 integration with a clean spec. If the work is under roughly 80 hours, a specialist freelancer is usually cheaper and faster.
Where a freelancer hurts
Continuity. They juggle three other clients, take holidays without warning, and seldom do the unglamorous work that keeps a TypeScript codebase healthy: Storybook hygiene, generic refactors, ESLint upgrades, codemods. You ship tickets fast and the platform rots in parallel.
Where an in-house hire wins
Long-term ownership. If TypeScript is central to your product for the next five years and you can afford a four-month search, a full-time senior is irreplaceable. Plenty of our clients start with us, see what “good” looks like, and then hire internally. That is a healthy outcome.
Where in-house hurts
Funnel risk and regret cost. Senior TypeScript engineers in US and UK markets take three to four months to close, with high offer-rejection rates. If the hire turns out wrong at month six, you are looking at severance, not notice. Meanwhile the roadmap stalls.
Where large offshore agencies win
Warm bodies at low rates when the work is genuinely generic: internal tools, CMS skins, data-entry UIs. If the brief really is “give me ten TypeScript developers and assign them tickets”, they are built for it.
Where large offshore agencies hurt
The engineer in the interview is rarely the one in the commits. Timezone overlap with the US tends to be two to four hours. Type architecture and design system work are treated as extra scope rather than defaults. Notice periods are 30 to 90 days, which makes ramp-down painful.
Where we fit in
Between the two. Small, senior, full-time employees in a timezone that overlaps a full US business day. You interview the exact engineer who will write your code. Type architecture, design system, testing and CI are part of the default scope, not an upsell. Minimum commitments are three to four months, not a year.
For narrower gaps, our TypeScript staff augmentation service is usually the better fit — same engineers, different commercial model.
Real TypeScript scenarios we see repeatedly
These are composites from recent engagements. Details anonymised, numbers rounded, but the shapes are accurate. They are here because buyers usually want to know whether their situation is a thing we have dealt with before.
Scenario A — the SaaS codebase that grew past its types
Context. US B2B SaaS, 180,000 lines of mixed JavaScript and half-typed TypeScript. Five-person engineering team, two people who quietly kept the codebase alive. Churn was ticking up because every release introduced at least one “undefined is not a function” incident.
What we did. Three-person migration squad alongside the internal team. Strict mode enabled package by package, Zod added at the HTTP boundary, a typed event bus replacing the untyped emit calls. No features paused.
Outcome. In eleven weeks we reached strict mode on the three business-critical packages. Runtime type-error incidents dropped from weekly to roughly one a quarter. Onboarding a new engineer went from six weeks to ten days.
Scenario B — the startup that wanted strict from day one
Context. Series A healthtech in Toronto. Zero front-end engineers, Figma ready, a half-built Postgres schema. Investors expected a live product in a quarter.
What we did. Two-person TypeScript squad plus a part-time tech lead. Next.js App Router, tRPC against the existing Postgres via Drizzle, Zod schemas shared front-to-back, Storybook from week two, Playwright from week four. Strict mode on from commit zero.
Outcome. Thirteen weeks to a production app with auth, billing, onboarding and a care-team dashboard. When they later hired their first internal senior, she merged her first PR in four days because the types were the documentation.
Scenario C — the enterprise with four JavaScript apps and no shared contract
Context. European insurance group. Four internal applications, three of them JavaScript, each consuming the same back-end with a slightly different idea of what a “policy” meant. Integration bugs were a weekly ritual.
What we did. Four-person squad to stand up a Turbo monorepo with a shared @company/contracts package: Zod schemas, branded IDs, generated OpenAPI clients. Two existing apps migrated into the monorepo; the other two consumed the published types via a private registry.
Outcome. Integration bugs measured via support tickets dropped 64% over six months. Two of the four teams adopted the contracts voluntarily; the other two were onboarded later when a new regulation forced the change.
Scenario D — the design system that needed types, not a rewrite
Context. Media company with a React design system used by twelve product squads. Typed partially, but the component variants were strings, and breaking changes were shipped as email announcements.
What we did. Two senior engineers for four months. Moved variants to literal unions, published a typed @design/tokens package, wrote codemods for breaking renames, and added Storybook coverage as a CI gate.
Outcome. Average adoption time for a new component dropped from three weeks to four days. “Did you see my email?” stopped being the release protocol.
Mini case study
How a logistics platform cut production type-errors by 81% with a migration squad
Client. A Nordic logistics company running a merchant-facing portal (quoting, booking, invoicing) in vanilla JavaScript since 2017. Around 120,000 lines, a six-person internal team, and a habit of shipping a hotfix every Friday afternoon.
Brief. Get the codebase into strict TypeScript without pausing the quarterly roadmap, and leave the internal team able to continue the work on their own.
What we did. Three-person migration and hardening squad: one tech lead, two senior TypeScript engineers. Week 1 was the audit — a risk map ranking 43 packages by conversion cost and runtime-bug frequency. Weeks 2 to 10, we converted seven packages (the shared utilities, two API clients, the pricing engine and the back-end handlers), flipping strict mode per package. Weeks 6 to 12 overlapped with contract hardening: Zod at every HTTP boundary, branded OrderId and MerchantId instead of string everywhere, and a discriminated-union message type on the queue consumer that had been the source of most Friday incidents. The internal team kept shipping features throughout; in the weekly ops review we watched production type-error reports drop from twelve a week in week 1 to two a week by week 14.
Result after six months. Production incidents categorised as “type-related” (wrong argument shape, undefined access, bad assumption on a JSON payload) fell 81% year-over-year. Release cadence doubled. Onboarding for a new hire moved from “three weeks to feel safe” to “first PR in the second week”. The internal team took over the remaining packages at month six; we stayed on for one day a week to code review for another quarter.
Honest caveat. The first month felt slow. The audit does not produce demo-able features, and the client’s COO had to hold the line internally when the CEO asked why there was nothing to show. If you compare velocity in month one, we look worse than a freelancer. By month three the compounding started to show, and by month six nobody wanted to go back.
At a glance
Industry: Logistics / merchant portal
Engagement: 3-person squad, 6 months + review tail
Stack: Node.js, NestJS, React, Zod, Drizzle, Turbo
Type-related incidents: −81%
Release cadence: 2×
Onboarding time: 3 weeks → 1 week
The risks of outsourcing TypeScript work, and how we handle them
Any vendor telling you outsourcing TypeScript is risk-free is either inexperienced or selling. Here are the four failure modes we see most often, and the specific controls we use against each.
Risk: the engineer looks strong on paper and stalls in week three
How we handle it. Vetting ends in a live pair session on a real TypeScript bug — a generic that does not compile, an infer case that needs unpacking — not a Leetcode puzzle. Two-week free replacement window. The account lead checks in with you on day 14 with one question: “if this were a full-time hire, would you keep them?”. In the last 18 months we have swapped two engineers, both within the free window.
Risk: the types drift and “just a quick any” keeps landing in PRs
How we handle it. no-explicit-any, no-unsafe-* and consistent-type-imports are CI-blocking rules. Exceptions require a comment explaining why, which is reviewed in the next tech-debt session. A public scoreboard tracks remaining escape hatches so nobody has to play debt archaeologist six months later.
Risk: knowledge walks out when the engagement ends
How we handle it. Documentation is a line item, not a favour. Architecture Decision Records for non-obvious type choices, READMEs for every non-trivial package, runbooks for production incidents, Storybook entries for components. If you end the engagement tomorrow, the internal team has a map, not a scavenger hunt.
Risk: the migration eats velocity and loses political air cover
How we handle it. A weekly scorecard with four numbers: packages on strict mode, ts-ignore remaining, boundary validation coverage, and production type-error count. Those four numbers sit in the weekly ops review so that engineering progress is visible to people who do not read pull requests.
Why Siblings Software specifically
Decide based on facts, not slogans.
11+
Years staffing TypeScript teams
Founded 2014 in Córdoba, Argentina
80+
TypeScript engagements shipped
SaaS, fintech, health, retail, logistics
GMT-3
Argentina timezone
Full same-day overlap with US Eastern
We are deliberately small. There is no sales organisation chasing headcount. The founders — Javier Uanini still takes most discovery calls personally — review every engagement. Our engineers talk to clients directly from week one. That is the actual reason onboarding is fast: there is nobody in the middle translating requirements.
Things buyers usually get wrong when shopping for a TypeScript vendor: asking for an hourly rate before explaining the work (you will be quoted the lowest possible number, and the real cost will arrive as change orders later), assuming any developer who lists TypeScript on their CV knows strict mode (most do not), and believing that a bigger agency means more reliable delivery (in TypeScript product work, small and senior beats large and generic almost every time).
For context, the official TypeScript website is the baseline we teach against, and the typescript-eslint project is the lint ruleset we extend. We contribute back when we can, we read the RFCs, and we do not treat TypeScript as an afterthought to JavaScript.
Frequently asked questions from buyers
ts-ignore escape hatches. Larger monorepos extend the middle phase, not the overall shape.Our standards
TypeScript treated like the main thing, not a linter we forgot to turn off.
- Strict mode as the default, always. New projects start with
"strict": true. Migrations reach it per package, not per repo. - Runtime boundaries are validated. Zod or Valibot at every HTTP, queue and third-party edge. Compiler trust is a privilege that stops at the JSON boundary.
- Generics with constraints, or no generics. Unconstrained
Tis a smell. Branded types protect IDs. Discriminated unions model state. - Type checks as CI gates.
tsc --noEmitblocks merges.typescript-eslintstrict rules block merges. No quiet fallback toany. - Written artefacts. ADRs for architectural type choices. READMEs per package. Runbooks for production incidents. The handover is a file tree, not a call.
- Honest escalation. If the migration scoreboard slips, it says so in the weekly update, not three sprints later.
Talk to Siblings Software
Tell us about the codebase, the team and what you need. We reply within one business day, or say so if we are the wrong fit.