~$ rebootworks
before you write

what should I include in the first message?

what you're trying to achieve, roughly when, and any constraint that matters: a budget ceiling, a deadline, an existing system you have to keep. links to what you already have help more than a long description.

the form on the contact page has five fields and only three are required: your name, an email we can reply to, and a short message. company is optional, and the "what do you need?" menu routes the note, it doesn't test you. if none of the nine options fits, pick "not sure yet, help me figure it out" and carry on.

what goes in the message

the placeholder in the box is the whole brief: what are you building or fixing, who is it for, and is there a deadline. then add anything that would change the plan if we didn't know it.

  • the goal in one sentence, in your words, not ours
  • roughly when: a launch date, a client deadline, or "no rush"
  • a budget ceiling if you have one. it saves a round trip
  • what already exists: the current site, the app, the ad account, the spreadsheet
  • anything that has to stay: a system you can't replace, a vendor you depend on

links beat descriptions. the URL of the current site tells us more in ten seconds than three paragraphs about it, and a screenshot of the error beats a description of the error every time.

what you can leave out

you don't need to write a specification or pick a technology. you don't need a diagnosis either: if something is wrong and you don't know what, say exactly that, because working out what's wrong is part of the job. you also don't need to know which of our three practices it falls under. not being technical is the normal case, not the exception.

a human reads it within one business day, monday to friday, and replies by email with two or three questions. if you're mid-incident, email us with "incident" in the subject line and it goes to the front. from there, the scoping conversation and the written plan are free.

read it in context