How to Start a Project With Codeveil Studio (and What Happens After You Submit)

Every project we take on starts at the same place: the brief form at /start-your-project. It is deliberately longer than a contact box, because the questions it asks are the same ones we would otherwise have to ask you over three emails before we could say anything useful about cost or timeline.

This guide walks through what each part is actually for, which answers carry the most weight, and what happens on our side once you submit. If you are about to fill it in, reading this first will get you a sharper reply.

What happens after you hit submit

Before the fields, the outcome. Submitting the brief does not put you in a sales funnel. It starts a short, bounded sequence with a written proposal at the end of it.

You also receive a confirmation copy of your own brief by email the moment it is submitted, so you have a record of exactly what you told us.

The form in three parts

The brief is grouped the way we actually think about a project: who we would be working with, what is being built, and what the constraints are.

• Client details — name, email, country, and an optional phone or WhatsApp number. Country matters more than people expect: it sets the timezone overlap for calls.
• Project basics — company, project name, the service you need, and the target industry.
• Scope and delivery — project stage, budget range, timeline, and how you prefer to be contacted.
• The written part — a description, your business goals, and any reference links.

The five answers that decide your quote

Not every field carries equal weight. These five do most of the work in turning your brief into a number.

• Project stage — "Just an idea" and "Requirements are ready" lead to very different first steps. The first needs a discovery pass; the second can often go straight to scoping.
• Service needed — this routes your brief to the right practice lead, so the person replying has actually built the thing you are asking for.
• Budget range — the single biggest signal. It does not set the price, it sets the shape of what we propose.
• Timeline — "ASAP" and "Flexible" change the team structure, not just the schedule.
• Description — the field where most briefs are won or lost. See below.

Writing a description that gets a real number back

The difference between a vague brief and a strong one is not length. It is whether we can picture a specific user doing a specific thing. Compare these two versions of the same project.

A description we can act on usually answers four things without needing to be long.

• Who the user is — patients, warehouse staff, your own support team.
• The one core action they perform — book a slot, submit a claim, generate a report.
• Rough volume — 400 users a month is a different build to 400,000.
• Anything that must integrate — an existing CRM, a payment provider, a legacy database.

Four sentences naming a real user, a real action, and a real volume beat four paragraphs of adjectives every time.

About the budget field

The most common worry about the budget dropdown is that naming a number means paying that number. It does not work that way. The range tells us which version of your project is worth proposing — whether to scope the focused build that fits, or tell you honestly that what you described does not fit the range and explain what would.

"Need guidance" is a genuine option, not a placeholder. Choosing it means the proposal comes back with options at different levels rather than one fixed figure. If you have never commissioned software before, it is usually the right answer.

The fields people skip, and why they matter

Three optional fields do more work than their position on the form suggests.

• Business goals — this is separate from the description on purpose. The description says what to build; goals say what success looks like. "More qualified leads" and "reduce support load" lead to genuinely different builds of the same feature.
• Reference links — competitors, a Figma file, a product you admire, even a screenshot of the spreadsheet you are replacing. One link often saves a whole round of clarification.
• Preferred contact — email, WhatsApp, phone or video. Picking the one you actually check means the reply does not sit unread for three days.

Choosing a timeline honestly

The timeline dropdown is not a wish list, and "ASAP" is not a free upgrade. A compressed schedule usually means running design and build in parallel and adding people, which raises cost and, past a certain point, raises risk too. Nine people cannot deliver a baby in one month.

If you have a real external deadline — a funding round, a trade show, a contract start date — say so in the description rather than only selecting "ASAP". A date with a reason behind it is something we can plan backwards from. An unexplained rush is something we have to pad for.

If you already have something built

Two of the project stages exist specifically for this: "Existing product needs improvement" and "Need ongoing development team". Both change the first conversation from scoping to assessment.

For an inherited or existing codebase, the most useful things to mention are what stack it is on, whether the original developers are still reachable, and what specifically is failing — performance, bugs, a feature that cannot be added, or simply that nobody can safely deploy it. That last one is more common than people admit, and it is a solvable problem.

What we do not do

• We do not ask for payment before the written proposal is agreed.
• We do not send an estimate without reading your description properly first.
• We do not pad a scope to reach a budget number you mentioned.
• We do not chase. If the timing is wrong, tell us and the thread ends there.
• We use your details only to respond to the request.

If your project is still fuzzy, submit anyway and pick "Just an idea" as the stage. A brief that honestly says "I am not sure yet" is far more useful to us than one that guesses at answers to look organised. The scoping call exists precisely to turn the fuzzy version into something specific enough to price.