Web Application Development Cost in Singapore (2026): Complete Pricing Guide

How much does it cost to build a web application in Singapore?

The slightly frustrating answer is that it depends on what you mean by a web application.

We have seen the term used for everything from a small internal dashboard to a SaaS platform with subscriptions, multiple account types, payment processing and integrations with several external systems. Those projects might both be called "web apps", but the amount of engineering involved is completely different.

For planning purposes, a fairly focused internal application can start from a few thousand dollars. A larger business system will usually move into the five-figure range, while complex SaaS and enterprise platforms can go much further.

The useful question is therefore not:

How much does a web app cost?

It is:

What are we actually asking the system to do?

That is how we approach scoping at retroXpect. Before worrying about frameworks or counting screens, we want to understand the workflow, the users, the data and where the application sits within the rest of the business.

This guide explains where web application development costs come from, what different budgets can realistically buy, and what businesses should look at when comparing quotations.

Web Application Development Cost in Singapore

As a rough planning guide, custom web applications in Singapore can fall into ranges like these:

These should be treated as planning ranges rather than a menu.

Two applications with roughly the same number of screens can require very different amounts of work. A dashboard that displays data from a clean, well-documented API may be relatively straightforward. A three-screen operational system containing complicated scheduling rules, permissions and integrations may take considerably longer.

The difference is in what happens behind the interface.

For businesses building an early-stage product, we have a separate breakdown of MVP development costs in Singapore.

What Do We Mean by a Web Application?

The easiest distinction is that a normal website mostly presents information, while a web application lets people perform processes and work with data.

A corporate website might contain service pages, articles, case studies and a contact form. A web application might contain customer accounts, bookings, approval workflows, payment processing, reporting, inventory management or an entire internal operations system.

Take a transport company as an example.

Its website could explain what services it provides and collect enquiries.

Its web application could allow customers to make bookings, operations staff to assign drivers, drivers to update job statuses, administrators to manage pricing and management to view operational reports.

The second system has to maintain state, enforce rules and keep data consistent across different users. That is where the additional development work comes from.

If you want a broader explanation of how these systems are built, read our guide to custom web application development.

Why Do Web Application Quotes Vary So Much?

A quotation usually reflects more than the amount of frontend work visible to the customer.

One developer might be pricing a relatively simple application that assumes happy-path behaviour (situation where everything works correctly as expected and without any errors). Another may be accounting for authentication, access control, logging, failed integrations, deployment environments, testing and the edge cases that appear once real users start using the system.

Sometimes one quote is genuinely overpriced. Sometimes the cheaper quotation simply contains less.

The difficult part for a non-technical buyer is figuring out which situation they are looking at.

Our separate guide on why web application development quotes vary goes deeper into comparing quotations, but most cost differences eventually come back to a few technical areas.

The logic of your business matters more than how your web app looks

Suppose you want a booking system.

At its simplest, a customer chooses a date, fills in a form and submits a booking. There is not much application logic there.

Now imagine the same booking system needs to understand different service durations, staff availability, vehicle availability, blackout dates, customer locations, travel time, deposits, cancellation policies and capacity limits.

The booking page may look almost identical but the code behind it is not.

Every additional rule has to interact correctly with the others. If a service requires a particular resource, for example, the system has to make sure the customer cannot book a slot simply because an employee happens to be free.

This type of logic is often where a project grows.

When we scope these systems, we spend quite a lot of time on the actual workflow because that tells us considerably more than a sitemap does.

User Roles and Permissions

Permissions are another area that sounds simple during early discussions.

A client might initially say:

We need staff and admin accounts.

Once we start mapping the workflow, there may actually be sales staff, operations staff, finance, managers, customers and system administrators, all with different access requirements.

A sales employee might be allowed to update their own opportunities but not another salesperson's. Finance might need access to invoices without access to internal sales notes. An operations manager may need visibility across several teams without being able to change user permissions.

This cannot be handled properly by hiding buttons in the frontend.

If a user does not have permission to access something, that restriction needs to be enforced by the backend as well.

The more granular the permission model becomes, the more implementation and testing it requires.

Database Design

Database work is not particularly visible during a product demo, but poor database decisions have a habit of becoming expensive later.

A relatively small application may only need users, customers and jobs. Once the product grows, the data model might also need organisations, transactions, invoices, documents, permissions, status history, inventory movements, notifications and audit records.

The relationships between these records matter.

