How Fast Can a Custom Web App Actually Ship?

Weeks, not months. That's the honest answer to how fast a custom web app can ship, and it has almost nothing to do with how fast anybody types. A quick turnaround on custom software comes from inventory. Either you have already built the boring 80 percent, or you are building it again on the client's clock.

We keep a library of 19 production modules. 383 files, 53 database tables, 61 API routes, all pulled out of a running Next.js and SQLite platform rather than written as examples. Database and auth and the UI kit sit in one group. Marketing site, CMS, blog engine, SEO toolkit and attribution in another. Then leads and CRM and forms. Then scheduling, automations, notifications. Then ledger, banking, invoicing. Then the AI group, which is where the MCP connector lives.

None of that is impressive on its own. Every agency claims a starter kit. The difference is whether the thing came out of production or out of a tutorial, because only one of those has already met a real user.

Speed is inventory, not heroics

The fastest way to blow a timeline is to build authentication again.

Not because auth is hard in some abstract sense. Because auth is a swamp of decisions that all look small: session length, refresh behaviour, what happens on a revoked Google account, whether the admin flag lives in the token or gets looked up per request, what a logged out user sees on a page they bookmarked while logged in. Every one of those is a twenty minute conversation and a two hour implementation, and there are thirty of them.

You answer those once, ship it, watch it survive contact with actual humans, and then you stop answering them. That is the whole trick. There is no clever part.

Which is also why a small senior bench beats a big org chart on turnaround. Junior handoffs and an account manager relaying messages is where schedules go to die, and it is not because juniors are slow. It is because every handoff reopens decisions that were already closed. Our average engineer tenure is 11 years. That is not a brag about seniority, it is a statement about how many of these decisions are already made before the kickoff call.

What that looked like on a real build

The most recent one is the Laramie Pickleball Association. Small club, volunteer board, and a membership spreadsheet doing four jobs at once.

What they needed was not exotic. A public site, a member dashboard, a board only admin area, dues collected online, and a login that did not require volunteers to run a password reset desk. Written out like that it sounds like a weekend. It is not, and anyone who tells you it is has never taken money from a stranger over the internet.

But almost none of it was new work. Sessions came from the core auth pattern. The database bootstrap, the migration runner, the settings store, all lifted. The admin shell, the tables, the form components, lifted. PayPal was the genuinely bespoke piece, because dues have a season attached and a payment that does not update a member record is worse than no payment system at all.

The part that would have eaten a month on a from scratch build, the part nobody demos because it is invisible, was already sitting in a folder with a README and an idempotent schema file.

Where the shortcut still cost us

This is the part most agencies leave out of the case study, so here it is.

The module library assumes a specific auth stack, NextAuth, and a specific database accessor. The pickleball app has neither. It runs jose JWT sessions and its own better-sqlite3 handle. So every module we pulled in needed its auth() calls swapped for the app's own session lookup and its db() calls pointed at the app's connection. Mechanical work, but not zero work, and you find every instance by breaking the build repeatedly rather than by reading.

Second, the MCP connector module shipped with a schema file that was missing a table its own code queried. The oauth_tokens table simply was not there. Our module, our bug, discovered the way these things are always discovered, which is at runtime with a stack trace.

Third, the upstream library moved underneath us. mcp-handler went to 2.x and changed its registration API, and the request context moved. Nothing dramatic, just the tax you pay for depending on something that is still evolving.

Three real seams, all found on this build, all now written down so the next port does not rediscover them. That is what a library actually is. Not a folder of code. A folder of code plus the list of ways it has already gone wrong.

We did the same exercise on ourselves when we built our own back office, and the pattern held: the second time you build something, you are not writing it, you are remembering it.

When fast is the wrong goal

Quick turnaround is a feature right up until it becomes the requirement.

A full custom build in our world runs 6 to 12 weeks. Martech wiring runs 4 to 8. A single design surface runs 2 to 4. Those ranges exist because some things genuinely take that long, and compressing them does not make the work smaller, it just moves the cost somewhere you cannot see it yet. Usually into whoever maintains the thing in month nine.

The projects that go quickly share a shape. The scope is understood before anyone opens an editor. The client can answer questions in hours rather than at the next board meeting. And the majority of what is being asked for has been built before by the people building it now.

When a project does not have that shape, saying yes to a fast timeline is just choosing which corner gets cut. We would rather tell you which weeks are real. Most of the time, the honest number is still faster than what you were quoted somewhere else, because that quote included rebuilding the login screen.

Frequently asked questions

How long does it take to build a custom web app? For a scoped app with authentication, payments and an admin area, plan in weeks rather than months if the team has shipped that shape before. Our published ranges are 6 to 12 weeks for a full custom build and 2 to 4 weeks per design surface. A team starting from an empty folder should be quoting you longer, and if they are not, ask what they are reusing.

Does using prebuilt modules mean I get a template site? No. The reused parts are the invisible ones: database migrations, session handling, admin tables, form plumbing. What your users actually see gets designed and built for you. Nobody has ever been impressed by a bespoke migration runner.

What makes a project take longer than expected? Undecided scope and slow answers, in that order. Almost never the code. A question that waits two weeks for a committee costs more calendar time than the feature it was about.

Can you speed up a project that has already started badly? Sometimes. It depends whether the foundation is sound or whether the fast option is to stop and redo the base. We will tell you which one it is before you spend more money, even when the answer is annoying.

Is a faster build a less reliable build? Only if the speed came from skipping things. Speed that comes from reuse usually goes the other way, because the reused parts have already been running in production and have already had their bugs found by somebody else's users.

Who owns the code at the end? You do. That matters more than turnaround, honestly. A quick build you cannot take with you is a rental with extra steps.

If you have a date you need to hit

Tell us the date first, before the feature list. It changes the conversation completely, and it is the fastest way to find out whether the thing you want is a 3 week project or a 3 month one.

We build custom web applications for businesses that have outgrown a spreadsheet or a SaaS subscription, and we are straight about which weeks are real. If you are still deciding whether to build at all, the build versus buy maths is here, and it is worth reading before you commit to either.

Or just send us the deadline and we will tell you if it is achievable.