Why a little preparation changes the conversation
Most first calls with a studio are spent working out what the project actually is. A short brief moves that forward. You get a more accurate estimate, better questions back and a quick sense of whether the studio understands your business.
The brief does not need technical language. Studios are used to translating business needs into features and screens. What they cannot guess is your goal, your customers, your constraints and your priorities. That is what the brief is for.
Writing it helps you, too. Putting the project on one page forces the decisions that otherwise surface halfway through a build: who the product is really for, what can wait, and how much you are prepared to spend. It is also the easiest way to give several studios the same starting point.
Start with the goal, the users and the must-haves
The goal
What should be different once this is live? Describe the outcome, not the feature list. "Take bookings online so staff stop handling them by phone" is far more useful than "a booking system", because it tells the studio what success looks like and what can be simplified.
The users
Who will use it, and in what situation? Customers on their phones, staff on a desktop at the front desk, managers checking reports once a week. Include anyone who needs a different view or permission level, because each role adds screens and rules.
Must-have features
List only what the first version cannot launch without, then put nice-to-haves on a separate list. This one distinction does more for your budget than anything else. Our guide on scoping an MVP that actually launches shows a simple way to sort them.
Then add examples, budget, deadline and who decides
Examples you like
Share two or three websites or apps you like and say what you like about each: the layout, the checkout, the tone of voice. Examples beat adjectives like "modern" or "clean", which mean different things to different people. Examples you dislike are useful too.
Budget band and deadline
Give a budget band, even a rough one: under $5,000, $5,000-$15,000, $15,000-$50,000 or $50,000+. It lets the studio propose what fits rather than guessing. Add your target launch date and whether it is fixed, such as a trade show or season, or flexible.
Who decides
Name the person who approves the scope, the design and the launch. Projects slow down most when decisions wait on someone who was not involved from the start, so bring that person into the first conversation if you can.
A brief outline you can copy
Paste this into a document and answer each line in a sentence or two. One page is plenty.
- Project name and one-line summary: what you want to build, in plain words.
- Business goal: the outcome you want, and how you will know it worked.
- Users: who uses it, on which devices and in what situation.
- Must-have features: the minimum needed for launch.
- Later features: useful additions that can wait.
- Examples: two or three links, with what you like about each.
- Existing assets: brand guidelines, content, a current website or systems.
- Integrations: tools it must connect to, such as payments, CRM or booking.
- Budget band: under $5,000, $5,000-$15,000, $15,000-$50,000 or $50,000+.
- Deadline: target launch date, and whether it is fixed or flexible.
- Decision-maker: who approves scope, design and launch.
- Contact: the best person and way to reach you.
Aim for honest rather than polished. "Not sure yet" is a perfectly good answer for any line, and it tells the studio where to focus its questions. A rough brief sent this week is more useful than a perfect one sent next month.
Extras that help, but are not required
- A list of the accounts involved, such as your domain registrar, hosting or analytics, so access can be arranged later
- Current numbers you want to improve, such as inquiries per month or time spent on manual admin
- Known technical constraints, like an existing system that must stay in place
- Legal or compliance needs, such as data protection rules in your industry
- Previous attempts at the project, and what went wrong
- Photos, product data or written content you already have and can reuse
Do not put passwords in a brief or an email. A good studio will arrange secure access once the work starts, usually by having you invite them to each account.
Questions to ask the studio
- Have you built something similar, and can you walk me through how it went?
- Who exactly will work on my project, and who is my day-to-day contact?
- How do you break the work into phases, and when will I see progress?
- What is included in the estimate, and what is not?
- How do you handle changes to the scope once work has started?
- How do you test before launch, and on which devices?
- Who owns the code, design files and accounts when the project ends?
- What support do you offer after launch, and how is it priced?
- What do you need from us, and how much of our time will the project take?
Listen for specific, plain answers. A studio that can explain its process clearly is usually one that follows it. Pay attention to the questions they ask you, too. Good ones probe your goals and users before talking about technology.
Red flags to watch for
- A firm quote without questions. If they have not asked about your users or goals, the number is a guess.
- Yes to everything. Good studios push back, suggest cuts and explain trade-offs.
- No written scope. You need a clear list of what is and is not included.
- Vague ownership terms. You should own your code, content and accounts once you have paid.
- A large payment upfront with no milestones. Payments should follow visible progress.
- No plan for after launch. Every product needs fixes and updates.
- Pressure to sign quickly. Discounts that expire in days are a sales tactic, not a sign of a good partner.
What happens after you send the brief
Expect a reply with clarifying questions, then a call to walk through the project. After that, a good studio will send a proposal with scope, phases, timeline and cost, often with options at different levels. For larger or less defined projects, a short paid discovery phase to map requirements before committing to the full build is common and usually worth it.
At AXURS, you can share your brief through our project form or by email at info@axurs.com. If you are still shaping the idea, our guide to website costs in 2026 and our services overview are good next reads.
Frequently asked questions
Do I need a technical specification before contacting a studio?
No. A one-page brief describing your goal, users, must-have features, examples, budget band and deadline is enough to start. Turning business needs into a technical plan is part of the studio's job. If your project is large or unclear, the studio may suggest a short discovery phase to define the details before the build is priced.
Should I share my budget with a studio?
Yes, at least as a band. Without a budget, a studio has to guess whether you want the leanest workable version or a fully featured product, and the estimate will be less useful. Sharing a range such as $5,000-$15,000 or $15,000-$50,000 lets the studio propose what fits and explain what would need to wait for a later phase.
How many studios should I talk to?
Two or three is usually enough to compare approaches without losing weeks. Send each the same brief so you can compare proposals fairly. Look at how well they understood your goal, how clearly they explained scope and trade-offs, and how they plan to work with you, not just the final number.
Should I ask a studio to sign an NDA first?
It depends on how sensitive the details are. Many studios will sign a reasonable NDA, especially when proprietary data or processes are involved. For a first conversation, a general description is often enough, with sensitive specifics shared once an NDA is in place. The idea itself is rarely the risky part. Execution is what makes the difference.
Who should own the code and accounts?
You should. Once you have paid for the work, your contract should give you ownership of the code, designs and content. Accounts such as your domain, hosting, app store listings and analytics should be registered in your business's name, with the studio given access. That keeps you free to change providers later.