How to brief and budget a website, platform or app project

A useful project brief turns an idea into decisions that a designer and developer can act on. It does not need to contain technical specifications for every component. It does need to describe the audience, the main job, the expected outcome and the boundaries of the first release. Those details make pricing more meaningful and reduce the chance that two people agree to the same project name while imagining very different products.

This guide explains how to prepare a brief for a marketing website, management system, online platform or mobile app. It covers scope, content, integrations, acceptance criteria, ownership and ongoing costs. It also explains how to compare proposals without assuming that the lowest headline figure represents the same deliverable. The aim is a clear working agreement and a product the business can continue developing after launch.

Start with the business problem and audience

Describe what is happening today and why it needs to change. Customers may struggle to understand your offer, staff may lose track of enquiries, or a manual service may need a self-service platform. Use a concrete example from ordinary work. This helps the team distinguish the actual problem from a preferred feature that may or may not solve it.

Name the initial audience and its context. A customer browsing on a phone has different needs from an administrator handling many records on a desktop. A field worker with unreliable connectivity needs different assumptions from someone working in an office. These differences affect layout, performance, account design and testing, so they belong in the brief from the beginning.

State what success would look like in practical terms. A useful enquiry reaches the team with the right context. A staff member can find and update an assigned task. A customer can complete a paid workflow without support. Avoid choosing a target that the build alone cannot guarantee, such as a particular sales total or a top search ranking.

Choose the right project category

A marketing website mainly explains a business and supports contact or another focused action. A management system organises internal work, records and responsibilities. An online platform delivers a recurring service through accounts and workflows. A mobile app provides a phone-focused experience and may use device capabilities or store distribution. Some projects combine these categories, but the distinctions help reveal scope.

Do not describe a product with accounts, payments, private files and automation as a simple landing page merely because it has an attractive homepage. The public page may be small while the underlying service is substantial. List the operational features separately so the estimate reflects what must be built, tested and maintained behind the visual introduction.

TenWeb's published service categories provide a starting point for this conversation. Website pricing and starting prices for custom systems are not substitutes for a defined scope. The final brief should explain which pages, workflows and integrations are included. It should also state which requests are deferred so later additions can be discussed transparently.

Describe workflows rather than a list of screens

A screen list can hide missing behaviour. Login, dashboard and settings do not explain how someone becomes a user, what the dashboard helps them do or how changes are saved. Write short journeys using a person's goal: a new customer registers, uploads a file, receives a result and downloads it. Then identify the screens and data needed to support that journey.

Include errors and interruptions. What happens if an upload fails, a payment is pending or a staff member loses access? These cases affect whether the product is actually usable. A brief does not need to solve every edge case technically, but it should identify important risks so the implementation can make deliberate choices rather than improvising late in delivery.

For each journey, define an observable completion condition. A submitted form produces a record and a confirmation. A changed task is visible to the next authorised colleague. A cancelled subscription shows the correct future access state. These outcomes become useful acceptance checks and provide a shared language for reviewing the finished work.

Prepare content and design references carefully

Collect the assets that already exist: logos, approved photographs, service descriptions, examples and contact details. Identify what must be created and who will approve it. A project can stall even when the software is ready if essential content has no owner. Include realistic review time in the plan rather than assuming every image and paragraph will be approved immediately.

Use design references to explain specific preferences. You may like one site's spacing, another's typography and another's mobile navigation. Say what works and what does not. Asking for a site to look like a reference without explaining the reason can lead to imitation that misses your actual audience or content needs.

Distinguish real evidence from illustrative concepts. Portfolio mockups and generated images can demonstrate a visual direction, but they should not be presented as documented customer results unless they are. Keep important source assets and final export versions organised. Future updates are easier when the team can locate the original image, approved copy and current implementation without searching through old message attachments.

Inventory integrations and external dependencies

List every external service the product needs to communicate with. Include payment providers, email, CRM, calendars, maps, AI services and app stores where relevant. For each one, describe the desired action and the business account that should own the connection. A vague request to integrate everything makes it difficult to estimate effort or identify restrictions.

Confirm whether the required interface exists and whether the current service plan permits access. A provider may offer an API but not the exact operation the workflow needs. Avoid basing a fixed delivery promise on an assumed capability. If a dependency needs investigation, identify that as a discovery task before treating the integration as agreed implementation scope.

