Well, that's great news! Art of Problem Solving has a long and storied tradition of mock competitions. It's great to see that you're interested in continuing this tradition! However, know that because the history of mock competitions goes back so long, there is a great deal of honour and responsibility placed onto the young ones who choose to embark on this journey.

I know what you're thinking: "How can I make sure I use this honor to my advantage?" Great question! It all starts with the idea....
[list]
[*]Decide what type of contest you want to write. This may seem like a simple step, but it goes a long way into deciding how the fate of the contest will play out. Choose whether you want to write an AMC8/10/12, an AIME, an USAMO, or something completely new and unexpected. By doing this now, you'll be able to gauge the difficulty of the questions and can set up your mind appropriately. (That being said, you don't have to necessarily stick to your original idea! However, knowing what you're going to write ahead of time is beneficial in terms of organization.)
[*]Start writing problems! Usually a .tex file will suffice. If you're collaborating with others, a Google Doc (with a add-on such as Auto-Latex Equations enabled) or ShareLaTeX/Overleaf file works best. Keep your questions organized in some sort of shortlist, possibly sorted by category. Don't start organizing questions into the actual contest just yet - it's too early to start pigeonholing yourself! Just start exploring ideas and see what comes. This is probably the time when you'll write the most number of problems per day.
[*]Don't post about the contest on AoPS yet! As is often said... wait darn, I forgot the adage that's quoted here... oops
[/list]

"Wait", but you say, "writing problems is hard D:".

Well, I agree, young one! Nobody ever said administering a contest would be easy. (Well, almost no one.) How exactly does one go over the hurdle of writing problems?

[list]
[*]Write problems backwards. This is one of the standard problem-writing techniques. Essentially, it boils down to "here's an interesting idea - how can I mold it into a problem"?
As an example, consider this problem from NIMO Contest 15. Over the summer, I was interested in writing a problem that revolved around the factorization . After playing around a bit, I realized that the second factor could be written as , meaning that I essentially had a functional equation of the form . This then led me to try writing a telescoping problem. Trying things involving partial fractions didn't work, but working with products did yield something cool. I then realized that what I had created could be molded into a nice-looking form, and after a few more adjustments I came up with the finished product.
[*]Also write problems forwards. This is another one of the standard problem writing techniques. This technique in simplistic form is "here's an interesting idea - what results can I get from it that can turn it into problems"? It seems very similar to the previous bullet point, but in fact it's quite different: here, you have no idea what the end product is going to involve.
As a (very) extreme example, consider this problem from NIMO Contest 21. This problem actually started development two years ago, when I was inspired by an AMSP Team Round question to look at constructing triangles with a given inradius and circumradius. I made no progress on this for a long time, but in February of this year, I realized that the formula essentially killed the problem I had in mind. With this breakthrough, I hid the true meaning of the question and eventually came up with this.
Around late July 2015, I gave this problem to Evan in a set of problems to check; his interpreted the problem in a completely different manner, responded with "the key observation is <something completely different from what I had intended>" and rephrased the problem in terms of perimeters. This new version I considered nice enough to end up submitting to the NIMO database.
However, the problem still wasn't finished evolving! When putting the problem onto Contest 21, I was unsure of the difficulty (and the configuration, but that's a different story) because it seemed like the problem was too focused around noticing one trick. I played around with the configuration a bit more and found that knowing the distance between the incenters and those two perimeters allowed one to uniquely determine the trapezoid! With this discovery in mind, the problem finally became the finished product put on the contest.

... what was I saying again? Oh right, problems!
[*]Don't artificially inflate the difficulty of problems by adding unnecessary components. This is a common pitfall for beginning problem writers (and experienced ones, too!) As a rule of thumb, the amount of work needed to compute the answer to a question should be at most the amount of work needed to find the main idea, unless the computation is part of the main idea itself. For instance, a problem asking to find the value of is a bad problem because although the idea of geometric sums is easy, computing is not.
[*]Using well-known problems as inspiration is okay; using them for the finished product is less okay. Long story short, don't try to put problems that 90% of the participants will have seen before. Of course, if you're running a deadline and the problem is really really obscure, odds are high that nobody will notice, but leaning on this is bad practice, especially in the long run.
[*]Don't overestimate the difficulty of the early problems! This is an extremely common mistake that occurs in user-generated contests. Remember, the AMC's (for example) are meant to be accessible, and as such the early problems are not supposed to be hard. If you're having trouble determining whether a problem is appropriate for the beginning, look at early problems from previous contests and compare them! (Or better yet, have a friend compare them!)
[*]Try to be creative! The problems that are most remembered are the ones that take familiar concepts and twist them in new and interesting ways. This is one of the reasons why Mandelbrot problems are so highly revered - they may not be the hardest problems ever, but you sure can't accuse them for lack of originality! Take care into writing your problems - after all, the contest is your work, and how quality the finished product is can affect the way people perceive you for future projects. (This is easier said than done. Often times, the cure for badproblemaphobia is simple: practice writing more problems! Question-creation is just as much of an art form as mathematics itself.)[/list]

