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.
Why the stack on your project is not the stack we prefer
Every technology listed here is one we have used in production and would use again. None of them is a default. The most damaging thing an engineering supplier can do is arrive with a preferred stack and reverse-engineer a justification for it, and it happens constantly because it is genuinely easier to sell a team on what they already know than to work out what the client should have.
The dominant factor in our recommendation is almost never technical merit — it is who maintains the system after we leave. If you have three PHP developers who have kept a CodeIgniter application alive since 2016, delivering them a TypeScript monorepo is professional negligence dressed up as best practice. The correct answer is excellent Laravel or CodeIgniter 4, built to a standard those developers can extend. If you have no in-house engineers at all and no intention of hiring any, the correct answer leans towards managed services and fewer moving parts, even where that costs more per month.
Second is the shape of the problem rather than its size. Distributed processing engines, event streaming platforms and orchestration frameworks all earn their operational complexity at a genuine scale and become expensive theatre below it. We have replaced small Spark deployments with a single well-provisioned machine and watched both cost and runtime fall. We have also told clients that a database table and a scheduled job would do everything they described a message broker for.
Third is longevity. We favour technologies with a boring track record and a wide hiring pool over ones that are currently interesting, because you will live with this choice for five years and will need to hire for it. That bias is the main reason PostgreSQL appears under almost every architecture we draw.
The four questions behind every stack decision
- Who maintains this after handover, and what do they already know?
- Is the operational complexity justified by the actual scale, measured honestly?
- Can you hire for this in Kolkata in 2031, not just in 2026?
- What does the managed version cost against the engineering time to self-host?
- What is the exit path if this choice turns out to be wrong?
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