For example, if customer information is duplicated across several tables because the system was built quickly, reporting becomes harder and inconsistencies start appearing. Changing that structure later, once the database contains live customer data, is considerably more painful than getting the fundamentals right early.

We do not believe every application needs an elaborate architecture diagram before anyone writes code. It does need a data model that makes sense.

Third-Party Integrations

Most business applications do not live in isolation.

A company might want its system connected to Stripe, HitPay, Xero, HubSpot, Microsoft 365, Google Workspace, WhatsApp or an existing ERP.

From the outside, that requirement can sound like:

Can you connect our system to Xero?

The actual work depends heavily on the API.

A good integration needs to account for authentication, available endpoints, rate limits and the way the external platform represents data. Then there is failure handling.

Suppose your application creates an invoice in an accounting platform after an order is completed. If the accounting API is temporarily unavailable, what happens?

We could fail the entire transaction, but that might be a terrible user experience. Another approach is to record the transaction successfully, queue the accounting operation and retry it later.

That creates another question. What if the first request actually succeeded but our application never received the response? A badly designed retry could create the same invoice twice.

These are normal integration problems. They are also why an "API integration" can take a few hours in one project and several days in another.

Our API integration cost guide covers this in more detail.

Frontend Complexity

Frontend development cost depends on what the interface needs to do, not simply how attractive the design is.

A standard business dashboard made using an established component system can be implemented quite efficiently. A consumer-facing platform with custom interactions, unusual responsive behaviour, live data and highly bespoke components will take longer.

There are also a lot of states that do not appear in a polished design file.

• What happens while the data is loading?
• What happens when there is no data?
• What happens when an API request fails?
• What happens when a customer double-clicks the payment button?
• What happens when a table has 50 records today and 50,000 next year?

These details are not glamorous, but production applications need to deal with them.

Admin Panels Are Often Bigger Than Expected

We hear "simple admin panel" fairly often.

Then the requirements start coming in.

Administrators need to search customers, manage accounts, edit records, review transactions, approve submissions, issue refunds, export data, generate reports, change system settings and view audit history.

At that point, the admin panel is a substantial part of the application.

For internal business software, it may actually contain more functionality than the customer-facing side.

When reviewing a quotation, check what administrative functionality is included instead of assuming an admin dashboard comes automatically with the project.

Reporting Can Become Its Own Project

Putting a chart on a page is easy.

Agreeing on what the chart is supposed to measure is sometimes harder.

Take a dashboard showing monthly revenue. Before building it, someone needs to decide whether that number includes unpaid orders, refunded orders, GST, discounts, cancelled bookings or transactions created in one month and settled in another.

The database then needs enough information to calculate the answer correctly.

Reporting gets more difficult when information comes from multiple systems. Management might want one dashboard combining sales data, operational data and accounting figures even though those three datasets originate from different platforms.

If reporting is an important part of your project, it should be scoped properly rather than added at the end.

We cover typical requirements in our guide to business dashboard development costs.

Real-Time Features

Some systems genuinely need real-time behaviour.

A fleet management platform may need vehicle positions to update continuously. A dispatch system might need new jobs to appear immediately for operators. Messaging, live inventory and collaborative systems have similar requirements.

Depending on the architecture, this can involve WebSockets, event-based processing, queues or real-time database subscriptions.

It also introduces new failure states. Connections drop. Devices go offline. Events can arrive late. Clients reconnect with stale state.

None of this means real-time functionality should be avoided. It just means there should be a reason for using it.

We would rather build a simpler polling-based system that works reliably than introduce additional infrastructure because "real-time" sounded good during the sales meeting.

Payment Processing

Payment integrations deserve more attention than a checkout button usually suggests.

A real payment flow needs to consider successful payments, failed payments, abandoned transactions and refunds. Subscription products introduce renewals, failed recurring payments, upgrades and cancellations.

The application also needs a reliable source of truth.

For example, we would generally avoid treating a customer as paid simply because their browser reaches a success page. The application should confirm the payment with the provider, typically through a server-side verification process or signed webhook.

Otherwise, you end up trusting something that exists on the user's device to determine whether money was actually received.

The difference is small from the customer's perspective. Technically, it matters.

SaaS Applications

SaaS projects become more expensive because the software is being designed as a product rather than as a tool for one organisation.

A normal internal system might contain one company and its staff.

A SaaS platform needs to understand different customer organisations, their users, subscriptions, permissions, billing state and potentially their own configuration.

This is where multi-tenancy enters the picture.

