Will you quote a fixed price for the whole thing?

For a defined phase, yes. For an entire product described in a conversation, no — and neither should anyone else. A fixed price on an undefined scope only ever resolves one of two ways — the work gets cut to fit, or the developer absorbs months of unpaid work and the relationship deteriorates. We break the product into phases, define each one in writing, price that phase, and you decide at the end of each whether to continue. You can stop after any phase with something that works.

What goes into the first phase?

The smallest version that genuinely removes the pain you described, not a demonstration. Typically that is authentication, the core data and the two or three screens where the actual work happens, deployed and used by real people. Everything else you asked for is written down in a separate list with a line explaining why it is not in phase one. That list is not a rejection — it is the plan for later, once real usage has told us which items still matter.

We are replacing spreadsheets and messaging apps. Where does that data go?

Into the migration plan, which we scope before the build rather than at the end. Exported data almost always needs cleaning — duplicates, inconsistent formats, records that only made sense to the person maintaining them. We would rather discover that in week one than during launch week. Sometimes the honest recommendation is to bring across only active records and archive the history as files.

How do we know it is secure?

Access rules are enforced on the server and in the database, never only in the interface, and they are tested by attempting to break them — logging in as one user and trying to reach another user's records directly. Secrets stay out of the codebase. Dependencies are kept current. What we will not do is claim it cannot be breached, because nobody can say that honestly. What we can commit to is a specific set of controls, tested, plus monitoring that tells you when something is wrong.

What happens when something breaks at two in the morning?

Error monitoring is built in from the first phase, not added after the first incident, so failures are reported with the context needed to diagnose them rather than arriving as a user saying it did not work. Backups run and get restore-tested. The support arrangement after launch — response times, what counts as urgent, what it costs — is agreed in writing before launch rather than improvised during the first outage.

Can our own developers take the code over later?

Yes, and it is built on that assumption. Standard framework, standard database, your repository, documented environment variables, and a deployment another team can take over. If you eventually hire engineers, they should be able to read this and continue rather than announce that it all has to be rewritten.

Web Development & Engineering

A custom web application built in phases you can actually stop after

Auth, database, roles and billing — scoped down to a first version that solves the real problem, shipped in stages you can see working before the next one starts.

From: $5,000–$40,000
Typical time: 2–5 months
Usually bought by: Startups, internal teams

What this actually solves

Two very different buyers arrive at this work with the same underlying problem, which is that a process has outgrown the tools holding it together.

The first is an established business running its operations across spreadsheets, shared documents and group chats. It worked at thirty orders a month. At three hundred, with forty people involved, things fall through — a job nobody picked up, a version of a file that was not the current one, a customer chased twice and another not at all. The cost is not theoretical. It is measurable in rework, in staff hours spent reconciling, and occasionally in a customer lost. The second is a founder building a product to sell, where the software is the business rather than a support function.

In both cases the software is not the hard part. The hard part is deciding what to build. An initial description is almost always a six-month project, described in a twenty-minute conversation, containing several features that will turn out not to matter and one that turns out to be the whole point. Building the described version means discovering nine months in, having spent the budget, that the priorities were wrong — and by then the business has changed anyway.

So the first work is compression: finding the smallest version that genuinely removes the pain, getting it into real hands, and letting actual usage decide what comes next. This is not a way of doing less. It is how you avoid paying for the wrong thing at full price.

What we do, and in what order

Cut the scope, in writing. We take your description and produce two lists: what is in version one, and what is deliberately not, each with a one-line reason. Then the questions that must be answered before anything is built, because the wrong assumption here costs weeks. You approve both lists before any code is written. Three to five days.
Map the data and the permissions. What entities exist, how they relate, what each record must record about who did what and when. Then roles — who can see what, who can change what, who can approve. The number of distinct roles is one of the biggest multipliers on effort in this entire category, so it is settled explicitly rather than discovered. Three to five days.
Build the foundations. Authentication, the database schema, the permission layer enforced on the server, deployment pipeline, and error monitoring — all of it before the first feature, not after the first incident. Environments are separated so nobody is ever testing against live data. One to two weeks.
Ship features one at a time, each deployed and demonstrated. Every feature is built, deployed to a staging environment and shown to you before the next starts. This is the mechanism that keeps a long project honest — you see progress you can click on every week, and a misunderstanding costs days rather than a quarter. Four to twelve weeks, depending on the phase.
Billing, if the product charges money. Subscription plans, trials, upgrades, downgrades, failed payments and the emails around them, plus the tests for the states people forget — what a user sees when their card is declined, what happens to their data when they cancel. Money in the system raises both the price and the obligation, and it is scoped as its own block. One to two weeks.
Test with real people and real data, then hand over. Actual users doing actual tasks while we watch, because that is when you find the thing everyone assumed was obvious. Then migration of existing data, monitoring confirmed live, backups restore-tested, documentation and a support arrangement agreed in writing. Two to three weeks.

