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 runs on the first four.
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
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
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
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
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
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.
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
Widely used, widely understood, and usually already there when you have a Laravel or PHP application.
- Laravel applications
- Existing systems
- Management systems
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
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
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.
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
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.
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 →Ubuntu and Nginx
A plain, well-understood server. Routing, SSL and serving, without a platform bill attached.
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.
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
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.
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 and Firebase messaging
Transactional email and push notifications: the one-time password, the receipt, the alert.
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.
Jest, Playwright and Postman
Automated checks on the logic, the screens and the APIs, so a fix does not quietly break something else.
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
- We reply the same working day
- Your details stay private