The author

Jimenez Julien, the person who built DraftAndQuery

Publication director at MLJ, SASU, and the one who answers the contact form on this site.

Portrait of Jimenez Julien

Contact the author

Write to jimenezjulien42@gmail.com. Replies come within one business day, from him, in English or French.

Book a walkthrough

Why this product exists

DraftAndQuery started with a shoebox of rejection letters and a spreadsheet that had four columns too few. A friend of mine, a short story writer with two collections behind her, asked me to help her work out whether a particular press still had her manuscript. It took us most of a Saturday to reconstruct the answer from an inbox, and the answer was that they had held it for fourteen months and she had never asked. She had also, in the meantime, sent a superseded draft to a magazine that liked the earlier one better. Neither of those failures was about talent or discipline. They were record keeping failures, and record keeping is a thing software is genuinely good at.

I spent the following year talking to authors, two literary agents and the reading staff at three small presses in the United States. What I heard again and again was that the tooling on offer was either a database built for a big house, priced accordingly, or a spreadsheet template downloaded from a blog in 2016. Nothing sat in the middle for a working writer with six projects and a day job, or for a press that reads four hundred submissions a year with two part time readers and a shared inbox.

So the shape of the product came from the trade rather than from a product roadmap. A manuscript is not a task. It is a thing that has versions, and each version has a life of its own once it leaves your desk. A submission is not a status field. It is a relationship with a named person at a named house who told you, in writing, how long she would take. The whole application is built on those two facts: version records that never overwrite each other, and submission records that carry a stated response window and a follow up rhythm calibrated to what that house actually said.

What I learned about this trade

Three things surprised me. First, that the most damaging problem is not rejection, it is silence: work that sits in a queue nobody is tracking, past the point where a polite withdrawal would have freed it. Second, that authors are far more reluctant to follow up than presses want them to be. Every acquisitions editor I interviewed said some version of "please nudge me, I lose things." Third, that the version problem is quieter than the tracking problem but more expensive, because sending the wrong draft is a wound you cannot see until months later.

Those findings shaped the follow up queue, which is deliberately conservative. It never suggests a nudge earlier than the house's own stated timeline plus a margin, because the point is to protect the relationship, not to generate activity. It also shaped the exclusivity flags, which will stop you queueing a send that conflicts with a promise you made in writing four months ago and have half forgotten.

How I work with authors and presses

I run demonstrations myself, one at a time, with your real data on the screen. If a feature does not fit the way your desk runs, I would rather say so on the call than sell you a subscription you cancel in March. Users can reach me directly rather than through a ticket queue, and the changes that ship most often are the ones a subscriber described in a two paragraph email. The reading queue view in the Small Press tier exists because a publisher in Arizona sketched it on a napkin during a video call and mailed me a photo of the napkin.

Experience and expertise

  • Publication director of MLJ, SASU, the company that publishes and operates DraftAndQuery.
  • More than a decade building and running small web products, with a focus on tools for independent operators rather than enterprise buyers.
  • Field research with authors, literary agents and acquisitions readers across the United States, France and the United Kingdom.
  • Responsible for product design, the written copy on this site, data protection practice and customer support.

How this product is built and maintained

Every statistic published on this site comes from either aggregated, anonymized platform data or from a named customer who agreed to be quoted. Nothing is estimated and then rounded up. When a number changes, the page changes with it. Testimonials are published with the full name, role, business and city of the person who gave them, and every one has been read back to that person before publication.

On the product side, releases go out weekly. Anything that touches manuscript files goes through a restore test before it ships, because the worst thing this application could do is lose a draft. Backups run hourly and are kept for thirty days. There is no advertising tracker, no third party analytics cookie and no data sale, on the marketing site or in the application. Support requests are answered by a person, and the person is usually me.

If you find an error on this site, a broken promise in the product, or a claim you think is overstated, write to me. Corrections get published, not quietly deleted.

Published articles

These are the nine reports I have written for The Query Desk, the magazine attached to this site, each one answering a question authors and presses actually ask me.

Profiles