What moves the price

The range is $5,000–$40,000 across 2–5 months, and three factors dominate.

How many distinct kinds of user exist. Two roles and five roles is not a difference of two and a half — every screen, every rule and every test multiplies. When a role is introduced late, previously finished work has to be reopened. This is the most commonly underestimated cost in the whole category.

How many other systems it has to speak to. An application that stands alone is predictable. One that must exchange data with an accounting package, a CRM, a courier service or a legacy internal system inherits every constraint of those systems, including their outages and their poor documentation. Each integration is scoped individually.

Whether money moves through it. Payments bring subscription states, refunds, failed charges, invoices, tax handling and a materially higher standard for reliability and record-keeping. It is a legitimate and common requirement, and it is not a small addition to an otherwise finished application.

What usually goes wrong

A fixed price is agreed on a scope that only exists in conversation. You say you need a simple dashboard, a number is agreed, and by month three three more features have been described as though they were always implied. Now the choice is a bad relationship or months of unpaid work, and often both. The fix is not a bigger number — it is either a written scope specific enough to argue from, or phases with their own prices and a genuine decision point at the end of each.

Error monitoring and logging are left until later. They feel like infrastructure rather than progress, so they get deferred. Then something fails intermittently for one customer on one browser, and there is no record of it — the entire diagnosis depends on a user's recollection of what they clicked. Monitoring goes in with the foundations, before the first feature, because its value is entirely retrospective.

The first phase is scoped as an impressive demonstration rather than a working tool. Everything is half-present: several screens exist, none of them completes a real job end to end, and nobody in the business can actually use it for anything yet. That project has no natural stopping point and no way to prove its worth, so it just consumes budget until someone loses patience. Phase one should be narrow and finished — fewer things, each of them genuinely usable by real people on real work.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Will you quote a fixed price for the whole thing?: For a defined phase, yes. For an entire product described in a conversation, no — and neither should anyone else. A fixed price on an undefined scope only ever resolves one of two ways — the work gets cut to fit, or the developer absorbs months of unpaid work and the relationship deteriorates. We break the product into phases, define each one in writing, price that phase, and you decide at the end of each whether to continue. You can stop after any phase with something that works.
What goes into the first phase?: The smallest version that genuinely removes the pain you described, not a demonstration. Typically that is authentication, the core data and the two or three screens where the actual work happens, deployed and used by real people. Everything else you asked for is written down in a separate list with a line explaining why it is not in phase one. That list is not a rejection — it is the plan for later, once real usage has told us which items still matter.
We are replacing spreadsheets and messaging apps. Where does that data go?: Into the migration plan, which we scope before the build rather than at the end. Exported data almost always needs cleaning — duplicates, inconsistent formats, records that only made sense to the person maintaining them. We would rather discover that in week one than during launch week. Sometimes the honest recommendation is to bring across only active records and archive the history as files.
How do we know it is secure?: Access rules are enforced on the server and in the database, never only in the interface, and they are tested by attempting to break them — logging in as one user and trying to reach another user's records directly. Secrets stay out of the codebase. Dependencies are kept current. What we will not do is claim it cannot be breached, because nobody can say that honestly. What we can commit to is a specific set of controls, tested, plus monitoring that tells you when something is wrong.
What happens when something breaks at two in the morning?: Error monitoring is built in from the first phase, not added after the first incident, so failures are reported with the context needed to diagnose them rather than arriving as a user saying it did not work. Backups run and get restore-tested. The support arrangement after launch — response times, what counts as urgent, what it costs — is agreed in writing before launch rather than improvised during the first outage.
Can our own developers take the code over later?: Yes, and it is built on that assumption. Standard framework, standard database, your repository, documented environment variables, and a deployment another team can take over. If you eventually hire engineers, they should be able to read this and continue rather than announce that it all has to be rewritten.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Custom web app / SaaS dashboard All Web Development & Engineering services