Custom web applications

The short version

A custom web application is software shaped around one business's process instead of the average of a thousand businesses' processes. The trigger is nearly always the same: customers call or email to do things — book a slot, reorder, check where their job is, send a document — that they would happily do themselves at nine at night if there were a screen for it. Every one of those interruptions is paid for out of somebody's working day.

• The real cost of "we handle that manually" is a payroll line, not a software line. Count it before you compare quotes.

• Off-the-shelf products usually fit the middle of your process and fail at the edges — your pricing rules, your approvals, your exceptions.

• A full custom web application typically runs $15,000 to $40,000, and six to twelve weeks from kickoff to launch.

• You own the code, the repository, the database and the hosting accounts. There is no platform to stay licensed to.

• If a $50-a-month product genuinely solves your problem, we will tell you. That is a cheaper answer than we are.

The test is hours a week, not complexity

The useful question is not whether your process is complicated. It is how many hours a week a person spends being the software — copying between systems, answering questions the customer could have looked up, and remembering rules nobody wrote down.

Put a number on that. Two people at fifteen hours a week is most of a full-time salary spent on work no customer is paying for. Against that figure, a one-off build stops looking like an expense and starts looking like a hire you do not have to make again next year.

The signals that usually mean it is time:

• Customers cannot see the status of their own order, booking or job without asking a human.

• Two or three systems hold overlapping copies of the same customer, and the copies disagree.

• A new hire needs two weeks of shadowing before they can quote a job correctly, because the rules live in one person's head.

• You bought a SaaS product and then built a spreadsheet next to it to hold the parts it could not do.

• Growth is capped by admin capacity, not by demand.

The last one is the expensive one. A business that cannot take on more work without taking on more admin has a ceiling, and it is usually lower than the owner thinks.

What these actually look like

In practice it is a website your customers or staff log into, that knows your rules and holds your data. The shape it takes depends on which part of your business is jammed. The common ones for small and medium businesses:

• Customer portals — login, order and job history, documents, invoices, live status, and self-serve changes that would otherwise be a phone call.

• Booking and scheduling systems — real capacity, service windows, travel buffers, deposits, cancellation rules and automatic reminders. There is more on those in e-commerce and booking platforms.

• Quoting and estimating tools — your pricing logic encoded once, so every member of staff quotes the way your best estimator does.

• Member and client areas — gated content, renewals, seat management, and the billing that goes with them.

• Field and workshop apps — job sheets, photos, signatures and sign-off, working on a phone in a basement with one bar of signal.

Underneath, all of it is ordinary technology: Laravel and PHP on the server, MySQL or PostgreSQL for the data, and a normal browser at the front. That is deliberate. The exotic choice is the one that strands you in three years when nobody wants to work on it.

What a custom web application costs

Every project is quoted individually, but the ranges are not a secret, and you should know them before the call, not after it.

The first call is free. Discovery and design are then billed as one piece of work — $1,500 to $3,000 depending on size — and credited in full against the build if you go ahead. What comes out of it is a written scope and a fixed quote, and that quote is the number you pay unless you ask us to add something. The screens and the scope are yours either way, even if you take them to somebody else.

If the scope changes mid-project — and it usually does a little — we price the change in writing before building it, so nothing appears on an invoice you did not agree to.

What moves the number most is not screen count. It is the number of genuinely different rules the system has to honor: pricing tiers, approval chains, tax and shipping edge cases, and the exceptions that start with "except when".

When custom is the wrong answer

Often enough that we say so at the scoping call, not after the invoice. Custom software is worth building when your process is genuinely yours and genuinely valuable. When it is neither, you are paying to rebuild something you could have rented.

We will point you elsewhere when:

• The process is standard. Accounting, payroll, email and general bookkeeping are solved problems, and the solutions are cheap.

• The process is still changing every week. Custom software makes decisions permanent; make the decisions first.

• The pain is really one report. Sometimes the fix is a better query against the data you already have, not an application around it.

• Nobody inside the business will own it. Software with no internal champion goes unused, however good it is.

There is a middle path worth more attention than it gets: keep the off-the-shelf product you already pay for, build the one custom piece it cannot do, and wire the two together. That is frequently a $5,000 answer to what looked like a $40,000 problem.

How the build runs

You see working software early and often, and you are never more than a week from the last time you looked at it. The pattern is the same on every project:

• Discover, about a week — a call, then a look at how work really moves through your business today, including the spreadsheets and the sticky notes.

• Design and scope, one to two weeks — screens, a written scope and a fixed quote. You approve the number and the list before we write a line of production code.

• Build, three to ten weeks — a staging URL you can use from early on, and a demo every week. No six-week silence ending in a surprise.

• Launch, about a week — we migrate your data, train your team on the real system, and stay on call through the first week of live use.

• Support, ongoing and optional — move onto the Anvil Care Plan, or take the keys and run it yourself.

The person who scopes your project is the person who writes it. There is no handoff to a team you have never met after you sign, which is the single biggest reason agency projects drift away from what was agreed.

What you own at the end

All of it. The code lives in a repository you own, on hosting accounts in your name, built with standard open-source tools. There is no proprietary platform to stay licensed to and no lock-in clause waiting for you at renewal.

That has a practical consequence worth stating plainly: if this studio vanished tomorrow, nothing of yours would be stranded. You would hand the repository and the documentation to another competent developer, and they could get to work — because we deliberately build on technology thousands of developers already know.

If you can name the request your team answers most often by hand, you already have the start of a scope: what it is, roughly how many times a week it happens, and what has to be true for the answer to be right.