Inside a 30-minute project brief: what we actually ask

A form gets you generic answers to generic questions. A 30-minute conversation gets us to the actual constraint that will determine whether your project takes six weeks or six months, which is almost never the thing people write down first when asked to describe their project in a text box.

We ask what happens today without any software at all, because the answer tells us what the real baseline is we're improving on. We ask who on your team will actually use this daily, because a tool built for one power user looks nothing like one built for a rotating team of ten. And we ask what's already been tried and didn't work, because that's usually the fastest way to avoid rebuilding the same mistake with better branding.

You do not need a finished requirements document, a wireframe, or a technical document. You need a clear sense of the problem you're solving and, ideally, a rough sense of budget and timeline so we're not planning a six-figure platform when you actually need a focused four-week build. Everything else, we can work out together on the call.

Within a few business days you get a written proposal: a fixed plan, a realistic timeline broken into milestones, and a price that does not move unless what you need changes. No hourly-rate guessing game, no vague 'depends on complexity' language. If the plan doesn't fit what you actually need, we'll tell you that too, on the call, before either of us wastes time on a proposal.