TypeScript, Python, or both for an eight-week build?

The question

We are a 10-person team about to start a new internal tool with a deadline of 8 weeks. Half the team knows TypeScript well, half knows Python well, and the tool will include a machine-learning scoring step. Should we write the whole backend in TypeScript, the whole backend in Python, or TypeScript for the API with a separate Python service for the ML step?

What each model said

Each answer is the model’s own words, with formatting marks removed.

• Claude Sonnet 5.5

  Write the whole backend in Python (FastAPI). ML scoring is the one component where Python is nearly mandatory, and a second service adds deployment, serialization, versioning, and monitoring overhead that eats a meaningful chunk of an 8-week budget for a 10-person internal tool. The TypeScript half still contributes by owning the frontend (React/TS) and consuming a typed OpenAPI client. Assumptions: modest scale, no hard need for a Node-specific ecosystem, and the ML model is a standard Python-library model.

• GPT-4.1

  Build the API/backend in TypeScript and the ML scoring step as a separate Python service. This leverages each group's strengths, allows rapid development, and keeps the ML code in Python where ecosystem support is better. Clear interfaces (e.g., REST or gRPC) minimize integration pain. With an 8-week deadline and split skills, this parallelization and division of concerns improves speed and quality.

• Gemini 3.5 Flash-Lite

  Decision: Use TypeScript for the API with a separate Python service for the ML step. Key Reasoning: - Leverages team strengths: Everyone contributes immediately without a steep language learning curve. - De-risks the deadline: 8 weeks is tight. TypeScript handles the CRUD/API logic fast for the TS half, while Python natively supports the ML libraries. Load-bearing Assumptions: - The ML scoring is a distinct, stateless step rather than deeply intertwined with core business logic.

• Grok 4.20

  TypeScript for the API + separate Python ML service. The 5 TS and 5 Python engineers stay productive in their strongest language, which is the dominant constraint on an 8-week deadline. Python’s ML ecosystem is vastly superior and battle-tested; forcing the ML step into TS would create major risk and slow the whole project. A lightweight service boundary (REST/gRPC) between them is trivial to operate for an internal tool. Assumption: the ML component can be cleanly isolated as a scoring service.