Technologies We Use
A stack list proves nothing — anyone can write one. So every page here also says plainly when we would not use that technology, and what we would recommend instead.
17
Technologies we actually run
Every page
Says when NOT to use it
Both sides
Postgres and SQL Server
In production
Not a capability slide
Every agency publishes a technology page and they all look the same: a grid of logos implying equal mastery of everything. It tells a buyer nothing, because the list is free to write and impossible to verify.
So we have written these pages differently. Each one covers what we build with that technology, the specific problems we find when we inherit a codebase using it, the engineering decisions that separate a good implementation from a bad one — and a section stating plainly when we would not use it and what we would recommend instead. That section is the useful part. A partner who cannot tell you the limits of their own stack has not hit them yet.
The through-line is that we choose per problem rather than per habit. Angular for large enterprise applications and Next.js for anything that must rank. PostgreSQL for new systems and MS SQL Server where the estate already runs on it. Kubernetes where the complexity is justified and a single container where it is not.
Frontend
Three different answers, because a marketing site and a 300-screen ERP are not the same problem.
Angular
The framework we reach for when an application has hundreds of screens, dozens of forms and a team that will maintain it for years — enterprise front-ends, ERP consoles and admin platforms.
- Enterprise ERP and admin consoles
- Reactive forms at real complexity
- Strict TypeScript, opinionated structure
Next.js
Our choice for anything that has to rank and load fast — marketing sites, storefronts and content platforms delivered as static HTML with the interactivity added where it earns its weight.
- Static-first delivery, sub-second loads
- Core Web Vitals as a build constraint
- Structured data and technical SEO built in
React
The library behind most of our interactive interfaces — used deliberately, with state kept where it belongs and rendering costs understood rather than discovered in production.
- Interactive dashboards and product UIs
- State management that stays comprehensible
- Component libraries and design systems
Backend
Where correctness, transactions and auditability are decided — plus the legacy nobody else will touch.
Python & Django
Our default backend for anything transactional — ERP, fintech, healthcare and marketplaces — where correctness, auditability and a mature security posture matter more than raw benchmark speed.
- Transactional integrity as a first principle
- Django REST Framework APIs at scale
- Celery + RabbitMQ for async work
PHP
The language a great deal of working business software is already written in. We maintain it, secure it, speed it up and modernise it incrementally — rather than proposing a rewrite by reflex.
- Take over unmaintained PHP applications
- Security and dependency remediation
- Performance and query optimisation
Node.js
Where a persistent connection or an event-driven service is genuinely the requirement — real-time features, streaming, webhooks and lightweight services alongside a Django core.
- Real-time and WebSocket services
- Webhook ingestion and integration layers
- Shared TypeScript across front and back
Data
The layer that outlives everything else built on top of it.
Microsoft SQL Server
Working with the enterprise database estate you already have — query and index tuning, stored procedure work, reporting, and integration without forcing a migration you don't need.
- Query and index performance tuning
- Stored procedures and T-SQL work
- Integration with existing plant systems
PostgreSQL
The database we build new systems on — exact decimal arithmetic, real constraints, JSON where it helps, and the transactional guarantees that make reconciliation possible at all.
- Exact decimal maths for financial data
- Constraints enforced by the database
- Query and index tuning with measured results
SSRS & SQL Reporting
The reporting layer most agencies will not touch — SSRS paginated reports, scheduled subscriptions, T-SQL report logic, and migrating decades of report estate onto something modern without losing it.
- SSRS report development & tuning
- Scheduled subscriptions and distribution
- Report estate audit and rationalisation
Platform & Infrastructure
Shipping changes safely, absorbing load, and enforcing policy at the edge.
Docker & Kubernetes
Containerisation and orchestration done for the reason that actually matters: deploying changes safely, repeatedly and without taking the business offline mid-shift.
- Zero-downtime rolling deployments
- Identical environments, no “works on my machine”
- Autoscaling for predictable peaks
RabbitMQ
Message queuing so slow work, unreliable third parties and traffic spikes never reach the user's request — the difference between one feature degrading and the whole system stalling.
- Heavy work out of the request path
- Retries, backoff and dead-letter queues
- Service decoupling for microservices
Kong API Gateway
One controlled front door for every API — authentication, rate limiting, routing and logging enforced once at the edge instead of reimplemented inconsistently in each service.
- Auth and rate limiting enforced once
- Safe routing during microservices migration
- Per-consumer quotas for partner APIs
Microsoft Azure
Deploying and running business applications on Azure — containers, Blob Storage, Queues and Service Bus — with the cost and configuration discipline that decides whether cloud is cheaper or just different.
- Container-based application hosting
- Blob Storage, Queues & Service Bus
- Secrets and configuration done properly
Microservices Architecture
Splitting a system into services that can be deployed and scaled independently — gateway, message bus, per-service databases, reporting services — and being straight about when a monolith is the better answer.
- Gateway → services → message bus → own databases
- Strangler-pattern migration, one endpoint at a time
- Separate reporting services
Mobile
Three of our own apps are on Google Play — build through to a live listing.
React Native
One codebase for Android and iOS when the product suits it — with an honest comparison against Flutter and native, because the right answer depends on what the app actually does.
- Android and iOS from one codebase
- Shared logic with an existing React web app
- Store submission handled end to end
Flutter
The framework behind all three apps we have published ourselves — one codebase for Android and iOS, a fully custom interface, and heavy on-device processing where it is needed.
- 3 of our own apps live on Google Play
- Fully custom UI, not platform widgets
- Heavy on-device processing (FFmpeg, SQLite)
Android & Play Store
The half of mobile delivery nobody quotes for — signing, app bundles, data-safety declarations, permissions, staged rollout and the review cycle that decides when you actually launch.
- Release signing & keystore management
- Data-safety and permission declarations
- Closed testing then staged rollout
Why This Stack, and How We Pick Within It
The frontend choice is a question about the application, not the framework
We use three frontend technologies deliberately. Next.js for anything public-facing that has to rank and load fast, because static-first delivery means content arrives as HTML rather than as instructions for producing HTML. Angular for large enterprise applications where opinionated structure keeps a 300-screen codebase consistent across a changing team. React for interactive product interfaces where flexibility is worth more than imposed structure.
Using one of these for the others’ job is a common and expensive mistake. Angular on a marketing site loses the search performance the site exists for. React without server rendering on a content site ships an empty shell to crawlers. Next.js on a huge authenticated application gives up structure it would benefit from.
The backend and data layer is where correctness is decided
Django is our default backend because it makes the unglamorous things correct by default — transactions, migrations, permissions and security — so our effort goes into your business rules rather than into rebuilding infrastructure. PostgreSQL is the default database because exact decimal arithmetic and real constraints are what make reconciliation possible instead of aspirational.
We work with Microsoft SQL Server just as seriously, because a great deal of enterprise and manufacturing data already lives there behind systems nobody has a business case to replace. Knowing both is what lets us give genuinely neutral migration advice — which is frequently that you should not migrate.
Infrastructure is judged by whether you can deploy on a Tuesday afternoon
Docker and Kubernetes are not the objective. Being able to ship a change while a factory runs a shift, with health-checked rolling updates and rollback in seconds, is the objective. RabbitMQ keeps slow work and unreliable third parties out of the user’s request. Kong makes authentication and rate limiting one policy instead of several slightly different ones.
SonarQube and automated end-to-end testing gate every change, so structural decay is caught in review rather than discovered a year later. And we use current AI tooling — Claude, ChatGPT, Gemini — for scaffolding, tests, refactoring and documentation, which genuinely reduces cost on the mechanical parts. Architecture, security and anything touching money or personal data are engineered and reviewed by a person, and everything passes the same gates regardless of how it was produced.
- Zero-downtime deployment as a baseline requirement
- Heavy work queued, never in the request path
- SonarQube quality gates and automated testing in CI
- AI used for speed; humans accountable for what ships
Explore Further
Industries We Serve
Where this stack is applied — manufacturing ERP, fintech, healthcare and more.
Case Studies
Real projects and our own published products.
Services
Web, mobile, ERP, dashboards, AI automation and custom software.
How We Work
Discovery through launch, and what to expect at each stage.
Engineering Blog
Longer write-ups on the decisions behind these choices.
Talk To Us
Describe the problem; we’ll tell you what we would actually use.
Not Sure Which Of These You Need?
You should not have to be. Tell us what the software has to do, who uses it and what it has to guarantee — choosing the stack is our job, and we will explain the reasoning rather than just the conclusion.
Serving startups, factories and enterprises across India, the US, UK, Australia & Europe.