We pick tools your team can still maintain in three years
Every technology on this page is one we run in production today, with an honest page explaining where it fits, where it fails, and when we would recommend something else instead. Novelty is not a selection criterion; hireability, operational simplicity and a decade of hindsight are.
Build & Application
The frameworks and languages our web, mobile and business systems are written in.
Data Platform
Processing, storage and warehouse technologies behind our pipelines and lakehouses.
Cloud & Automation
Where it runs, and the tooling that connects and automates it.
Three questions before any technology decision
We have inherited enough estates built on the exciting choice of 2019 to have opinions about this.
- 1Can the client hire for it in Kolkata?A stack nobody local can maintain becomes a liability the moment we are not in the room.
- 2Will it still be supported in five years?Business systems outlive fashions. We choose boring where boring is correct.
- 3Does it reduce moving parts or add them?One database that does four jobs beats four services that each do one, until genuine scale forces otherwise.
Why we publish an honest page for every tool
Most agency technology pages are a logo wall. They tell you a firm has heard of Kubernetes; they tell you nothing about whether that firm has operated it at 2 AM when a node pool failed to scale, or whether they would recommend it to you in the first place.
We took the opposite approach. Every technology here has a page describing where it genuinely fits, where it fails, the specific ways projects using it go wrong, and the circumstances in which we would recommend something else instead. Several of those pages actively argue against the technology for certain situations — the Spark page tells you when a single machine with DuckDB will finish faster and cost a fraction; the Kafka page asks two questions that frequently lead to a managed queue instead.
That is not modesty. It is the most efficient way we know to establish whether a working relationship makes sense. A prospective client who reads our Snowflake page and concludes that BigQuery suits them better has saved both of us three meetings, and they now know we will tell them the truth about the next decision too.
It also reflects how these decisions actually go wrong in the market. Technology selection in Indian mid-market IT is frequently driven by what sounds impressive in a proposal rather than by what the client can maintain. A vendor recommends a stack requiring skills the client does not have and cannot easily hire, delivers it, and leaves. Eighteen months later the system is frozen because nobody in the building can safely change it. We have inherited enough of those estates to have a strong view.
The single most important selection criterion for a business system is not performance or elegance. It is whether your organisation can maintain and extend it in three years — in-house, or by hiring another vendor without a rewrite.
What each page contains
- Our honest position — why we use it and how long we have run it in production.
- Where it fits: the specific workloads and situations it suits.
- Production patterns we apply, with the reasoning rather than a checklist.
- Pitfalls: how projects using this technology actually go wrong.
- Questions clients ask, including when we would recommend an alternative.
Deciding something now?
Short architecture advisory engagements are some of our most useful work — data model design, technology selection, or a diagnostic on an application that has become slow or expensive. Typically two weeks, fixed price, with a written report you own regardless of what you decide next.
Tell us what is slowing your business down.
A 30-minute call with a senior engineer — not a salesperson. You leave with an architecture sketch and an honest cost range, whether or not you hire us.
Direct line
+91 70033 91355Mon–Sat · 9:30 AM – 7:30 PM IST · Sealdah, Kolkata