Custom Web App Development: The Real Numbers, and When to Skip It

Most "custom software" quotes are template configuration with a different logo. You can tell within the first call — if someone can give you a number before asking what your approval process looks like, they're not scoping your business. They're scoping a category.

What we actually mean by "custom"

A custom web app is a portal, dashboard, or workflow tool built around how your business actually runs — not a template with your logo dropped on it. The features that make it custom aren't the color scheme. They're role-based access so a dispatcher sees something different than a controller. Audit trails so you can answer "who approved this" six months later without guessing. Approval chains that match how your team actually signs off on things, not a generic workflow someone else designed for a different industry. It also includes moving your existing data in and training your team to use it, because a system nobody can operate is just a more expensive spreadsheet.

The real signal that you need one

Every business we talk to has a version of the spreadsheet everyone secretly runs the business on. It started as one tab. Now it's forty, three people maintain it by hand, and someone emails a copy around every Friday because the "real" system doesn't do what the business actually needs.

The signal isn't "we've outgrown spreadsheets" — that's true of almost every company we talk to and it's too vague to act on. The real signal is narrower: when the workarounds cost more than the build would. That's the double data entry between two systems that don't talk to each other. It's the person who spends six hours a week reconciling a spreadsheet against an invoicing tool. It's the dispatcher who calls three people to find out if a job is done because nothing tracks it in real time.

We see this most in logistics and freight, healthcare, field services, manufacturing, professional services, retail, fintech and insurance, and construction — industries where the core business runs on operations, not software, and the software was always an afterthought bolted on later. If you can put a dollar figure on the hour your team keeps losing, you're probably past the point where a better spreadsheet fixes it.

When we'll talk you out of it

Here's the part most vendors won't say: we turn down projects a specialist would do better. If you need a piece of e-commerce infrastructure that a mature platform already does well, we're not going to build you a worse version of it from scratch to bill more hours. We also turn down projects an existing off-the-shelf product already solves for a tenth of the price — plenty of good software already exists, and building a custom version of something that isn't actually specific to you is just an expensive way to reinvent a wheel.

You'll hear that in the first call, not the third, after we've already sent a proposal. If your problem is genuinely off-the-shelf, we'd rather tell you now than string out a discovery week to get to the same answer.

What actually drives the cost and the timeline

Our custom web applications start at $45k and typically run 10 to 20 weeks. That's the real number, not a teaser — it's what it costs to build a portal or dashboard with role-based access, audit trails and approvals, reporting built for a finance team rather than a generic export button, migration of your existing data, and training and documentation so the system survives staff turnover.

What moves you up from that floor is usually one of three things. First, the number of distinct roles and approval paths — a system with two user types and one approval chain is a different build than one with five roles and conditional routing. Second, reporting complexity — a finance team that needs reconciled, auditable numbers takes more work than a dashboard that just needs to look right. Third, how messy the data migration is. Moving clean records from one modern system to another is straightforward. Moving fifteen years of inconsistent spreadsheets, each with its own quirks and exceptions someone remembers but nobody documented, is the part that actually eats weeks.

What moves you down: fewer roles, simpler reporting, and data that's already reasonably clean. None of this is exotic. It's the same three variables on every project, in different proportions.

Why the estimate comes after a discovery week, not before

We don't quote cold. Every fixed-scope project starts with a discovery week — flat $4,800, credited back in full if you continue. It ends in a written scope, an architecture sketch, and a fixed estimate. Not a range. A number.

The opinion behind this, and we'll say it plainly: estimates should come after discovery, not before, which is why the number holds. A quote given before anyone has looked at your data, your approval chains, or the mess behind your current spreadsheet isn't an estimate. It's a guess with a dollar sign in front of it. Once scope is written down and both sides have signed off on it, scope and the fixed estimate are locked. If something changes after that — and things do change — it gets priced before the work starts, not billed after the fact as a surprise on an invoice.

Boring technology, on purpose

We build on React, Node, and Postgres. Not because it's exciting — it isn't — but because it's boring on purpose. Novelty is a cost paid every year after launch, and it's the client who pays it, not us. A newer framework might save a few weeks on the build. It also means fewer developers who can maintain it in three years, fewer answers when something breaks at 2 a.m., and a slower hiring pool if you ever want to bring the work in-house. We'd rather hand you something a competent engineer can pick up cold five years from now than something clever that only we understand.

Who owns what, in practice

You own the code outright from day one. Not a license to use it, not a dependency on us to keep running it — ownership. The repos live in your organisation's accounts, not ours. The infrastructure runs in your own cloud account, not a shared environment we control and could, in theory, hold hostage.

This is the direct answer to the lock-in worry, and it's worth being blunt about: plenty of vendors keep the keys as informal leverage to keep you paying. We don't, because a client who feels trapped isn't a client who stays for the right reasons. If you want to walk away, walk away. The code is already yours.

How this actually gets billed

Fixed-scope projects bill on milestones — typically 30% at kickoff, then the rest on phase acceptance as work is delivered and signed off, not on a calendar. Every fixed-scope project includes 30 days of post-launch fixes, because software that's just shipped always surfaces a few things nobody caught in testing. Billing terms are Net 14.

One thing we don't do: equity or deferred payment. It muddies the relationship, and it has never once made the software better. We'd rather be paid in cash on clear milestones than have a stake in your company clouding whether we're building what you need or what protects our upside. Straightforward billing keeps the incentives straight too.

What the first conversation actually covers

The first call is about your spreadsheet, your workarounds, and whether this is actually a custom-software problem or something a specialist or an existing product already solves better. No pitch deck, no pressure to sign anything on the spot.

If it makes sense to move forward, we work under NDA by default — your data doesn't need to wait for you to ask. If you're in healthcare, fintech, insurance, or anywhere else with a vendor security review, we complete that as part of onboarding, not as an afterthought once we're already three weeks into the build.

From there it's the discovery week, ending in a written scope, an architecture sketch, and a fixed estimate. The same named lead who takes that first call stays with the project through scoping, build, and launch — no handoff to a junior team once the contract's signed. If you've been burned by that before, it's usually the first thing worth asking any vendor about, including us.