Before You Hire a Web App Development Company, Answer This One Question

Ask the vendor which one they think you're buying before you sign anything. If they don't ask you back, that's information too.

A website and a web app are not the same purchase

A marketing website is built for content and conversion. Someone lands on it, reads something, maybe fills out a form, and leaves. A web application is different. Dashboards, portals, workflow tools, logins, roles, approvals, data that has to be right and visible to the right people and invisible to everyone else.

Most businesses we talk to already have a web app. They just built it in a spreadsheet. It lives on someone's laptop with a version history that's really a folder full of files named "final_v3_ACTUAL," and half the company has learned to work around it instead of asking anyone to fix it. That spreadsheet everyone secretly runs the business on is a web app in disguise. It just doesn't have logins, doesn't track who changed what, and breaks the moment two people touch it at once.

Knowing which one you're buying changes who you should hire, what a fair price looks like, and what "done" even means.

Why hiring the wrong agency burns the budget

A website agency builds for content and conversion. That's the discipline they've hired for, priced for, and staffed for. Ask them to bolt on a customer portal with logins and permissions and you'll get exactly that: bolted on.

Role-based access, audit trails, and reporting a finance team can trust are a different discipline entirely. These aren't a plugin you add at the end. They're decisions about who can approve a discount, who can see a margin, who gets notified when a record changes, and what happens when two people edit the same job at once. Get this wrong and you don't get a failed project. You get a pretty front end sitting on top of the same broken process, with a bigger invoice attached.

The signs you actually need a web app

The spreadsheet everyone secretly runs the business on has outgrown what a spreadsheet can safely do: formulas nobody wants to touch, a "master" version, someone who reconciles it by hand every Friday. Approvals happen over email, which means an approval is really just a sentence in someone's inbox that nobody can search six months later. And different people need different levels of access to the same data — your dispatcher shouldn't see payroll, your finance lead shouldn't have to ask a favor to see a job's real margin, but right now everyone's looking at the same file because nobody's built the version that doesn't require that.

If two of those are true, you're not shopping for a nicer website. You're shopping for a web app.

What this actually looks like when we build it

Compare this to whatever a vendor is pitching you. A custom web application from us means role-based access, audit trails and approvals built in from the start, not added later. It means reporting built for finance, numbers they can trust without a side conversation to confirm them. It means migrating your existing data instead of asking your team to re-enter three years of history by hand. And it means training and documentation at the end, so the system doesn't live only in the heads of the people who built it.

We build it on React, Node and Postgres. Boring technology, on purpose. Novelty is a cost paid every year after launch, and your team is the one who pays it.

A typical build runs 10 to 20 weeks and starts from $45k. That's a range, not a promise, because your version of "approvals" might be one button or a four-stage sign-off with escalation rules. That difference is exactly what discovery is for.

Sometimes the honest answer is: don't hire us

We turn down projects. Sometimes a specialist would do the job better than we would — a niche compliance tool, a vertical product where someone else has spent years solving exactly your problem. Sometimes an off-the-shelf product already solves it for a tenth of the price, and building custom would just be an expensive way to reinvent something you could buy this afternoon.

You'll hear that in the first call, not the third. A project we shouldn't have taken costs both of us more than it's worth.

How the number gets fixed: discovery week

Every published price on our site starts with the word "from," because nobody can price a system they haven't scoped.

A discovery week is a flat $4,800, credited back in full if you continue into a build. Over that week we get into the actual mess: your current process, your data, the approvals that live in someone's email, the report finance doesn't trust. It ends in a written scope, an architecture sketch, and a fixed estimate. Not a range. A number.

Do the scoping before you quote, not after. That's the whole trick to an estimate that holds.

Who owns the code — the actual answer

You own the code outright from day one. The repos live in your own organization's account. The infrastructure runs in your own cloud account. If you want to walk into your own AWS console and see exactly what's running and what it costs, you can, from the start.

If it ends, here's what you're left holding

If the relationship ends, you're not left holding a system nobody understands. We do a full handover: an architecture walkthrough with whoever inherits the system, runbooks that explain how it actually operates day to day, and two weeks of support after the handover to catch what the walkthrough missed.

Ask any vendor you're considering to describe theirs in the same amount of detail.

A short checklist for vetting any web app company

Use this whether you call us or not.

Ask who owns the code, the actual repo, not a vague "you'll have access." Ask how the estimate was built, and specifically whether it came before or after anyone looked at your actual process. Ask whether roles and audit trails are covered as a first-class part of the build, not quoted separately later. Ask what handover looks like if things end: what documents, what walkthrough, and for how long.

If a vendor gives you a firm number over email before asking a single question about your data or your process, that number isn't real yet. The custom web application you actually need — and the ongoing cloud and care it takes to keep it running once it's live — deserves better than a guess.