Web Application Development in New Zealand

Why the quotes look nothing like each other

Send the same brief to five developers for a website and you will get five numbers in roughly the same neighbourhood. Do it for a web application and you can get $50,000, $95,000 and $220,000, all defensible.

The reason is that a web application brief describes an outcome — "our customers should be able to see their orders and raise issues" — and there are several honest routes to it. One developer assembles the app from proven components and has something running in ten weeks. Another builds the core themselves because they expect your requirements to outgrow those components within a year and would rather not rebuild then.

Neither is wrong. They are different bets about your future. Ask each of them what they are building versus assembling, and what they think you will need in two years. The answer tells you more than the price does.

Four kinds of project, four different risks

An internal tool has the clearest requirements and the fastest payback, because you can walk over to the people who will use it. Scope creep is the main risk.

A customer portal adds accounts, permissions, notifications and, quietly, a support obligation: when your customers cannot log in, that is now your problem at 9am on a Monday.

A SaaS product adds multiple customer organisations sharing one system, billing, self-service sign-up, and the reliability expectations of something people pay for monthly. The software is perhaps half the work.

A marketplace adds the hardest problem in the list, and it is not technical: both sides have to show up, and neither wants to be first. Build accordingly — cheaply, and with a plan for filling one side by hand.

Define the first release by what someone can finish

"MVP" has been stretched to mean anything from a prototype to a full product. Replace it with a sentence: what can one real user complete, start to finish, without your help?

An app where a customer can log in, see their orders and raise an issue is useful even with no reporting, no admin screens and no email notifications. An app with a quarter of six different features is useful to nobody and teaches you nothing, because no one can use it for real work.

Ask each developer to describe their first release that way. The ones who can have built these before.

Permissions are the hidden cost

The question "how many kinds of user?" changes a quote more than almost anything else in the brief.

One internal team is straightforward. Staff, managers, customers and suppliers with different permissions is four applications sharing a database — every screen needs a decision about who sees what, every action needs a check, and every combination needs testing. It is not glamorous work and it is a large share of the budget.

Be explicit in the brief about who logs in and what each should never see. Adding a user type after the architecture is settled is expensive.

Ask what breaks at ten times the size

Most applications are built for the load they have. That is correct — building for imaginary scale wastes money. But you should know where the ceiling is.

Ask each developer what breaks first if usage grows tenfold, and what fixing it would cost. A good answer is specific: the reporting queries slow down, and moving them to a read replica is a week. A vague answer about the cloud scaling automatically means they have not thought about it.

Running costs are part of the price

Hosting for a small application runs $50 to $500 a month. A busy one with real data and backups is more. Add maintenance at 15% to 20% of build cost per year: dependencies get security updates, platforms deprecate APIs, and browsers change under you.

If the app has paying customers, add support. Someone has to answer when it breaks, and that is a person, not a server. Deciding whether that person is you, your developer, or a retainer is a question best settled before launch.

What to compare across quotes

• Built versus assembled. What is custom, what is off-the-shelf, and why.
• The first release, described as a task a user can finish.
• User types and permissions, listed explicitly.
• Monthly running cost and annual maintenance.
• The scaling ceiling, named, with a price to raise it.
• Ownership and exit. Code, data, hosting accounts, in writing.

Describe the job, not the screens

You do not need wireframes or a technology preference. Describe who uses this, what they are trying to finish, what happens today instead, and what that costs. Developers who build applications every week will propose approaches you had not considered — and where they disagree with each other is exactly where you should be asking questions.