Data belonging to Company A cannot accidentally be exposed to Company B. Subscription limits need to be enforced. Users join and leave organisations. Companies upgrade plans. Accounts get suspended or cancelled.

All of that sits underneath whatever the main product actually does.

We discuss this separately in our guide to SaaS development costs in Singapore.

What Can You Build for Around S$5,000?

A useful web application does not automatically need a five-figure budget.

A tightly scoped internal system could, for example, have administrator and staff accounts, a customer database, job creation, status tracking, basic search and a simple dashboard.

If the workflow is well understood, the interface uses relatively standard components and there are no particularly complicated integrations, that can be a sensible small project.

The mistake is expecting that budget to also include an advanced mobile experience, live GPS, accounting integrations, complex analytics, six different permission levels and an AI assistant.

Software budgets become unrealistic when several individually reasonable requests get combined without looking at the engineering work behind them.

What Pushes a Project Towards S$20,000 to S$50,000?

Take the same operations system and continue adding functionality.

Customers now have their own accounts. Drivers have another interface. Management needs reporting across branches. The system needs live location information, automated dispatch, payments, accounting integration, notifications, audit logs and document generation.

At some point it stops being a small operations tool and becomes a core business platform.

The increase in cost is not caused by making the dashboard prettier. It comes from the number of systems, rules and states the software is responsible for.

If you want a feature-by-feature breakdown, read what makes a web application expensive.

MVP Development (Minimum Viable Product)

"MVP" has become one of those terms that gets stretched until it can mean almost anything.

To us, an MVP is the smallest version of the product that can properly test the important assumption behind it.

Suppose you are building a marketplace. The first version might need accounts, listings, search, enquiries and basic moderation.

It probably does not need an AI recommendation engine, a loyalty programme, five subscription tiers and native mobile apps on day one.

Adding those features might feel like progress, but they also delay the point where actual users can start telling you whether the core product is useful.

This applies to internal software too. Start with the workflow that is causing the biggest operational problem. Once that works, expanding the platform is far easier because the next set of decisions can be based on real usage.

See our full MVP development cost guide.

Custom CRM Development

There are plenty of good CRM products already available, so building another one from scratch should not be the default answer.

If HubSpot, Salesforce, Zoho or another product fits your process well, use it.

Custom CRM development starts to make sense when the workflow becomes unusually specific or employees are spending too much time working around the software.

A common sign is when the "CRM" actually consists of a real CRM plus several spreadsheets, WhatsApp conversations, shared folders and somebody manually copying information between them.

At that point, the problem may not be the CRM itself. The business may need a system that joins those workflows together.

A custom implementation could include leads, customer records, sales pipelines, quotation generation, tasks, documents, activity history, automation and reporting. Whether that is a S$5,000 project or a S$50,000 project depends entirely on how those pieces need to work together.

Read our custom CRM development cost guide.

Customer Portals

Customer portals are common because they can sit on top of an existing business rather than replacing everything behind it.

A customer might log in to check an order, download documents, make payment, submit a request or view their service history.

The portal itself is often not the difficult part.

The bigger question is where that information comes from.

If customer records are already stored in an ERP or legacy application, we need a reliable way for the new portal to retrieve and update the correct information without compromising the existing system.

The integration can therefore cost more than the interface.

We cover the common architectures and costs in customer portal development cost in Singapore.

Booking Systems

Booking systems are another good example of a project that becomes more interesting once you look beneath the interface.

A simple scheduler can be built fairly quickly.

A real operating business may need the system to understand employee availability, service duration, locations, travel time, resource availability, cancellation rules, buffer periods and deposits.

Some businesses should simply use an existing booking platform. There is no point custom-building solved functionality for the sake of owning the code.

Custom development becomes more reasonable when booking is tightly connected to the way the business operates, particularly when it needs to trigger dispatching, payment, inventory, customer records or other workflows.

See booking system development cost in Singapore.

Internal Business Systems

Some of the most useful software we build is not customer-facing at all.

A company may already be operating successfully, but the internal process behind the scenes has become a mixture of spreadsheets, emails, WhatsApp messages and manual data entry.

At a small scale, that works.

Eventually somebody spends an hour every morning reconciling information from three systems. Then another employee copies those records into a spreadsheet for management reporting. Mistakes creep in, and every increase in business volume creates more administrative work.

At that point, the cost of the current process matters just as much as the development quotation.

A custom internal system can centralise the workflow, automate repetitive actions and make the same data usable across departments.

The goal is not to digitise every part of the company. It is to remove the parts that are wasting time or causing errors.

