Web application development is the building of software that runs in a browser and does work for the people using it: a customer portal, an internal dashboard, a marketplace, a SaaS product. It differs from a website in that people log in and change things, so it needs accounts, permissions, state and a database behind it.
Success depends less on the feature list than on whether the app loads quickly on an ordinary phone over an ordinary connection, whether sign-up survives a bad network, and whether the second screen gets as much care as the landing page. Those are engineering decisions made early, and they are expensive to retrofit.
We build on React and Next.js because they are widely known, so your team or your next agency can maintain what we hand over without learning a framework only we understand.
Our work
A media marketplace, a booking platform and an internal records app, with the full write-up behind each.
Montage India
3
media types: video, images and audio
A stock media marketplace with watermarked previews, Razorpay checkout and GST invoices. 4K files of several gigabytes upload from the browser straight to S3.
How we built and rebuilt Montage India's marketplace →Healthcare marketplace · India
8
days from first commit to a working patient flow
A web app where patients find a doctor, book a slot, pay and join a video consultation, with each hospital's data kept apart. Live in beta.
How a healthcare marketplace went from first commit to live beta →Dalmia Resorts International
12
resort properties in one database
A browser app with separate dashboards for support executives, verifiers and admins, reachable only from office networks.
How Dalmia Resorts' support team finds any member in one search →Hiring from outside India? Read how our distributed team delivers for US clients: overlap hours, written specs and who actually writes the code.
Setting a budget? Read what web application development costs in 2026, with typical weeks by app type.
Not sure whether to start on the web or in the app stores? Read which to build first, a web app or a mobile app, including what a PWA can do on iPhone.
What we build
All four are held to the same engineering standard, and each is scoped in writing before a line of code is written.
Every release is checked on a real phone before it reaches production, not only in a desktop browser.
What you get
They are included by default, and they decide whether an app keeps working well after launch day.
01
We set a load-time target on a mid-range Android phone and hold the build to it. Most web apps are tested only on the developer’s own machine, which is why they feel slow to everyone else.
02
Keyboard navigation, focus states, colour contrast and proper form labels. They are cheap to build in and expensive to add later, and they make the app easier for every user.
03
Automated tests on sign-up, checkout, permissions and anything that touches money. We aim them at the paths whose failure you would hear about, rather than at a coverage percentage.
04
Continuous deployment, error tracking and uptime alerts wired in before launch, so a broken release is something you learn from a dashboard rather than from a customer.
How we work
The range is scope, not uncertainty. Your scope and milestones go in writing once discovery is done.
01 · Discover
1 week
Who logs in, what they need to accomplish, and what has to integrate. We map the screens before designing any of them.
02 · Design
1-2 weeks
Key screens designed and the schema agreed. Design is part of the build, so you never commission it as a separate engagement.
03 · Build
4-10 weeks
A working, deployed environment at the end of each sprint, on a URL you can open and send to a colleague.
04 · Harden
1 week
Load times measured on real devices, accessibility pass, security review, and the automated test suite finished.
05 · Launch
~1 week
Go-live, monitoring, documentation and a walkthrough for whoever maintains it next.
Fit check
Saying no early is cheaper for both of us than discovering the mismatch in week three.
Either works. Send the spec, or describe what people need to do, and we will turn it into a written proposal you can schedule. The call and the proposal cost nothing.
Real questions
The questions we get asked most, answered directly.
Five things move the cost of a web app more than anything else. How many user roles need their own screens and permissions. Whether money changes hands, with refunds and payouts to handle. Whether several customer organisations share one app with their data kept apart. How many outside systems it talks to. And whether anything updates live, such as chat, notifications or video calls. A single-role internal dashboard is the smallest build; a multi-tenant marketplace with payouts and live video sits well above it. The scope goes in writing before work starts, and we bill time-and-materials against it or run a monthly retainer for an ongoing roadmap.
Six to fourteen weeks for most projects, measured from signed scope to production. A focused internal dashboard lands near the bottom of that range. A marketplace or SaaS product with billing, multiple roles and third-party integrations lands near the top. Discovery and design add one to three weeks before the build clock starts, and we would rather spend that time than discover in week eight that the wrong thing was built.
React with Next.js on the front end, Node.js or NestJS on the back end, PostgreSQL for data, deployed on AWS or Vercel. We choose these because they are mainstream: you can hire for them anywhere, and any competent agency can take over the codebase. We do not build on a proprietary framework, and we will use something different when your existing team already runs a different stack well.
For most products, the web app. It reaches every device through a link, needs no store review, and a fix can go live the same day. Start with a mobile app when the product depends on what a browser handles poorly: dependable offline use, background location, or heavy camera and video processing. Plenty of platforms end up with both, and building the web app first tends to work well, because it settles the flows and the API before a phone app reuses them. On the healthcare marketplace we built, the web app and the Android app call one API, and the web app went live first.
Yes, and we test on real devices rather than a resized desktop browser. We set a load-time target on a mid-range Android phone at the start and hold the build to it. This matters in India, where a large share of traffic arrives on mid-tier phones over variable connections, and an app tuned only on a developer’s laptop will feel broken to those users while looking perfect in the demo.
Often, yes. We start with a short paid audit of the codebase, the infrastructure and the test coverage, and report back on what is salvageable and what is not. Sometimes a rewrite costs less than continuing, and we will show the reasoning rather than assert it. Taking over someone else’s code is normal work; inheriting it without an audit is how estimates go wrong.
Ready when you are
Describe the users and the job they log in to get done. You will get a straight answer on scope and timeline, and on whether we are the right team for it.
