Users log in and see different things
The moment you have accounts, roles and permissions, you are building software. Plugin-based permission systems on a CMS get fragile fast and are a recurring source of security problems.
Delhi NCR
Web application development in Delhi where a website stops being enough.
Portals, dashboards, booking systems and SaaS products. Different budget, different timeline and a different failure mode from a website.
Overview
Where a site becomes an application
A web application is software that does something rather than a site that says something: logins, roles, data, workflow and rules. It costs several times a website and takes months rather than weeks. The most expensive mistake in this market is scoping an application as a website, discovering the difference in month three, and paying for both.
There are rules, not just pages
Pricing logic, approval chains, eligibility, scheduling conflicts. Rules that live in someone's head today have to be written down precisely before anyone builds them, which is most of the discovery work.
Data has a life of its own
Records created, edited, related to other records, reported on and audited. Once data outlives the page that created it, you need a data model rather than a form.
Someone will integrate with it
Payment, accounting, ERP, SMS, WhatsApp, a partner API. Integration is where application budgets overrun, so we scope each one explicitly with its failure behaviour named.
It has to keep working
Applications need monitoring, error tracking, backups, a deployment process and someone on call. A website that breaks is embarrassing; an application that breaks stops your operation.
And when you do not need one
If what you actually want is a good website with a form, say so and save the money. We would rather tell you that in week one than build you software you did not need.
Comparison
Website, application, or product
| Website | Web application | SaaS product | |
|---|---|---|---|
| Purpose | Inform and convert | Do work internally or for customers | Sell as a product |
| Typical timeline | 2 to 9 weeks | 3 to 9 months | Ongoing |
| Users | Anonymous visitors | Known, logged in, with roles | Paying subscribers |
| Fails when | Nobody enquires | The workflow does not match reality | Nobody renews |
| Needs after launch | Content updates | Monitoring, support, iteration | A product team |
The middle column is where most Delhi enquiries actually sit: a portal, a dashboard or a booking system for an existing business rather than a startup product.
Detail
What to ask before you hire
| Ask them | A good answer sounds like | Walk away if |
|---|---|---|
| Who owns the work and files? | You do, unconditionally, in the contract | Ownership depends on staying with them |
| Can I see three live examples? | URLs you can open and check yourself | Screenshots and a portfolio PDF |
| What is explicitly not included? | A written list with change pricing agreed | Everything is included, which means nothing is defined |
| How will we know it worked? | A metric agreed before the work starts | They show you the visuals again |
The last question is the one that separates most of the field, because answering it commits them to a number.
What to avoid
Where application projects go wrong
| Problem | What it costs |
|---|---|
| Scoped as a website | Budget and timeline are wrong from day one |
| Rules never written down precisely | Endless change requests once building starts |
| Roles designed after the screens | Permissions bolted on, which is how they leak |
| Integrations assumed to be simple | The largest single source of overrun |
| No error tracking or monitoring | You find out from a customer |
| No deployment process | Changes made directly on production |
| Nobody owns it after launch | Dependencies rot and it stops being safe to change |
FAQ
Common questions
What is the difference between a website and a web application?
A website informs and converts. An application does work: logins, roles, data, rules and workflow. The practical difference is budget and timeline, weeks against months, and scoping one as the other is the most expensive mistake in this space.
How long does a web application take?
Three to nine months for a genuine application, depending on how many rules and integrations it carries. If someone quotes an application in four weeks, they are describing a platform build with a different label.
What technology should we use?
Something with a large developer pool in India so you can hire and get second opinions. The stack matters less than whether the next developer can pick it up, and whether it is documented well enough for them to.
Can you build a customer portal?
Yes, and it is the most common request in this category: customers logging in to see their orders, documents, tickets or account. The work is mostly in the roles, the data model and the integration with whatever system already holds that data.
Do you build SaaS products?
Yes, and it is a different commitment from a portal. A product needs iteration, support and a roadmap rather than a launch. We will be honest about whether you are resourced for that before starting.
What happens after launch?
Applications need monitoring, error tracking, backups, security updates and someone who responds. Agree ownership at the start, because an unmaintained application ages faster and more dangerously than a website.
Will we own the code?
Yes, unconditionally on final payment, including the repository and deployment documentation. Custom code you do not own is the worst outcome: you paid for bespoke work and still cannot leave.
How do you price an application?
After discovery, because pricing one before the rules are written down produces a number that is wrong for both sides. Discovery itself is a small, fixed, separately quoted piece of work that produces a specification you own regardless of who builds it.
Next step
Tell us what you need.
Send us what you are trying to fix and we will tell you what it takes, what it costs, and whether we are the right people for it. If we are not, we will say so.