Read our internal business system development cost guide.

Build or Buy?

Because we develop custom software, it would be very easy for us to say custom software is always the answer.

It isn't.

If Shopify solves your e-commerce requirements, building a commerce engine from scratch is usually a waste of money.

If Xero works for your accounting, we are not going to recommend recreating Xero.

The same logic applies to authentication, email delivery, payment processing, file storage and many other solved problems. Mature infrastructure exists for a reason.

Where custom development becomes useful is in the part of the business that generic software does not understand.

Perhaps you have a very specific operational workflow. Maybe several existing platforms need to behave like one system. Perhaps your staff are spending hours every week moving information around because the software does not match how the company actually operates.

There is also a middle ground. Quite a lot of good business software is a combination of established platforms and custom code connecting the important parts.

Our build vs buy software guide for Singapore SMEs goes into the trade-offs.

Freelancer or Development Agency?

A strong freelancer can be the right choice for a small project.

There is no useful reason to pretend otherwise.

What matters is when the project needs significant frontend work, backend engineering, database design, infrastructure, testing and ongoing support at the same time.

The question then becomes less about whether one person is technically capable of doing all of it and more about capacity and continuity.

If the developer is occupied with a production issue, who is building the next feature? If they disappear for two weeks, who understands the deployment? If an architectural decision needs another set of eyes, who reviews it?

Agencies solve some of these issues by having more than one person involved in delivery, although that naturally affects cost.

Neither model is automatically better. The right one depends on how much risk and technical management the client is comfortable holding.

See freelancer vs software agency in Singapore.

Offshore Development vs Singapore Development

Offshore development can be significantly cheaper on an hourly basis.

Sometimes it is an excellent option.

What really matters is whether the team can deliver the system properly.

A capable offshore team with strong technical leadership and clear communication can outperform a local company. A cheap team working from vague requirements can turn into an expensive project once rework starts.

The things we would look at are fairly practical: how requirements are handled, who owns technical decisions, how frequently you can communicate with the team, how the code is documented, where infrastructure is hosted and what happens after deployment.

Geography on its own does not tell you whether a development team is good.

We discuss the trade-offs in offshore vs Singapore web development.

How We Think About Architecture

We prefer architecture that fits the current problem and has a sensible path to grow.

There is a tendency in software development to make architecture sound more sophisticated than it needs to be. A startup expecting its first few hundred users usually does not need fifteen microservices and a Kubernetes cluster.

Every moving part has a maintenance cost.

For many applications, a properly structured monolith with a relational database is a very good place to start. It is straightforward to develop, easier to test and much easier for another engineer to understand.

If a particular service later needs to scale independently, or there is a genuine technical reason to separate it, we can do that then.

Our typical stack includes technologies such as React, Next.js and TypeScript on the frontend, with Node.js handling server-side application logic. PostgreSQL is a common choice when the application's data is relational. MongoDB can make sense for other data models, while Redis is useful where caching or short-lived state is needed.

Infrastructure might run on Vercel alongside managed database and cloud services, depending on what we are building.

We do not choose a stack because its logos look impressive on a proposal.

The application architecture should match the data, workload, integrations and people who eventually have to maintain it.

Our full-stack development guide explains how the different parts fit together.

Security Is Part of the Build

Security work is easiest when it is part of normal development rather than a checklist added before launch.

At a basic level, that means enforcing permissions on the server, handling authentication correctly, validating incoming data, protecting secrets and controlling access to production databases.

Some applications will need significantly more.

The required security model depends on what the software stores and what happens if something goes wrong. An internal marketing tool does not need to be designed like a financial platform.

There is also a difference between saying software is "secure" and being able to explain what controls have actually been implemented.

We prefer the second one as we believe that once our clients understand how we are able to implement security, this creates a layer of trust between us and our clients.

Deployment and Infrastructure

The project is not finished when it works on localhost.

At some point the application needs to run somewhere, and that production environment needs to be reasonably repeatable.

A typical setup may involve separate development and production environments, DNS, SSL, application hosting, databases, file storage, environment variables, backups and some form of monitoring.

For larger applications, staging environments and automated CI/CD pipelines become more useful.

We generally prefer automated deployments where possible. Manually uploading files to a server and hoping somebody remembers the correct procedure next year is not a particularly good deployment strategy.

Testing

The amount of testing should reflect what can go wrong.

If an icon is three pixels out of place, the consequence is minor.

If a normal user can access another customer's invoices, the consequence is rather different.

