The stack matters less than what it has to do.
Nobody runs a business better because their software is written in one language rather than another. What a stack decides is how fast you can change things later, who you can hire to maintain it, and what it can be connected to. Those questions have real answers, and they are the ones we work through before recommending anything.
A technology choice is a maintenance decision.
Every item below is something we build with. Where a page already explains that work in detail, it is linked. Where it is not linked, there is no page yet rather than a page we forgot to mention.
- Change a feature without a rewrite
- Hire somebody in this city to maintain it
- Connect to the systems you already run
- Hold up when more people use it
- Keep your data correct under load
- Add AI later without starting again
What the user actually looks at.
The screens your staff open every hour and your customers judge you by. This site is built with React, Next.js, TypeScript and Tailwind CSS.
React
Interfaces built from reusable parts, which is what keeps a large application consistent as it grows.
- Dashboards
- Customer portals
- Employee portals
- CRM and ERP screens
- Admin panels
Next.js
React with the server side attached, so pages arrive fast and search engines can read them.
- Business websites
- SaaS applications
- Customer portals
- Marketplaces
- Product platforms
TypeScript
JavaScript with types, which means a whole class of mistakes is caught while the code is written rather than by your staff.
- React and Next.js
- NestJS
- React Native
- APIs
JavaScript
The language every browser runs. Most of what your staff click is still built on it.
- Web applications
- Browser behaviour
- Interactive forms
- Older applications
Tailwind CSS
A styling approach that keeps an interface consistent when several people work on it over months.
- Application interfaces
- Dashboards
- Admin panels
- Responsive layouts
Vue.js
An alternative to React, and the sensible choice when your team already knows it or your current application uses it.
- Dashboards
- Admin panels
- Internal tools
Angular
Common in older enterprise front ends. We extend and maintain these rather than pushing a rewrite.
- Enterprise applications
- Existing dashboards
- Internal portals
Progressive web apps
A web application that installs on a phone, for when an app store listing is not worth the effort.
- Field staff tools
- Customer portals
- Offline-tolerant screens
Where the rules and the data live.
Business rules, permissions, integrations and everything that has to stay true whichever screen it is edited from.
Node.js
One language across the browser and the server, which is why a small team can hold the whole system in its head.
- APIs
- Real-time features
- Automation
- Integrations
- Mobile app backends
NestJS
Structure imposed on a Node application, which matters most on the systems that live for years.
- SaaS platforms
- Multi-tenant applications
- REST APIs
- Authentication
- CRM and ERP backends
Express
The lighter Node framework, used where a service does one job and does not need a full framework around it.
- Small services
- Internal APIs
- Webhook receivers
Laravel
A mature PHP framework, and often the right answer when you already run PHP and want to build on it rather than start again.
- Business applications
- Management systems
- Admin portals
- Customer portals
PHP
Still running a great many Indian business systems. We maintain and extend them rather than insisting they be replaced.
- Existing applications
- Web applications
- APIs
- Backend work
Python
The language we reach for when the work is data, documents or models rather than screens.
- Data pipelines
- Document processing
- AI services
- Automation scripts
Django
Python with the admin, authentication and database layer already built, which shortens an internal system considerably.
- Internal systems
- Admin-heavy applications
- Data-backed portals
FastAPI
A fast way to put a Python service behind an API, used most often in front of AI and data work.
- AI services
- Data services
- Internal APIs
Applications for people who are not at a desk.
Field staff, delivery teams, technicians, doctors on rounds, and customers who will never open your web portal.
React Native
One codebase producing both Android and iOS, which usually halves the cost of keeping two apps in step.
- Customer apps
- Field sales apps
- Employee apps
- Booking apps
- Dealer apps
Flutter
The other cross-platform option, strong where the interface is heavily designed and animation matters.
- Customer apps
- Booking apps
- Catalogue apps
Expo
The tooling around React Native that handles builds, updates and device features, so a release is not a week of work.
- Android and iOS builds
- Push notifications
- Over-the-air updates
- Device integrations
Kotlin and Swift
Native Android and native iOS, for the cases where the platform itself is the product and a shared codebase would hold you back.
Firebase
Push notifications, crash reports and sign-in for mobile apps, without a server of your own for each.
- Push notifications
- Crash reporting
- App analytics
- Sign-in
The part that has to be right.
An application can be rewritten. Its data usually cannot, so the database decides how long the system stays useful.
PostgreSQL
The default for anything that has to be correct under load, and the one this site runs on.
- SaaS platforms
- Multi-tenant systems
- CRM and ERP
- Reporting
- Transactional work
MySQL and MariaDB
Widely used, widely understood, and usually already there when you have a Laravel or PHP application.
- Laravel applications
- Existing systems
- Management systems
MongoDB
Used where records vary in shape from one to the next, and where forcing them into columns would cost more than it saves.
- Catalogues
- Event and log data
- Content stores
Redis
Holds the things that must be fast or must not be lost between requests: sessions, queues, one-time passwords.
- Caching
- Sessions
- Background jobs
- Rate limiting
Prisma
The layer between the application and the database that keeps schema changes deliberate and reviewable.
- Schema migrations
- Type-safe queries
- Multi-tenant data
Elasticsearch and OpenSearch
Search across a large number of records, where a plain database query is too slow or too literal.
- Product search
- Document search
- Log search
Object storage
Where documents, photographs and backups live, kept out of the database so both stay manageable.
- Uploaded documents
- Photographs
- Backups
- Report exports
Turning records into something a manager reads.
A system that holds everything and reports nothing gets abandoned. These are the tools that close that gap.
Power BI
Dashboards for owners and managers, built on data pulled from your existing systems.
- Owner dashboards
- Branch comparison
- Sales and collection reporting
Metabase
Questions answered without writing SQL, which suits a team that wants its own numbers without asking us.
- Self-service reporting
- Operations dashboards
- Scheduled reports
Apache Superset
An open dashboard layer where licence cost per viewer would otherwise decide who gets to see the numbers.
- Internal dashboards
- Wide read access
Looker Studio
Lightweight reporting on Google data, usually where marketing and website figures are the question.
- Website reporting
- Campaign reporting
Apache Airflow
Schedules the jobs that move and clean data, so a report is not waiting on somebody remembering to run something.
- Nightly data loads
- Report preparation
- System-to-system transfers
dbt
Keeps the transformations behind a report written down and version-controlled, rather than living in one analyst’s file.
- Data modelling
- Report logic
- Data quality tests
BigQuery and ClickHouse
Warehouses for when the reporting volume has outgrown the database the application runs on.
- Large data sets
- Historical analysis
- Fast aggregates
Connecting to what you already run.
Most systems we build have to talk to something older. Whether that is possible is the first thing we check, not the last.
REST APIs
The connection between your web application, your mobile app and anything outside.
- Mobile app backends
- Third-party integrations
- Partner access
- Internal connectivity
GraphQL
One request that returns exactly the fields a screen needs, which helps when a mobile app is on a weak connection.
- Mobile backends
- Composite screens
- Partner APIs
OpenAPI and Swagger
A written contract for an API, so the people integrating with it do not have to ask you what a field means.
Webhooks
The other direction: another system tells yours that something happened, instead of yours asking repeatedly.
- Payment confirmations
- Delivery updates
- Status changes
Message queues
Work handed off to run in the background, so a slow third party does not hold up the person at the counter.
- Bulk messaging
- Report generation
- Retrying failed calls
Tally XML and ODBC
The two ways into Tally. Which one fits depends on your version and how your accountant works.
- Invoice export
- Ledger reads
- Voucher posting
Where AI earns its place.
Useful when a person is reading documents, answering the same question repeatedly, or searching for something they cannot name exactly.
OpenAI API
Generative AI inside an existing workflow, rather than as a separate thing somebody has to remember to open.
- Support assistants
- Internal knowledge assistants
- Document processing
- Summarisation
Anthropic Claude
Another model provider, chosen on how it handles long documents and how carefully it follows instructions.
- Document review
- Policy assistants
- Drafting from records
Google Gemini
Used where the work already sits in Google services or where its pricing suits the volume.
- Document processing
- Summarisation
- Assistants
Self-hosted open-weight models
Models running on your own infrastructure, for records that are not to leave it.
- Sensitive documents
- Internal assistants
- Offline processing
Retrieval-augmented generation
Answers drawn from your own documents and records, so the system quotes your policy rather than inventing one.
- Internal knowledge systems
- Policy and document search
- Support
- Training material
pgvector
Keeps the AI search index inside PostgreSQL, which means one database to back up instead of two systems to keep in step.
Qdrant
A dedicated vector database, used when the search index is large enough to deserve its own home.
- Large document sets
- Semantic search
Document AI and OCR
Reading figures off invoices, forms and scanned paper so somebody stops typing them twice.
- Invoice capture
- Form processing
- Scanned records
Where it runs, and how it stays up.
Unglamorous, and the reason an application is still working a year after the people who built it moved on.
Docker
The same environment on a developer laptop and on the server, which removes the commonest cause of a deployment failing.
How we work with it →Kubernetes
Worth it when you genuinely run many services. We say so when you do not, because it adds work nobody asked for.
- Multi-service platforms
- Scaling workloads
Terraform
Servers and networks described in files, so the setup can be rebuilt instead of remembered.
- Repeatable environments
- Cloud setup
- Disaster recovery
Ansible
Configuration applied to servers the same way every time, which is what keeps staging and production alike.
- Server setup
- Patching
- Deployment steps
Ubuntu and Nginx
A plain, well-understood server. Routing, SSL and serving, without a platform bill attached.
How we work with it →AWS, Azure, Google Cloud and DigitalOcean
Four places to run it. The choice follows your budget, your data location and who will manage it.
- Hosting
- Managed databases
- Storage
- Scaling
Cloudflare
DNS, caching and a layer of protection in front of the application.
- DNS
- CDN
- SSL
- Traffic protection
Git and GitHub Actions
Every change reviewable and every deployment repeatable, so a release is a routine rather than an event.
- Version control
- Code review
- Automated testing
- Deployment
Who can see what.
On most business systems this is the requirement that takes longest to get right, because it mirrors how the organisation is actually run.
Role-based access
A super admin, a branch manager, an employee, a customer, a dealer, a doctor and a teacher looking at one system and each seeing their part of it.
How we work with it →JWT authentication
The tokens that keep a mobile app, a web portal and an API talking to each other securely.
OAuth 2.0 and OpenID Connect
Signing in with an account people already have.
- Microsoft
- Apple
- Enterprise identity providers
Single sign-on
One login across several systems, which matters once staff are juggling four passwords and writing them down.
- Staff portals
- Multiple applications
- Enterprise identity
Multi-factor authentication
A second step on the accounts that can move money or export data.
- Admin accounts
- Finance roles
- Remote access
Encryption and key management
Data protected in transit and at rest, with the keys held somewhere other than the application.
- Personal data
- Documents
- Backups
Money and messages.
The two integrations almost every business system needs, and the two where the details matter most.
Razorpay
Online payments for Indian businesses: collections, links, subscriptions, refunds and the status of each.
How we work with it →Stripe
International payments and subscription billing, where you sell outside India.
How we work with it →WhatsApp Business API
Where Indian customers actually reply. What can be sent is governed by the provider and the templates they approve.
- Enquiry alerts
- Appointment reminders
- Order updates
- Payment reminders
Brevo
Transactional email that reaches the inbox: the one-time password, the receipt, the statement.
- Transactional email
- Campaign email
- Email APIs
SMS and push notifications
The messages that still matter when a customer has no data connection or no app installed.
- One-time passwords
- Delivery alerts
- Reminders
Knowing whether it works.
Software that nobody measures quietly stops being used, and nobody finds out until somebody asks for a report.
Google Maps Platform
Addresses, geocoding, service areas and field visits.
Google Analytics and PostHog
Which pages bring enquiries, and which parts of your application anybody actually opens.
Sentry
Errors reported when they happen, rather than when a customer rings to complain.
Prometheus and Grafana
Server and application health on one screen, with alerts before a queue becomes an outage.
- Server metrics
- Queue depth
- Alerting
OpenTelemetry
One slow request followed across the services it touched, which is how a vague complaint becomes a fix.
- Tracing
- Performance investigation
Uptime and synthetic checks
Somebody watching the site from outside, so the first report of an outage is not a customer.
- Availability checks
- Login journey checks
Checking it before your staff do.
Every one of these exists so that a change made today does not quietly break something that worked yesterday.
Jest and PHPUnit
Automated checks on the logic underneath, run on every change.
Playwright and Cypress
A browser driven through the real screens, so a broken form is caught before release.
- Checkout journeys
- Login and permissions
- Form validation
Appium
The same idea on Android and iOS, for apps where a bad release is expensive to pull back.
Postman
API checks that can be handed to your own team and run without us.
k6 and JMeter
Load put on the system deliberately, to find the limit before your busiest day does.
- Peak load
- Report-heavy screens
- Launch readiness
Lighthouse and Web Vitals
What a visitor on an ordinary phone actually experiences, measured rather than assumed.
Semgrep and Trivy
Automated scanning of code and containers for known weaknesses and outdated packages.
How we work with it →Systems we work alongside.
Most businesses already run something. These are the ones we are asked to connect to, extend or take over.
Tally
The accounting system most of our clients keep. We export to it or read from it rather than replacing it.
- Invoice export
- Ledger reads
- Reconciliation
WordPress
Websites we maintain, secure and extend, including where the rest of the system is custom-built.
- Business websites
- Blogs
- Landing pages
Shopify, WooCommerce and Magento
Online stores customised and connected to stock, billing and delivery.
- Store customisation
- Stock sync
- Order integration
Salesforce, HubSpot and Zoho
CRMs we integrate with, so the same contact does not have to be typed into two places.
- Contact sync
- Lead capture
- Reporting
Figma
Where screens are agreed before they are built, which is cheaper than agreeing them afterwards.
- Wireframes
- Prototypes
- Design handover
Where a technology has its own page.
Written for the reader who already knows what they are asking for. Each one says what the technology is good at, and when it is the wrong choice.
Access and security
Integrations
Cloud and delivery
Frontend and language
Databases
Where most new builds begin.
This is the stack we reach for before the requirements move it, and they usually do. It is also what this site runs on, so it is not a recommendation we avoid living with.
- Frontend
- Next.js, React, TypeScript, Tailwind CSS
- Backend
- NestJS and TypeScript
- Database
- PostgreSQL with Prisma
- Mobile
- React Native with Expo
- Caching and jobs
- Redis
- Infrastructure
- Ubuntu, Nginx, Docker, Cloudflare
- Integrations
- WhatsApp, Razorpay, Brevo, Google Maps
- AI
- OpenAI, retrieval-augmented generation, pgvector
What we ask before recommending anything.
We do not pick a technology because it is popular this year. These are the questions that actually decide it, roughly in the order they matter.
The problem
What has to change in the business once this exists. Everything else follows from the answer.
Who opens it
Ten people in one office and ten thousand customers are different systems, whatever the feature list says.
Web, mobile or both
Field staff need a phone. Back office usually does not. Building both when one would do is the commonest waste.
What it must talk to
Your Tally, your existing CRM, a machine on the floor. We check whether a route in exists before promising one.
What you already run
A working PHP system is an asset. Modernising it is often cheaper and less risky than replacing it.
Who may see what
Access rules mirror your organisation, so they take longer to agree than to build.
Who maintains it
If your own team will run it, the stack should be one they can hire for in this city.
Budget and timing
Architecture is a trade against both. We say which parts are worth the money and which are not.
You may not need a rebuild.
A system that works is an asset, even an old one. Replacing it is expensive, slow and risky, so it should be a decision you take deliberately rather than the default answer.
We work with existing PHP, Laravel, JavaScript, React, Node, MySQL and PostgreSQL applications: new features, modernisation, performance work, APIs, a mobile app on top of what you have, integrations, migration, or simply keeping it running.
You do not have to choose the stack first.
Nobody should have to decide between NestJS and Laravel before their first conversation with a developer. Tell us what you want to build, who opens it, which process you want to stop doing by hand, and what you already run. The architecture follows from that, and we put the reasoning in writing so you can argue with it.
Discuss your requirementQuestions owners ask about the stack.
Which technology is best for a web application?
There is no single answer, and anybody who gives you one has not asked enough questions. It depends on what the application does, how many people use it, what it must connect to, and what you already run.
Do you work with our existing Laravel or PHP application?
Yes, and often that is the better option. We maintain, extend, integrate and modernise existing PHP and Laravel systems. Replacing a working system is expensive and risky, so it should be a decision rather than a default.
Can you build Android and iOS from one codebase?
Usually, with React Native. Where an application depends heavily on platform-specific features, native Kotlin or Swift is the right call, and we will say so rather than force a shared codebase.
Can you add AI to software we already have?
Often yes, through its APIs or database. The useful question is not whether AI can be added but whether it removes work somebody is doing by hand today. If it does not, we will tell you.
Can you build APIs for a system we already run?
It depends on whether that system exposes a way in. Some do, some can be extended, and a few are closed. We check before committing, because the answer decides whether the rest of the plan is possible.
Can WhatsApp be integrated into our software?
Yes, through the WhatsApp Business API. What you can send is decided by the provider and the message templates they approve, so the workflow is designed around those rules rather than around what we would prefer.
How do you decide the stack for a project?
We start from the problem, the people who will open it, and what it has to connect to. The stack is the last decision, not the first, and we put the reasoning in writing so you can disagree with it.
Do we need to know what we want built?
No. Most people arrive with a process that is not working rather than a specification. Describing how the work runs today is enough to start.
Start with the problem, not the technology.
Describe how the work runs today and who it frustrates. We will tell you what is worth building, what is worth buying, and what is not a software problem at all.
- No obligation
- A reply within one business day
- Your details stay private
Start with your requirements
Seven short steps that tell us what you need. An engineer reads them before getting in touch.
Share your requirements