How to brief a software studio in one message

Most people put off contacting a software studio because they think they need a requirements document first. You do not. Our contact form asks for a name, an email, and one message, and next to it sits a panel with three prompts: what you are trying to get done, what is in the way today, and any deadline that actually matters. That is the whole brief. This post explains why those three lines, and not a spec, are what we need, and what each one changes in the reply you get back.

What happens to your message

Every message goes to an engineer, not a sales inbox. Within 24 hours we reply, and the goal of that reply is a plan, a timeline, and a price, or the one or two questions standing between us and those three things.

That first reply is the start of what our process calls Listen: mapping your actual workflow, where time leaks, where data stalls, what "done" means to you. Next comes Scope, a fixed plan with real milestones and a real price. Your first message does not have to do the scoping. It only has to point us at the right problem so the Listen step starts in the right place.

The three lines, and what each one buys you

1. What you are trying to get done

Write the outcome, not the feature. "Our sales team should see a customer's full order history before a call" is a brief. "We need a CRM" is a product category.

The difference matters because it decides which of our four services you actually need. The same sentence about order history could be answered by custom software, by configuring a platform you already pay for, or by wiring two existing tools together. If you name the outcome, we can propose the smallest thing that delivers it. If you name the solution, we can only quote the solution, even when a cheaper one exists.

Basecamp's Shape Up ↗ makes the same point about internal pitches: always present the problem with the solution, because without a problem there is "no test of fitness to judge whether one solution is better than the other." That holds just as well for a message to an outside team.

2. What is in the way today

This is the most useful line in any brief, and the one most often skipped. Describe the current workaround, honestly:

• "Two people re-type orders from email into a spreadsheet every morning."
• "Our booking site breaks on mobile and we lose the weekend traffic."
• "We pay for a platform that does this, and nobody can get it set up."

The workaround tells us three things a feature list cannot. How painful the problem is (one person, ten minutes a week is a different job from two people every morning). What data already exists and where it lives. And what "better" looks like, because the new system only has to beat the workaround, not some imagined perfect version.

3. Any deadline that actually matters

"ASAP" is not a deadline. A trade show on March 12, a contract renewal, or a season that starts on a fixed date: those are deadlines. They change the shape of the plan, because a real date lets us split the work into what must be live by then and what can follow.

If there is no real date, say so. That is useful information too: it means we can order the work by value instead of by urgency.

Useful extras, if you have them

None of these are required, and none should hold up the message:

• A link. Your current site, the app, the tool you use today, or a product you want to feel like. One link is worth a paragraph.
• A budget range. Our pricing is fixed for well-defined scopes and time-and-materials for evolving ones, and either way you see the number before work begins. A range up front lets us propose the version that fits it instead of the version we would build with no limits.
• Who decides. If the person writing is not the person approving the price, tell us. It changes who we should get in front of in week one.
• Where your team is. We work from Alexandria at UTC+2, and we cover the overlap math for US and EU teams in a separate post.

What not to do

• Do not wait for a full spec. Writing it is part of our job, and it goes faster when we write it with you instead of decoding one written alone.
• Do not send only a feature list. Twenty bullet points without the problem behind them get you a quote for twenty features. Two sentences about the problem may get you a quote for five.
• Do not hide the messy part. The legacy system nobody wants to touch, the spreadsheet with 40 tabs, the vendor contract you are stuck in. The messy part is usually where most of the work is. Knowing about it on day one is how the price we give you stays the price you pay.

Where this breaks

Three lines are enough to start a conversation, not to price a large platform. If the project is a multi-month build with several integrations, our first reply will be questions, not a number, and we will say so. The three lines still matter there: they decide whether the questions are the right ones.

They also cannot replace a call when the problem lives in someone's daily workflow. Some things are faster to show than to describe, so the Listen step sometimes means a screen share of the current workaround. That is a good sign, not a failure of the brief.

The template

The exact shape we ask for, plus the optional extras. It works for any studio, not only us:

GOAL       what should be true when this is done (an outcome, not a feature)
TODAY      the current workaround, who does it, how often
DEADLINE   a real date and what happens on it, or "no fixed date"
LINK       optional · current site, tool, or a product you want it to feel like
BUDGET     optional · a range, even a rough one
DECIDES    optional · who approves the plan and the price

The takeaway

A good first message is short and specific about the problem, not long and specific about the solution. If you can fill in GOAL, TODAY, and DEADLINE, you have written a better brief than most requirements documents, and any studio worth hiring can turn it into a plan. If a studio needs more than that before it will even reply, ask what it plans to do with the extra detail. Then send us your three lines and see what comes back.

← the journal