“Okay”, you say. “I have all the problems written, and I’ve made sure all the answers are correct. Now what?”
Well, it’s time to release to the world!
[list]
[*]Advertise your product! Be proud of what you’ve written. But don’t release the test yet! Give your contest time to spread through the community.
[*]Make clear the method in which you have participants sign up. Also, make sure it’s organized. Recently, there have been some mock contests which have had flawed methods of signup and suffered because of it. Think through how you want to administer the contest before you announce it to the AoPS-verse. (These are all important things to ensure a successful mock!)
[*]Recruit testsolvers! It’s easy to look over potentially fatal flaws if you’re the only one who looks over the test before it’s released. Get a few friends to help look it over! Some contests prefer to do this through sign-ups analogous to the normal ones; others just prefer to PM their prospective targets directly. Either way, get a bunch of people to agree, because not everyone will ultimately have time to follow up. (I’m not saying this in an evil and bitter way – it’s just human nature!)
[*]Prepare for the big day! It’s almost here!
[/list]

All right, the lights are on, the stage is set, and the cameras are ready. Action!
[list]
[*]Make the location of your test clear. Once again, be proud of your work!
[*]Take errors with grace. Sometimes, even with test-solvers, mistakes happen! Don’t let them pull you down too much. Make changes to the actual test, notify users (whether in-thread or through PM) of the changes, and adjust scores accordingly.
[*]Ask for feedback! Problem writers are always looking for ways to improve, so give honest criticism! I usually like to achieve this through a few questions at the end of a Google Form. This usually generates healthy participation, although other methods can probably work just as well.
[*]Watch as scores pour in! Whoo!
[/list]

And that’s all! If you have any ques…

“… that’s a lot of work. Are there any examples I can use to convince myself something like this is even possible?”
[list]
[*]All official AMC/AIME contests. These are contests written by people, too! More importantly, many of the individuals who contribute problems to these contests are not professional problem writers – they’re volunteers, willing to put in time to write interesting questions for the world to see.

But I imagine this was not the answer you were looking for? Fine….
[*]Mildorf’s Mock AIMEs. These five AIMEs are often referred to as the gold standards for mock contests. These are really hard (especially for pre-2005 times), and can give you a sense of the potential of what a mock contest can look like.
[*]djmathman’s Mock AMC10/12. Okay, maybe I’m a bit biased here, but I can afford to be a little biased, right? In any case, this AMC was met with generally positive criticism, so there’s that. The AMC10 is probably similar if not a bit easier than usual, while the AMC12 is much easier than usual. (This was the result of announcing the contest prematurely!)
[*]The 2015 Mock AIME I. “Okay seriously man, what’s up with all the bias?” Eh, I still think this is an objectively good example of what a mock AIME should look like, even if the difficulty curve is a bit wonky. (This was originally designed to be a Mock Mandelbrot competition, after all!)
[*]The 2015 Mock AIME II (henrikjb). I haven’t been able to look at all the problems in detail, but I can say that the ones I have looked at are of high quality! Another example of the potential a mock contest can deliver.
[*]Many other examples! These are just the contests I remember. If there’s a good example that I’ve overlooked, feel free to link to it in the comments!
[/list]

“I’ll check those out, thanks!”

Any last questions, young fellow?

“I’m still not sure if this thing is right for me. Can you provide some words of encouragement?”
[list]
[*]Even though AoPS can be a divisive community at times, just remember that we’re all here to support you! Writing contests is hard. Nobody’s gonna give you a hard time for a contest you genuinely put thought and effort into! Just remember: as budding mathematicians, we’re constantly looking for good problems to chow down on; as long as that goal is accomplished, the contest was a success. We’re rooting for you!
[/list]
“Yay! Thanks for all the advice, Mr. Omniscient Voice! Time to start writing problems!”