How to Accept Submissions

One of the other major facets of starting a literary magazine is the receiving and sorting of submissions. There is no way anybody would send me, a nobody, a printed submission in this day and age, so I’m not going to bother with a physical slush pile. As I’ve looked around, there are a few options for accepting submissions.

  1. Email – Of course, this is the simplest to implement. Just have authors send an email to a dedicated email address. And I could set it up with tagging/folders to stay organized.
  2. Submittable – Submittable is a web app that handles everything for submissions. I understand it has lots of options on the publisher end. A couple of the magazines to whom I’ve submitted use it, and it’s pretty easy for an author to use, too. The biggest hangup for me is the price. They have 2 levels of subscription, one at $31/month and one at $66. That’s not totally absurd, but it’s just not something I want to pay at launch. Another tiny hangup is it appears to have a few too many options.
  3. [](Green Submissions) – It’s a free to use submission manager app. It is nowhere near as slick as Submittable, and does not appear to be quite as user-friendly. It is however, free to use. I could also buy the software that powers Green Submissions, but it doesn’t look like it’s been updated in a while, nor do I know how easy it is to customize. And besides, if I want to make it better I might as well…
  4. Make my own – this is a problem among many programmers I know, myself included. A big part of me just wants to code up my own submission manager. Like I’ve already put down like three different starts on code.

Since the magazine I’m thinking about would be just me running it, I’d start with email. It’s easy to use and keep organized, and nobody should have a problem using it.

2 thoughts on “How to Accept Submissions

  1. How hard is coding a sub manager? I have no idea how to even begin that project. How do you decide what’s needed? What’s your process?

  2. It would not be terribly difficult to make. Of course, everything always takes longer than I think. My processes is to design it on paper, then in a text file. I make sure I’ve thought of most of what the site is going to need/do. Sometimes I’ll sketch up some wireframes. Then I go off the deep end and shop for a new programming framework. That kind of depends on what language I want to use (js, php or python) Different frameworks provide different levels of built in stuff. Then I’ll usually make some kind of plain-jane html pages to act as a base.

    I make sure I have a testing server up and running (meteor.js has a built in server, and there are lots of free, usable wamp/mamp servers), download/git a fresh copy of the framework, then start integrating the html pages I made, then add functionality into those pages.

    For the three starts I’ve made, two were in php frameworks (fat free framework and one other I can’t remember off hand) and one was in meteor.js. I didn’t get very far, maybe an hour in to each, before I realized I should be writing. I usually start with the user system, which is probably a mistake. Add core functionality first would be better.

Leave a Reply

Your email address will not be published. Required fields are marked *