Custom web app RFP: the pack for a build beyond a marketing website

Scope this as a custom software build with logic, data storage, and often user accounts behind it, distinct from a marketing or brochure website. Examples include an internal booking tool, a client portal, a calculator with saved results, or a workflow app specific to how your business operates. Say explicitly whether this is a brand new build or an extension of something that already exists.

List every feature you consider must have versus nice to have, since a custom build without a clear feature boundary tends to grow in scope quietly, with each small addition seeming reasonable on its own until the total project has drifted far past the original quote.

State whether ongoing maintenance and feature development after launch are part of this RFP or a separate, later engagement; a build contract and a long term support contract are different commitments and should be priced separately even if you expect to hire the same vendor for both.

Create the code repository under your own organization account before work starts and add the vendor as a contributor, rather than letting them build inside their own account and transfer it to you later. This single decision avoids most of the ownership disputes that come up at the end of a custom build.

Provide access to any existing systems the app must connect to: a CRM, a payment processor, an existing database, or an authentication provider. If none of these exist yet, name who is responsible for selecting them, since a vendor defaulting to whatever they are most familiar with may not be the best fit for your actual requirements.

Give the vendor a named point of contact on your side who can make product decisions quickly; a custom build stalls fastest when every small decision needs a round trip through people who were not in the room when the requirement was written.

You should own the full source code, in a repository under your own account, along with documentation of the architecture, the tech stack, and every third party service the app depends on. A build with no documentation is, in practice, only maintainable by the developer who wrote it, which is a serious risk if that developer becomes unavailable.

Confirm you own any custom design assets, icons, or illustrations created specifically for this app, and confirm the terms of any paid third party libraries or services the app relies on, since some licenses are tied to the original purchasing account rather than transferring automatically.

Require a written handoff document at project end: how to run the app locally, how to deploy it, where credentials and API keys are stored, and who currently has access to each one, so a different developer can pick up maintenance without starting from zero.

Break the build into milestones tied to working, testable features rather than percentage complete estimates, which are notoriously unreliable in software work. A reasonable structure: a milestone for core data structure and authentication, a milestone for each major feature group, and a final milestone for launch readiness including the staging to production move.

Each milestone's acceptance test should be a live demonstration in the staging environment, not a status update in an email. If a feature does not work the way the requirement described, that milestone is not complete, regardless of how much underlying code exists behind it.

Require a staging environment that mirrors production closely enough to catch real problems, and require sign off in staging before anything moves to the live environment where real users or real data are involved.

Weight technical clarity over price: 25 percent for a specific, named tech stack with a stated reason it fits your project, 20 percent for a milestone plan broken into testable, demonstrable pieces, 20 percent for a portfolio of comparable custom builds, not just marketing websites, 15 percent for accessibility and security practices named up front, and 20 percent for price and timeline realism.

Be cautious of a bid that describes the whole build as one milestone with one delivery date months away; a custom build with no intermediate checkpoint gives you no way to catch a misunderstanding early, when it is cheap to fix, instead of late, when it is not.

Ask to see a redacted repository or codebase from a past comparable project, since a portfolio of finished screenshots tells you far less about a vendor's work than seeing how they actually structure and document their code.

Ask every bidder to answer these in writing before you score their proposal: What exact tech stack will you use, and why does it fit this project specifically? Will the code live in a repository we own from day one? What accessibility standard do you build to, and how do you test for it? How do you handle a staging environment before anything reaches production? What happens to API keys, credentials, and third party accounts if we end the engagement or move to a different developer?

Also ask how they document third party integrations as they build them, since a custom app with an undocumented payment integration or an undocumented API connection is a maintenance risk that only becomes visible the first time something breaks and nobody can explain why.