Before requesting a website, app, or business system proposal, prepare your goals, users, priority functions, current setup, and an outline of your timeline and budget. You do not need a complete technical document. A short account of the work you want to simplify can start the discussion.
Cost is often the first question. That is reasonable, but a useful answer needs a picture of the work involved. A website introducing a service differs from an application that records transactions, even if both look simple on screen.
I help discuss those needs before putting together a proposal. Clearer information helps you see what will be done, what is outside the scope, and which choices still need to be made. This guide helps you prepare without becoming a technical specialist.
Start with six essential details
For the first enquiry, share what you already know:
- Your type of business and the main problem you want to solve.
- The people who will use the website or application.
- The functions needed to meet the primary goal.
- Any existing website, system, materials, or records.
- Your target date for using the result and the reason behind it.
- Your budget range, if you have one.
If you do not yet know an answer, explain what remains unclear. You might know that handling bookings involves too many separate conversations without knowing whether you need a form, a customer app, or an internal system.
There is no need to wait until you have a polished presentation. A summary sent through the official contact channel can begin the conversation. The following details help as the discussion develops.
Explain the purpose before choosing the product label
Websites, apps, and business systems overlap. An app can run in a browser, while a public website can connect to an internal system. Describe the job before deciding on the form of the solution.
| Initial need | Example purpose | Details to clarify |
|---|---|---|
| Business website | Explain services and receive enquiries | Content, languages, contact routes, and what needs to be editable |
| User application | Book a service or track a request | Devices, accounts, user journeys, notifications, and connectivity needs |
| Internal system | Record work and manage approvals | Staff roles, data, process stages, reports, and connections to other systems |
This table starts the discussion rather than setting rigid categories. A catalogue with a contact button differs from one with payments and stock updates. If your main need is a public website, the guide to landing pages, business websites, and online stores can help narrow the choice.
For an app, say whether people will use a browser or a mobile application. Offline use, camera access, or particular devices also need discussion. Do not assume every access method is included just because a proposal mentions an app.
Describe one process from beginning to end
A feature list becomes easier to understand alongside a workflow. Explain who starts the process, what information comes in, who acts on it, and what result is needed.
GOV.UK describes user needs through the person, task, and purpose. For a project discussion, this approach helps turn a feature name into work that can be explained.
As an illustration, I want a booking app leaves many possibilities open. A more useful description is that a customer submits a preferred appointment, an administrator checks technician availability, and the customer receives confirmation. The appointment is not final until the administrator approves it.
That final detail affects the design. Manual confirmation differs from an automatic booking that immediately reserves a slot. Either may be appropriate, depending on how your business operates.
Include common exceptions, such as a customer changing the appointment or a technician becoming unavailable. You do not need to document every possibility on the first day. Start with the situations that most often get in the way.
Identify users, permissions, and working conditions
The people using a system affect its functionality and the checks it needs. Business owners, administrators, field staff, and customers may have different permissions to see or change information.
OWASP's authorization guidance recommends identifying users, resources, and permitted actions during design. Access should match the tasks required. In your brief, explain, for example, that a technician should only see jobs assigned to them.
Share estimated user numbers, transactions, and data volumes where available. Distinguish registered users from people active at the same time. If a figure has not been measured, identify it as an estimate rather than a verified capacity requirement.
Working conditions matter too. Someone using a phone with an unreliable connection has different needs from an office administrator at a computer. Include known language, device, and accessibility requirements.
W3C includes goals, scope, responsibilities, and resources in accessibility planning. If a particular standard or assessment is required, discuss it early so the work can be accounted for. A responsive layout alone does not describe all those needs.
Separate initial requirements from later development
A proposal is easier to assess when features are grouped by importance. Decide what must be available at first use, what would be useful but can follow later, and what still needs investigation.
In the booking example, recording requests and allowing administrator confirmation might cover the initial needs. Automated payments or scheduled reminders could follow if needed. This does not mean later features will necessarily be easy to add; their effect on the design still needs assessment.
Mention growth plans you already know about, such as new branches, additional languages, or upcoming services. That information helps account for changes without putting every idea into the first phase.
I can help discuss those priorities so the proposal addresses the needs you face now. You can compare options against clearly described work, including the consequences of postponing a function.
Prepare relevant materials and references
For a business website, an initial inventory might include your services, business profile, logo, photos, contact details, and required languages. Identify which materials are ready, need revision, or are not yet available.
Distinguish building the interface from writing, translation, photography, or entering a large product catalogue. Do not assume all content work is included in the development fee. Final materials and their usage rights need to be clear before publication.
Content I supply for a project is temporary preview material. You must replace it before public or commercial use, unless the written scope expressly includes final content for that intended use. Applicable usage rights and licence conditions still apply.
Design references are more useful when you explain your reasons. You might like how services are organised, how products are selected, or how easy a page is to read on a phone. A reference link helps discuss direction; it does not grant permission to copy another party's materials, code, or identity.
For an internal system, a blank form or a report with fictional data can help explain the information needed. Do not include passwords, API keys, or actual customer records in the initial enquiry.
List existing systems, integrations, and data to migrate
If the project builds on an existing system, identify the website address, services in use, available access, and the main obstacle. Also explain whether people must keep working in the old system during the transition.
An integration needs to be explained as a flow of information. What data is sent, where does it come from, where does it go, and when must it update? Sending a request to one service differs from synchronising changes between two systems.
Identify any official documentation or integration facilities you know about. Access availability, usage limits, service costs, and provider permissions need checking before feasibility can be promised. Do not send credentials just to demonstrate that you have an account.
For migration, describe the data types, approximate volume, available formats, and what must remain usable. Moving a product list is not necessarily equivalent to moving transaction histories and their attachments.
GOV.UK's cloud guidance recommends planning for the time and cost of changing providers. If a project depends on a particular platform, cost and continuity planning should account for its limits. Custom websites can also depend on other services.
Source code is not automatically included in my services and may not be available. Panel access, domains, data, licences, and code are separate matters. Raise any particular handover or migration requirements before accepting a proposal. The guide to website access and provider dependency covers this in more detail.
Share your budget and the reason behind your deadline
A budget range helps identify workable options. It is not an obligation to spend the entire amount. If you have not set a budget, explain the priorities and constraints you already know so the possible work can be discussed first.
Separate development costs from recurring expenses. Domains, hosting, subscriptions, licences, API usage, and management may each have charges depending on the design. Using AI during development does not automatically mean the finished website needs a paid AI API to run.
For timing, explain the reason: opening a branch, changing a business process, or replacing an old system. Distinguish a preferred date from a deadline that cannot move.
The schedule also depends on materials, access, decisions, testing, and any third-party services needed. A client's target date is not a delivery commitment before feasibility and scope are discussed. Sharing the deadline early helps assess whether the work should be split into phases.
Describe the result you will check
Requests such as easy to use or fully featured need further explanation. Identify the tasks people must be able to complete and the conditions that make each task successful.
GOV.UK uses acceptance criteria to check whether user needs have been met. In the booking example, checks could cover a recorded request, a status change made by an authorised administrator, and confirmation that matches the administrator's decision.
You do not have to write technical test scenarios yourself. Explain the result you expect and the mistakes that would be most disruptive. The necessary checks can then be discussed within the project scope.
If calculations are involved, provide sample inputs and expected results using fictional data. For a report, show the information needed to make a decision. This explains more than a feature name such as a dashboard or a report.
Where do custom development and an engineer add value?
A clear brief helps establish whether an existing tool is sufficient or adaptation is needed. Custom website development becomes useful when information and functionality need to follow a more specific business process.
For a service business, a customer request might need to reach the correct branch before an administrator assigns a technician. I help discuss that workflow, define the work, and assess what needs adapting. If your existing tools are sufficient, a new build does not have to be the first choice.
AI can help organise ideas or produce a prototype. But a prototype form does not settle who may see requests, how status changes are handled, or whether the process fits staff tasks. As a web engineer and technical lead, I help turn those needs into decisions and checks within the project scope.
You can discuss them directly with me without choosing the technology first. For public websites, SEO, performance, and security foundations can be coordinated with design as specified in the proposal; that work does not guarantee rankings, sales, or uninterrupted operation. See the comparison of custom websites and AI website builders for more on the approaches.
Use these ten questions as a simple project brief
Copy the questions into your notes and answer what you already know. Everyday language is enough; unclear points can become part of the discussion.
- What business or organisation will use the result of this project?
- What problem do you want to solve, and how is the work done now?
- Who are the users, and what should each be allowed to do?
- Which workflows or functions must be available in the first phase?
- What results will you check to confirm that those functions meet your needs?
- What materials, sample data, and existing systems are available?
- Are there integrations, migration needs, or particular working conditions?
- Which references do you like, and what makes them relevant?
- When is the result needed, why, and what budget range have you set, if any?
- Who will coordinate project decisions and manage the result once it is in use?
Do not turn this note into an administrative burden. If you can only describe the problem and the goal so far, start there. Avoid sending confidential data; requirements for handling sensitive information can be discussed before it is shared.
What needs clarification after you send the brief?
The initial information helps identify unanswered questions and possible work. If the existing system needs further assessment, its scope and any fee are discussed before that work takes place.
Before accepting a proposal, check the deliverables, content work, integrations, revision limits, checks, payment, and estimated schedule. Also examine recurring costs, usage rights, the access to be handed over, and help after launch.
Choose one contact to coordinate decisions. Several people can still contribute feedback, but the final instructions need to be consistent. If requirements change, agree on the effect on cost and timing before additional work starts.
A brief supports the discussion; it is not, by itself, an order or agreement to every service. Work follows the accepted proposal and service terms. You do not have to resolve every detail alone before starting a conversation, but important decisions need to be clear before development begins.
Frequently asked questions
What should I prepare before requesting a website, app, or system proposal?
Start with your business, the problem to solve, the users, priority functions, existing content or systems, and any target date and budget range. Unknown details can be discussed; you do not need a complete technical document to contact me.
Can I request a proposal if I do not understand the technology?
Yes. Explain the work you want to simplify in everyday language. Example workflows, blank forms, or screenshots without confidential information can help. Technology choices and feasibility are discussed once the purpose is understood.
Is the number of pages enough to determine a website's cost?
No. Content types, functionality, languages, editing facilities, integrations, and the readiness of your materials also affect the work. Two websites with the same page count can have different scopes.
Does sharing a budget range mean the whole budget must be spent?
No. A budget range provides a boundary for discussing options and priorities. The quoted price follows the agreed work and services, rather than an obligation to spend your entire budget.
Do I need to send passwords when asking for a proposal?
Not for the initial discussion. Send an overview and examples without credentials or personal information. If a further assessment requires access, agree on permission, scope, and how access will be provided first.
Does a proposal automatically include source code and maintenance?
No. Source code, management access, maintenance, migration, training, and support each have their own scope. Source code delivery is not automatically included and may not be available. Check the deliverables and usage rights specified in the proposal.