Critical workflows deserve more attention. That includes authentication, permissions, payments, important calculations and anything that changes business data.

Depending on the project, we may use a mixture of unit tests, integration tests, API testing and end-to-end testing alongside normal user acceptance testing.

There is no prize for having the largest automated test suite. The useful question is whether the parts of the system that matter are adequately covered.

How Long Does Web Application Development Take?

A focused application can take several weeks. Larger systems can take several months, particularly when external integrations, migration or substantial UI work are involved.

The usual process is not especially mysterious.

We first need to understand what the application is replacing and what users actually need to do. From there we define the initial scope, work out the main data structures and technical architecture, design the important interfaces and start development.

Testing tends to happen throughout the build, although there will usually also be a more deliberate UAT phase before production deployment.

After launch, there is almost always some iteration. Real users are exceptionally good at finding workflows and edge cases nobody mentioned during the first meeting.

For a more detailed breakdown, read how long it takes to build a web application in Singapore and our guide to the web application development process.

What Happens After Launch?

Production software will change.

Browsers change, dependencies change and third-party APIs change. Users also start asking for things once they understand what the system can do.

Some of those requests will be new features. Others will be small improvements that only become obvious once the application is being used every day.

There is also the less exciting maintenance work: monitoring, backups, dependency updates, security patches and dealing with the occasional production issue.

The required support arrangement depends heavily on how important the system is.

A small internal reporting tool can probably tolerate a slower response time. An application processing revenue throughout the day cannot.

Read our web application maintenance cost guide for a more complete breakdown.

Sometimes You Do Not Need a Web Application

This is worth saying because custom development is not always the correct solution.

Sometimes the problem is simply that two pieces of software are not communicating.

For example, a company may want a new enquiry to create a CRM lead automatically, assign it to a salesperson, send a confirmation email and update a reporting dashboard.

That may not require a new application at all.

A workflow automation tool such as n8n, combined with the APIs of the existing platforms, may solve the problem with far less development.

We use this distinction a lot when discussing projects. If automation handles the requirement cleanly, building an entire custom system around it makes little sense.

Our existing business automation guide covers this area in more detail.

Better Requirements Produce Better Quotes

One reason software quotations vary so much is that developers are often quoting against very different assumptions.

Take a brief like:

We need a CRM with customer accounts, booking and payment.

It sounds reasonably specific, but there are still dozens of unanswered questions.

Can customers change or cancel bookings? Are refunds supported? Does every staff member see every customer? Are there different permission levels? Does the CRM already exist, or are we building it? Which payment provider is being used? What happens after a successful payment? Does management need reporting?

Two development teams can read the same brief, make different assumptions about those questions and come back with completely different scopes and prices.

You do not need to write a fifty-page technical specification before speaking to a developer. In fact, we generally find that a clear explanation of how the business currently works is more useful than a document filled with technical terminology.

Start with the workflow.

Explain who uses the system, what they are trying to accomplish and what happens from beginning to end. If different users have different permissions, describe them. If the system needs to communicate with existing software, tell the developer what those platforms are and what information needs to move between them.

It also helps to separate what the first version genuinely needs from features that can be added later. Without that distinction, an initial scope can quickly become a collection of every idea anyone has had for the product.

Existing material is useful too. If the current process runs through spreadsheets, show the spreadsheets. If employees coordinate jobs through WhatsApp, explain how that works. Screenshots of an old system, sample invoices, forms and even rough process diagrams can provide more context than a polished requirements document.

Before requesting a quotation, we would ideally want to understand:

• what problem the application is meant to solve
• who will use it
• the main workflow from start to finish
• the different user roles and permissions
• which features are required for the first release
• which systems or APIs it needs to connect to
• whether existing data needs to be migrated
• approximate user or transaction volume
• any important reporting requirements
• your target timeline and rough budget range

You do not need to know which database to use, how the API should be structured or whether the frontend should be built with React. Those are technical decisions the development team should be able to recommend.

What you should be able to explain is how the business works today and what you want the software to improve.

The clearer that picture is, the fewer assumptions developers have to make. That generally leads to more accurate quotations and makes it much easier to compare proposals properly.

If you are preparing to approach developers, our software development requirements checklist covers what to put together before requesting a quote.

How retroXpect Approaches Custom Web Application Projects

Our first conversation is usually about the business rather than the technology.

We want to understand what the current workflow looks like, where it breaks down and what the new system needs to change.

From there, we can work out whether the project actually requires custom software.

