Technologies
Tankar's stack by layer, with when we recommend each technology and when we do not. Where you already run a platform, that comes first; these are the defaults when the choice is open.
Frontend
What runs in the browser: marketing sites, SaaS dashboards, admin panels and customer portals.
| Technology | When we recommend it | When not |
|---|---|---|
| Next.jsHire Next.js and React developers | Anything that must be found by search engines or load fast on mobile: marketing sites, SaaS products with public pages, portals with server-rendered content. Server components and static generation keep the JavaScript budget small. | A purely internal tool behind a login where SEO and first-load speed do not matter; a plain React single-page app with Vite is simpler to run and host. |
| ReactHire Next.js and React developers | Interactive interfaces with a lot of state: dashboards, editors, configurators, anything with drag and drop or live updates. The component model and the hiring pool make it the default for web UI. | Content pages with almost no interaction, where server-rendered HTML with a little JavaScript is lighter and cheaper to maintain. |
| TypeScriptHire Next.js and React developers | Every new frontend and Node.js codebase. Types catch a class of bugs before they reach QA and make the code readable to the next engineer, which matters when the code lives in your repository. | A throwaway prototype that will be discarded after a demo. Even then the cost is small. |
| Tailwind CSSHire Next.js and React developers | Products with a design system: tokens for colour, type and spacing are defined once and every component uses them, which keeps the interface consistent as it grows. | A team that already has a mature component library and CSS conventions; switching for its own sake costs more than it saves. |
Mobile
Apps for iOS and Android built from one codebase.
| Technology | When we recommend it | When not |
|---|---|---|
| FlutterHire Flutter developers | Consumer and business apps that need the same look on iOS and Android, custom UI, and smooth animation. One Dart codebase, one team, and a rendering engine that does not depend on platform widgets. | An app that is mostly a wrapper around web content, or one that needs deep platform-specific features on day one; a native module still has to be written per platform. |
| React NativeHire React Native developers | Teams that already have React developers and a React web product: shared skills, shared logic and shared TypeScript types between the web and mobile apps. | Graphics-heavy apps or apps that lean on many native SDKs; Flutter or native development is a better fit there. |
Backend
APIs, business logic, background jobs and integrations.
| Technology | When we recommend it | When not |
|---|---|---|
| Node.jsHire Node.js developers | APIs and services that sit next to a TypeScript frontend: one language and one set of types across the team, and strong libraries for real-time features, queues and integrations. | CPU-heavy processing such as large batch computations or video encoding; Node.js is single-threaded per process and those jobs belong in a worker written for it. |
| Python and FastAPIHire Python developers | Backends that include data processing, machine learning or LLM features: the same language as the model code, typed request and response models, and good async support for calling model APIs. | A team with no Python experience building a conventional CRUD product; Node.js or .NET will be easier for them to own after handover. |
| .NETHire .NET developers | Organisations already on Microsoft infrastructure, Windows-integrated systems, and long-lived enterprise applications where a strongly typed, well-supported platform with a clear upgrade path matters. | Small products where the team's skills are in JavaScript or Python; the platform is capable, but the hiring pool for the client's own team should decide. |
| REST and GraphQL APIsHire Node.js developers | REST with an OpenAPI specification for most products and every public API: simple to cache, document and integrate. GraphQL when several clients need different shapes of the same data, such as a web app and a mobile app sharing one backend. | GraphQL for a simple internal API with one client; the extra layer adds complexity without a benefit. |
AI and machine learning
LLM applications, retrieval systems, agents and classical machine learning, chosen by the problem rather than the trend.
| Technology | When we recommend it | When not |
|---|---|---|
| LLM APIs (OpenAI, Anthropic, Google, Azure OpenAI)Hire AI and machine-learning engineers | Assistants, document understanding, summarisation, extraction and classification where quality matters more than per-token cost. Provider choice is driven by data-residency requirements, evaluation results on your documents and the cost per query. | A task a rule or a small classifier solves reliably, such as matching on known fields, or a workload where every request must stay on your own infrastructure. |
| Retrieval-augmented generation (RAG)Hire AI and machine-learning engineers | Answering questions over your own documents, policies, tickets or contracts. The model reads retrieved passages instead of relying on what it was trained on, so answers can cite sources and stay current as documents change. | When the knowledge is small enough to fit in a prompt, or when the task needs the model to learn a style or format rather than facts; fine-tuning or plain prompting is simpler. |
| Vector databases (pgvector, Qdrant, Pinecone)Hire AI and machine-learning engineers | pgvector inside PostgreSQL for most products: one database to run, and retrieval sits next to the rest of the data. A dedicated vector store when the corpus is very large or retrieval latency at scale is the bottleneck. | Small corpora, where a full-text index or an in-memory search is enough and easier to operate. |
| Model fine-tuningHire AI and machine-learning engineers | A stable, well-defined task with plenty of labelled examples, where prompting has been evaluated and falls short, or where a smaller, cheaper model must match a larger one on your task. | As the first step. Prompting and retrieval are evaluated first because they are cheaper to change when the requirements move. |
| AI agents and tool useHire AI and machine-learning engineers | Multi-step tasks that need to call systems: look up an order, draft a reply, create a ticket. Each tool has a narrow contract, actions with consequences require a human confirmation, and every run is logged. | Any workflow where a wrong action is expensive and hard to reverse and cannot be gated by a person; a deterministic workflow with an LLM step inside it is safer. |
| Python ML stack (scikit-learn, PyTorch)Hire AI and machine-learning engineers | Forecasting, anomaly detection, recommendation and classification on structured data. Classical models are cheap to run, explainable and often beat an LLM on tabular problems. | Problems without enough historical data to learn from; start with rules and collect data first. |
| Evaluation harnessesHire AI and machine-learning engineers | Every AI feature. A test set of real inputs with expected outputs, scored for accuracy, cost per query, latency and safety before and after every change. Without it there is no way to know whether a prompt change helped. | There is no case for skipping it; the size of the test set scales with the risk of the feature. |
Data
Databases, caches, pipelines and reporting.
| Technology | When we recommend it | When not |
|---|---|---|
| PostgreSQLHire Node.js developers | The default database for products: transactions, JSON columns, full-text search and vector search in one well-understood system that every major cloud runs as a managed service. | Very high write volumes of time-series or event data, where a purpose-built store is cheaper, or unstructured documents with no fixed shape. |
| RedisHire Node.js developers | Caching, rate limiting, sessions, queues and anything that needs sub-millisecond reads. It sits beside PostgreSQL, not in place of it. | As the primary store for data that must not be lost; it is memory-first and should hold data you can rebuild. |
| MongoDBHire Node.js developers | Documents whose shape varies by record, such as product catalogues with different attributes per category, or prototypes where the schema is still moving. | Data with many relationships and reporting needs; joins and constraints are what PostgreSQL is for. |
| Data pipelines (Airflow, dbt)Hire Python developers | Scheduled ingestion and transformation from several sources into a warehouse: scraped portals, ERP exports, payment reports. Airflow schedules and monitors the jobs; dbt keeps transformations versioned and tested. | One source and one nightly job; a scheduled script with logging is enough until there are several. |
| Warehouses and dashboards (BigQuery, Snowflake, Metabase, Power BI)Hire Python developers | When reporting queries slow down the product database or need data from several systems. A warehouse takes the analytical load; Metabase or Power BI gives the business self-service dashboards. | Early-stage products with one database and a few reports; a read replica and a handful of SQL views cost far less. |
Cloud and DevOps
Hosting, infrastructure as code, containers and delivery pipelines.
| Technology | When we recommend it | When not |
|---|---|---|
| AWS, Azure and Google CloudHire DevOps engineers | The client's existing cloud, first. Otherwise: AWS for the broadest managed services, Azure for Microsoft-centred organisations and .NET workloads, Google Cloud for data and AI-heavy products. Data-residency rules in the UAE, Saudi Arabia and India often decide the region before the provider. | Splitting one product across providers without a reason; it doubles the operational surface. |
| VercelHire DevOps engineers | Next.js sites and apps where fast deploys, preview environments and a global edge matter more than fine-grained infrastructure control. | Workloads with data-residency requirements the platform cannot meet, or long-running backend processes; those run on the client's cloud. |
| DockerHire DevOps engineers | Every backend service: the same image runs in CI, staging and production, and the client can run it on their own servers if they leave a platform. | Static sites and serverless functions where the platform handles packaging. |
| KubernetesHire DevOps engineers | Several services with different scaling needs, or an organisation that already runs a cluster. Managed offerings (EKS, AKS, GKE) keep the control plane someone else's problem. | A single service or a small team; a managed container service or a VM with Docker Compose is cheaper to run and easier to understand. |
| TerraformHire DevOps engineers | Any environment that must be reproduced: staging that matches production, disaster recovery, or handover to the client's own team. Infrastructure in code, reviewed like application code. | A one-off prototype environment that will be deleted after a demo. |
| GitHub ActionsHire DevOps engineers | CI and CD for repositories on GitHub: lint, test, build, security audit and deploy on every pull request, with the workflow living in the client's repository from week one. | Organisations standardised on another CI system such as GitLab CI or Azure DevOps; the pipeline is written for the system they already run. |
| Monitoring and error tracking (Sentry, cloud-native monitoring)Hire DevOps engineers | Every production system: error tracking, uptime checks, performance monitoring and alerting wired into the incident process before launch, not after the first outage. | There is no case for skipping it; the depth of monitoring scales with the SLA. |
QA and test automation
Automated and manual testing that runs in the pipeline, not only before release.
| Technology | When we recommend it | When not |
|---|---|---|
| PlaywrightHire QA engineers | End-to-end tests of the flows that make money or cause support tickets: sign-up, checkout, booking, form submission. Runs in CI against real browsers and catches regressions before a release. | Driving every screen through the browser; that suite becomes slow and brittle. Cover the critical flows this way and the rest with unit and integration tests. |
| Vitest and JestHire QA engineers | Unit and component tests for business logic, validation and UI components, written alongside features so the test suite grows with the product. | Testing framework code or trivial getters; tests should cover behaviour the product depends on. |
| k6Hire QA engineers | Load testing before a launch or a campaign, and for any public-sector or marketplace system where a traffic spike is predictable. It shows where the system breaks before users do. | Internal tools with a known, small number of users. |
| axe-core and LighthouseHire QA engineers | Accessibility and performance checks in the pipeline for every public-facing page, so WCAG and Core Web Vitals regressions fail the build rather than appear in an audit later. | There is no case for skipping them on public pages. |
GovTech integrations
Interfaces that Indian public-sector and government-facing systems commonly need.
| Technology | When we recommend it | When not |
|---|---|---|
| Tender and e-procurement portal pipelinesHire Python developers | Aggregating tenders and notices published across central, state and municipal portals into one searchable system, with scheduled collection, normalisation and alerting. This is the pattern behind TenderBazaar. | Where a portal offers an official data feed or API; use that instead of collecting pages. |
| DigiLocker and Aadhaar-based eKYCHire Node.js developers | Citizen-facing services that must verify identity or fetch issued documents. Aadhaar-based verification goes through licensed providers under UIDAI rules; DigiLocker is used for document pull with the citizen's consent. | Services that do not legally need identity verification; collecting identity data without a need creates compliance obligations under the DPDP Act 2023. |
| Payment gateways and UPIHire Node.js developers | Fees, licences and services paid online: a PCI DSS-compliant gateway with UPI, cards and net banking, with reconciliation reports the finance team can use. | Building card handling in-house; the gateway keeps card data out of your systems and out of your PCI scope. |
| GST and e-invoicing APIsHire .NET developers | Marketplaces and platforms that issue invoices in India: GST-compliant invoicing, e-invoice generation through a GSP where turnover requires it, and reports that match the returns. | Products that do not invoice in India. |
| SMS, WhatsApp and email notificationsHire Node.js developers | Citizen and customer notifications through DLT-registered SMS templates, the WhatsApp Business API and transactional email, with delivery logs for audit. | Marketing broadcasts without consent; notification channels are for transactional messages the recipient expects. |
| eSign and document workflowsHire Node.js developers | Approvals and agreements that must be signed and archived: Aadhaar eSign or a digital signature certificate through a licensed provider, with a tamper-evident audit trail. | Low-stakes internal approvals where a logged in-app confirmation is enough. |
Tell us what you are building.
NDA on request. Written estimate within 48 hours of a scoped call. Reply within one business day.