What we build with, and when we would not.
Novelty is a cost your project pays after we leave, so we reach for things your next engineer will already know. Every entry below includes the case where it is the wrong answer — that half is usually more useful than the other.
10
Tools we actually use
2019
Longest in service
Interface
What people touch
API
One contract, many clients
Data
The source of truth
Infrastructure
How it stays up
Most agencies stop at the first layer. The other three are what turn a website and an app into one system a business can actually run on.
Interface
What people touch. Server-rendered by default; client-side only where it earns its place.
Next.js
Web applications and marketing sites
In service since 2021
Why we reach for it
Server components mean most of a page never becomes JavaScript, which is the single biggest lever on how a site feels on a mid-range Android.
When we would not
A purely static brochure with no content model — Astro is lighter and we will say so. And we do not reach for it to wrap an existing backend that already renders fine.
React Native
iOS and Android from one codebase
In service since 2022
Why we reach for it
Two native teams is a cost most businesses this size cannot justify, and the gap in feel has largely closed for the kind of apps we build.
When we would not
Heavy real-time graphics, deep platform integration, or anything where the app *is* the product and the company can fund two teams. Then native is correct and we would say so.
Tailwind CSS
Styling
In service since 2021
Why we reach for it
Constraints in the markup rather than a parallel naming system nobody maintains. It also makes a design system enforceable rather than aspirational.
When we would not
A team that already has a working component library and a strong CSS convention. Switching them costs more than it returns.
Server & data
Boring, well-understood choices your next engineer will already know.
Node.js
APIs and services
In service since 2019
Why we reach for it
One language across the stack, so a small team moves between layers without switching context. That matters more at our size than raw throughput.
When we would not
CPU-bound work — image pipelines, heavy analytics. We reach for Python or Go there and have done.
PostgreSQL
Primary datastore
In service since 2020
Why we reach for it
Most business software is relational whether or not the team admits it. Constraints in the database are the cheapest bugs you will ever prevent.
When we would not
Genuinely document-shaped data with a schema that moves weekly. Then Mongo, and we will not pretend otherwise.
MongoDB
Document workloads
In service since 2019
Why we reach for it
Right when the shape of a record is genuinely unstable, or when a client's team already runs it and switching is not the project.
When we would not
Reporting-heavy products. We have watched aggregation pipelines become the hardest code in a codebase.
Redis
Cache, queues, rate limits
In service since 2021
Why we reach for it
Small, predictable, and does three jobs well enough that you rarely need a fourth tool.
When we would not
As a primary store. It is not one, and treating it as one ends badly.
Run & prove
Every project ships with tests, monitoring and infrastructure as code.
Vercel
Hosting for web
In service since 2021
Why we reach for it
Preview deploys per pull request change how a client reviews work — they click a URL instead of reading a status note.
When we would not
Long-running jobs, heavy background processing, or a client with an existing cloud commitment. Then AWS, in their account.
AWS
Infrastructure
In service since 2020
Why we reach for it
When it has to live in the client's own account with their own compliance posture. Reproducible from Terraform, not from memory.
When we would not
A five-page marketing site. Paying the AWS complexity tax for that is a choice we would be making for ourselves, not for you.
Playwright
End-to-end testing
In service since 2022
Why we reach for it
The tests that matter run the actual flows a user runs. It also catches the things unit tests structurally cannot.
When we would not
Never, really — but we keep the suite small. A slow suite gets skipped, and a skipped suite is worse than none.
Already running something else? That is usually fine, and often the right answer. We would rather fit your stack than sell you a migration you did not ask for — and if the honest recommendation is that you keep what you have, that is what you will get.
Not sure what yours should be?
Tell us what the software has to do and who has to maintain it afterwards. Those two answers decide most of the stack on their own.
- 24h
- Reply to every enquiry
- 48h
- Written scope after the call
- ₹0
- Cost of the first conversation