Sometimes it does, sometimes it doesn't.

Sometimes an existing SaaS platform plus a small integration is enough. In other cases, there is already a decent system in place and the real problem is one missing workflow that should be automated.

When we do build a custom web application, we generally handle the application as a complete system: frontend, backend, database architecture, authentication, permissions, API integrations, deployment and the infrastructure required to run it.

We also try to keep the codebase understandable.

There is very little value in delivering an unnecessarily complicated architecture that requires the original developer to explain it every time somebody needs to make a change.

Good software should still make sense six months later and years down the road.

How to Keep Development Costs Under Control

The most reliable way to reduce a software budget is to reduce the amount of software that needs to be built.

That sounds obvious, but it gets forgotten quickly once feature discussions start.

Consider an operations platform.

The first version might need customer records, job creation, employee assignment and job statuses.

Once people start brainstorming, the same project suddenly contains route optimisation, live GPS, automated invoicing, customer apps, AI scheduling and predictive analytics.

Those may all be useful eventually.

The question is whether they need to exist before anyone can use the core system.

When we scope version one, we prefer separating things that are operationally necessary from things that would simply be nice to have.

A smaller first release is easier to build, easier to test and gives you real information about what users actually need next.

Frequently Asked Questions

How much does it cost to build a web application in Singapore?

A focused custom web application can start from a few thousand dollars, while larger business systems and SaaS platforms can move well into the five-figure range.

The final cost depends mainly on the workflow, business logic, user roles, integrations, data structure and infrastructure involved.

See the pricing breakdown at the start of this guide for typical project ranges.

Can I build a custom web application for S$5,000?

Yes, provided the scope fits the budget.

A focused internal tool or lean MVP with a clear workflow may be realistic around that level.

A production SaaS platform with multiple integrations, complex permissions, subscriptions and real-time functionality is a very different project.

Rather than asking whether a web app can be built for S$5,000, ask what useful version of your application can be built for S$5,000.

How long does it take?

A small application can take several weeks. More involved systems may require several months.

The timeline depends heavily on how clear the requirements are, how much custom design is required, the number of integrations involved and how quickly decisions and feedback are provided during development.

What is the difference between a website and a web application?

A website mainly presents information.

A web application contains application logic and lets users work with data or complete processes such as bookings, payments, account management, reporting or internal operations.

Is custom software always more expensive than SaaS?

Upfront, usually.

An existing SaaS provider spreads its development cost across many customers, so it is difficult for custom software to compete purely on initial price.

Custom software becomes more interesting when the existing platform does not fit the workflow, requires a lot of manual work or becomes expensive at the scale you are operating at.

Should I build an MVP first?

For a new product, generally yes.

The first release should be large enough to test the main product properly, but small enough that you are not spending months building features based entirely on assumptions.

For internal systems, we often apply the same idea by starting with one operational workflow and expanding from there.

What technology should my web application use?

It depends on the application.

We commonly work with React, Next.js, TypeScript, Node.js and modern database systems, and much more.

That does not mean every application should use exactly the same stack. Technology choices should follow the requirements rather than the other way around.

Do I own the source code?

This should be stated clearly in the development agreement before work begins.

You should also understand who controls the source repository, hosting account, domain, database and third-party service accounts used by the project.

How much does web application maintenance cost?

There is no fixed number because support requirements vary significantly.

A small internal application may only need occasional updates. A business-critical platform may require monitoring, faster response times, regular maintenance and ongoing development.

Our web application maintenance cost guide breaks this down further.

Final Thoughts

There is a reason developers are reluctant to answer "How much does a web app cost?" with one number.

The term covers too much, however an estimate may be provided based on the developer's initial understanding of your project.

A small internal application that replaces a spreadsheet is one engineering problem. A SaaS platform with subscriptions, multi-tenancy, payments, reporting and several external integrations is another.

When you compare quotations, look at what each team has actually included and what assumptions they have made.

• Ask how the system will be structured.
• Ask how permissions are handled.
• Ask what happens when an integration fails.
• Ask what testing is included.
• Ask who controls the source code and infrastructure.

You do not need to become a software engineer before hiring one. You should, however, expect the people building your application to be able to explain these decisions without hiding behind technical jargon, hoping the customer would not understand.

That is also how we approach projects at retroXpect.

If you already have a workflow, spreadsheet, existing system or rough project brief, send it over. We can look at what is happening today, work out what actually needs to be built and scope the first version from there.

See the list of services we provide or some case studies and success stories.