Insights · 5 min read

Web application development: scope it before you build

Web application development spans a landing page and a SaaS product. The gap is scope. Here is how to pin it down before you spend.

By GGP Editorial

Web application development is a big umbrella, and the price you hear from different shops will be all over the place because each one is quoting a different thing. A marketing site with a contact form is a web app in the loose sense. A multi-tenant SaaS with user accounts, billing, and an admin panel is a web app in the real sense. The second one costs twenty times the first, and the mistake people make is pricing the second while only specifying the first.

What kind of web app are you actually building

Before you talk to a developer, get clear on the category. It changes the stack, the timeline, and the bill:

CategoryWhat it isRough build size
Marketing sitePages, forms, SEO, a CMSSmall
Internal toolDashboards, reports, workflows for your teamSmall to medium
Customer portalAccounts, documents, self-service featuresMedium
SaaS productMulti-tenant, billing, roles, integrationsLarge

Most projects sit somewhere between two rows, and the honest scoping conversation is about which row you are closest to. A portal that later needs billing is not a small upgrade. It is a different data model, so decide early whether accounts and payments are in scope.

The stack decisions that matter, and the ones that don't

Clients spend a lot of energy choosing a framework. The truth is that Vue, React, Spring Boot, Node, and Go all ship good web apps, and the framework matters less than two other choices: how you model the data and how you split the backend from the front end.

At GlobeSoft we tend to build the front end in Vue or React and the API in Spring Boot or Node, with MySQL or PostgreSQL for the data and Redis when the app needs caching or queues. That stack has carried us through 300 plus projects since 2018. What changes between projects is never the stack, it is the schema and the permission model.

One decision worth real time is whether you want a single codebase for web and mobile. If you will need an app later, plan for an API the app can talk to from day one. Retro-fitting an API onto a server-rendered app is painful, and we have seen it add a month to projects that skipped this step.

A real build: alooz.com.br

One web app we built that shows the spread is alooz.com.br, an online billboard advertising platform for the Brazilian market. It is a web application in the classic sense: a public site, a design tool where customers put together their ad, and a backend that manages orders and accounts, all in Portuguese.

The interesting part was not any single feature. It was building for a market six or seven hours away and a language we do not speak natively. That meant a Portuguese interface reviewed by someone who actually reads Portuguese, and an overlap schedule so questions did not sit for a day. It is the same delivery discipline we apply to every overseas client, from Brazil to Singapore and the United States.

What actually drives the cost

Three things move the price more than anything else. First, accounts and permissions: anonymous visitors are cheap, logged-in users with roles are not. Second, integrations: connecting a payment gateway, an email provider, or a third-party API is where timelines slip. Third, the admin side: the screens you use to manage users, content, and orders are often half the app and nobody budgets for them.

Under those three sits a baseline everyone should assume: authentication done right, HTTPS, backups, and a test environment. None of it is glamorous, and none of it is optional once real users and real money are involved. Shops that skip it to lower the quote are not saving you money, they are moving it to the month after launch.

A typical build runs in short cycles: a discovery pass to settle the data model, then working slices you can click through every week or two. That rhythm matters more than the framework choice. If you can see and test the app while it is being built, the scope stays honest.

Scope the boring parts first. If you can describe exactly what an admin can do, what a customer can do, and what happens when a payment fails, you have a buildable spec. Everything else is design polish.

GlobeSoft takes on web apps in almost any industry, as long as the work is legal, from e-commerce and finance to property management and IoT. If you are still at the scoping stage, we are happy to help you get the category and the budget right before a line of code is written.

Talk to us about your project

Need help applying this?

Tell us what you are building and where you are today. We typically reply within 24 hours.