A web development company is selling you three things you cannot get from a template: a site built around your process, a codebase and a domain you own outright, and a named party who is accountable when something breaks after launch. Everything else in a proposal — the framework list, the design system, the weekly demo — is a means to those three ends.
That is the way to read a proposal: not "which company looks most impressive", but "which shape of engagement am I buying, what does each phase hand me, and what do I own on the day the site goes live". This is what each of those answers looks like in practice.
What a web development company actually sells you
Almost every engagement takes one of three shapes, and they differ in the single thing that decides how the project feels from the inside: who carries the risk that the estimate is wrong. A fixed-scope project puts that risk on the company; a retainer puts it on you; a developer placed in your team puts it on whoever manages that developer.
- A fixed-scope project. You buy a defined outcome — a specific list of pages, flows and integrations — for a fixed price. The company carries the risk of its own estimate, which is why a serious one spends real time on discovery and why a vague brief produces either a padded price or a change-order argument in month two.
- A product retainer. You buy a standing team for a monthly fee and direct what they build. Work keeps moving, priorities can change every month, and the estimate risk sits with you. It only works when someone on your side can decide what is worth building next.
- A developer placed in your team. You buy capacity. The company supplies the person, you supply the direction, the prioritisation and the technical management. It is the cheapest per hour and the most exposed arrangement if nobody on your side is available to make technical calls.
None of the three is better in the abstract. A site with a fixed launch date is a good fixed-scope project; a product that will change every month is a retainer that somebody keeps re-scoping into fixed quotes.
The five phases of a build, and what each one should produce
Web projects run through the same five phases whether the company is one person or forty. The difference between a competent web development company and a cheap one is whether each phase hands you something you can read and object to before the next phase starts spending money.
- Discovery. You should receive a list of pages or routes, the integrations the site depends on (payment, CRM, email, inventory, whatever it has to talk to), the data the site stores, who owns each piece of content, and the assumptions the estimate rests on. If discovery produces a slide deck and no list, the estimate is a guess with a design.
- Architecture and design. You should receive the site structure, wireframes for each page template rather than every page, and a design system — type, spacing, colour, components — rather than a set of one-off screens. A page-by-page design of a 60-page site is mostly a way to bill for repetition.
- Build. You should see work land in a shared repository and on a staging URL that updates as it is finished, not a fortnightly status report. Weekly demos and a visible task board are the minimum; neither is a substitute for a URL you can open.
- Quality assurance and release. You should receive a launch checklist: a device and browser pass, end-to-end tests of every form and payment path, a redirect map from the old site's URLs, a sitemap and robots file, and a written rollback plan for the first week.
- Post-launch. You should receive monitoring — error tracking and uptime checks — a performance baseline to measure future changes against, and a support arrangement with stated response times rather than "email us and we will look".
What belongs in the handover before launch
Handover is not a zip file sent at the end of a project. It is the list of accounts and artefacts that decide whether you can change your own site next year without paying someone to unlock your own property. Ask for it at the start and the answer tells you most of what you need to know about the company; a supplier that resists it is telling you the lock-in is the business model.
- Domain registration and DNS inside an account you control, with the company as a delegated user rather than the owner.
- The source repository, owned by your account or organisation, with the company as a contributor.
- Hosting, database and storage accounts on your billing, even when the company created them.
- An admin account in the content management system tied to your own address, with a second admin you can use if the first is lost.
- Analytics and search console properties verified in your name, with the sitemap submitted.
- Third-party API keys, transactional email credentials and payment account access, documented in one place.
- The redirect map for every old URL, and a note of what was deliberately allowed to 404.
- A short runbook: how to deploy, how to roll back, who to call and what it costs out of hours.
Five things that should be true on launch day
None of these need a bigger budget; they need somebody to check them, and they are the ones most often missed because the launch date arrives first.
- One canonical host. If both the www and the bare domain serve the same page, search engines have to choose between two copies of it. Pick one and redirect the other at the server.
- Server-side redirects. A page that only redirects after JavaScript loads reads as an empty page to a crawler — the old URL keeps its history and the new one gets nothing.
- Per-page titles and descriptions, one h1 per page. Titles inherited from a shared layout template are the most common duplicate on a new site, because every page ends up claiming to be the homepage.
- Content in the served HTML. Copy fetched by JavaScript after the page loads is invisible to many crawlers and to the answer engines that increasingly quote sites. A page you can read with JavaScript disabled is a page that can be indexed.
- A conversion goal tested once. An analytics property that records a form submission or a checkout on day one is worth more than a dashboard installed after the first campaign.
How estimates move, and how to keep them honest
Estimates move for four predictable reasons, and all four are visible in advance: scope discovered after the estimate was written, an integration nobody priced, content that arrives after the slot it was needed for, and decisions that stall while the team waits. You will not eliminate them, but you can price them.
Ask for the assumptions list, ask what happens to the schedule when content is three weeks late, and ask how the company handles the first request that is genuinely new work. A fixed price is a bet on the clarity of your brief. If you want certainty, buy it with a better brief: written scope, named content owners, one decision-maker, and a discovery phase that ends in a document you have actually read and signed.
Where 723 Studios fits
723 Studios builds web platforms and custom applications for businesses whose workflow is not a template — custom app development for internal tools, portals and system integrations, alongside marketing sites that are handed over clean. If you are weighing a rebuild against a redesign, the honest starting point is the breakdown in how app projects are actually priced, and the evaluation questions in how to choose a software development agency apply to a web build unchanged.
Frequently asked questions
How much does a web development company charge?
Pricing follows the three engagement shapes rather than a rate card: a fixed price for a defined scope, a monthly retainer for a standing team, or an hourly rate for a developer placed in your team. The number that matters is the three-year total, not the day rate, because maintenance, hosting and the next set of changes usually outlast the build by a wide margin.
What is the difference between a web development company and a web design agency?
A design agency owns the visual and brand layer; a web development company owns the code, the integrations and the deployment. Many companies do both, and the useful question is not which label they use but whether the same team is accountable for the design as built, including performance, mobile behaviour and the forms that collect money.
How long does a typical website build take?
For most business sites the schedule is set less by coding than by discovery and content. The build itself is usually the shorter half. If your copy, images and product data are ready before the build starts, the calendar is short; if they arrive late, no amount of engineering effort recovers the launch date.
Do I own the website and the code when the project ends?
You own it if the contract says so and the accounts are in your name. Ownership in a contract means nothing if the domain, hosting and repository belong to the supplier. Put the account list in the agreement, and check that each account has your organisation as owner before the final invoice.
How do I compare two quotes for the same project?
Compare the assumptions, not the totals. Take both proposals, line up what each one says is included, what it says is excluded, and what it assumes you will supply. The cheaper quote is often the one that quietly excluded the integration, the content migration or the redirect map.