Record responsibilities for sensitive setup. The account owner should enter private keys through the relevant secret-management interface, not send them through a public document or chat. The handover can describe where a connection is configured without recording the secret itself. This preserves maintainability while reducing unnecessary exposure of business access.

Separate build costs from operating costs

The initial build pays for creating and delivering the agreed product. Ongoing costs can include hosting, domain renewal, storage, email delivery, AI usage, payment processing and store accounts. The exact list depends on the architecture and current provider terms. Ask for these categories to be identified so the business can budget beyond the launch date.

Usage-based costs deserve particular attention. A platform that processes video or generates images may have a different operating profile from a static business website. Estimate a realistic customer's activity and consider repeated or failed operations where costs still apply. Do not assume that a small first-month bill predicts the cost after a successful promotion or a large customer joins.

Budget for maintenance and change as separate responsibilities. Fixing an agreed workflow that is broken differs from adding a new product capability. Clear acceptance criteria make that distinction easier to discuss. Agree how updates are requested, prioritised and priced, and identify who handles urgent incidents when the original project phase has ended.

Compare proposals on the same scope

When comparing estimates, check what each includes. One proposal may include content preparation, migration, testing and handover while another covers only the visible interface. Ask about the number of workflows, supported roles, integrations and expected deployment environments. A price difference can reflect a genuine scope difference rather than simply a more expensive supplier.

Look for concrete delivery evidence. The proposal should explain how the team will demonstrate working journeys and how you will review progress. A series of attractive screenshots is useful for design approval but does not establish that payments, permissions or data handling work. Ask which parts are prototypes and which are connected to the actual system.

Understand assumptions and dependencies. If delivery depends on your team providing copy, access or approvals, those responsibilities should be visible. If a third-party review can affect the release date, the schedule should acknowledge it. A reliable plan makes uncertainty explicit instead of presenting every external dependency as fully controlled by the developer.

Agree ownership and handover before launch

Clarify who owns the source, assets, domain and service accounts. The business should understand how it can continue development with the same team or another authorised provider. Where a platform imposes restrictions on export or hosting, discuss those before committing. Ownership is easier to organise at the start than during a rushed handover after a disagreement.

Request practical documentation appropriate to the product. A small website may need editing and deployment instructions, while a platform also needs operational procedures, account roles and integration details. Documentation should help someone perform real tasks, not merely list technologies. Keep it current when a major workflow or provider changes.

Preserve a verified launch snapshot and the final acceptance record. This gives future development a stable reference and helps distinguish existing behaviour from a new regression. Keep credentials separate from project documentation. Use authorised account access and secure secret storage so handover does not become a folder of passwords copied between people.

Project brief checklist

• The audience, current problem and desired outcome are concrete.
• The project category reflects the actual workflows behind the homepage.
• First-release journeys include failures and recovery.
• Required content and approval owners are identified.
• Design references explain specific preferences rather than vague imitation.
• Integrations name the action, account and supported capability.
• Build and operating costs are considered separately.
• Acceptance checks demonstrate outcomes, not only completed screens.
• Ownership, handover, maintenance and future changes are agreed.

Frequently asked questions

Do I need technical knowledge to write a good brief?

No. Describe the people, tasks, information and outcomes in ordinary language. The development team can translate those needs into an implementation. Concrete examples and clear priorities are more useful than technical terms used without a shared understanding.

Can the scope change after work begins?

Yes, but changes should be made deliberately. Record what is being added or removed and how it affects delivery, cost and acceptance checks. Avoid silently expanding the first release while continuing to use the original estimate as if nothing changed.

Why do two quotes for the same idea differ so much?

They may include different workflows, testing, content work, integrations or handover. Compare the assumptions and deliverables before comparing only the total. Ask each team to explain what the customer can actually do in the delivered version.

What is the most useful thing to prepare first?

Write one complete customer or staff journey and explain why it matters. Then gather the content and examples that support it. This gives the team a concrete starting point and helps reveal whether the project is a website, an internal system or a broader platform.

How should we plan future development?

Keep a prioritised backlog, preserve source and assets, and document the decisions that affect the architecture. Use real customer feedback and operational evidence to choose improvements. A maintainable first release creates room for future work without trying to build every possible feature immediately.