There isn't a lot of published information that I've seen (or can quickly find) on how washio and postmates validated their business model, but I definitely agree that starting fairly lean and validating your business first even if that means a lot of manual effort up front is a better approach than investing heavily in infrastructure before launch. Of course, if you are very successful, that manual work will pile up quickly and managing it could be quite painful, but you can have worse problems than a successful launch. Maff Rigby's 7-day startup recommendation is definitely a good one.

Find a niche. Establish your expertise / authority in that niche by writing about it, giving talks on it, consider things like a drip-email campaign. Without a niche, you're competing with every other software development firm out there, and it's hard to differentiate. With a niche, you can establish your authority. The niche can be a platform, particularly a new platform where it's easier to establish authority, or it can be solving a particular class of problem (e.g. customer on-boarding, A/B testing, migrating subversion to git, etc.).

Absolutely, it's alright. Developed intuition through experience is often better than a detailed decision matrix in terms of results. When experts rely on their intuition, it's usually called "experience" or "expertise". It might be worth reading 'sources of power' (a book about decision-making and experts) to cull some useful stats that you can use to back up your approach to making decisions: http://www.goodreads.com/book/show/65229.Sources_of_Power Of course, the key element to all of this is to be able to establish a track record that you can demonstrate. Telling someone to "trust you" works well if you've got a demonstrable track record of past successful projects. If you can't show that to a new customer, it'd be harder to sell.

Well, it's certainly completely possible to build a system that would do what you're looking for, but I'd like to believe you can find something off-the-shelf that would accomplish it, since a custom system would definitely cost you more (e.g. thousands of dollars to get a decent system built by a reputable firm). I'm guessing that the students are the clients in this setup? One thing to watch out for is that if the student/client includes their name and/or contact information on their essay, then you (or the system) would ideally sanitize that information out of the essay before sending to the the teacher/employee. I don't know a system that I'd recommend for this, but I hope that someone else is able to recommend something that you like.

I've been a developer, consultant, manager. I've conducted hundreds of phone screens and interviews. Even now, I can tell you that it's difficult to gauge someone's experience, particularly in a short timeframe. I doubt I could accurately gauge someone's experience in three questions. Technical assessment is hard. There's no simple solution, so I can't give you something totally reliable. The two most reliable ways I know to assess someone are: - Referral: If you trust someone's judgement and they've worked with that person before and they strongly believe that person can help you, that's usually been pretty reliable for me. - Actual Work: If you have a very small list of candidates, preferably one that you're seriously considering, start doing some actual work with that person, but keep your options open. Start building trust with regular delivery of working software. Get some early deliverables defined, have that person deliver you an early work product -- maybe a prototype. Continue to build on that incrementally. Either the candidate will show you with each incremental delivery that they can get the job done, or they won't, and you'll be able to make ongoing decisions about whether or not you want to trust the rest of your project to that candidate. But, back to the meat of your real question -- how would you quickly assess a potential candidate to see if they might be a good fit? To be honest, I think trying to assess detailed technical skills if you don't have them isn't really going to work. Any question I could give you, they could fake easily enough if they're more technical than you are. You'd be better off trying to relate to them in the way that you expect to -- as someone who doesn't know programming and will rely on them to bring that skill-set. Ask them questions you want answers to about how easy and hard parts of your project will be. Ask them to help you understand how they will accomplish parts of the project. You won't necessarily be able to assess the detailed technology they're describing, but you will get a sense for whether or not they seem like they know how to go about your work, and whether they'll be able to communicate well with you and give you the information you need. Once you find the right person who can communicate with you, then go back to my earlier response, and work on building trust through continuous delivery of software.

Have you considered seeking investment instead (or already tried)? If it isn't already a profitable business with good revenue, investment seems more likely than a reasonable acquisition. Angel investors are expecting to take risks and it sounds like your product is still in the risky stage.

While definitions of 'good developer' do vary, the ultimate proof is delivery of "good software" (possibly within time or budget constraints). Figuring that out without working with someone is hard. Most technology companies put a lot of work into that and still make mistakes from time to time, hiring someone who ends up not living up to their recruiting evaluation. Even if you could accurately measure 'good developer', someone who meets that definition might not be available, and deciding if anyone who is available is 'good enough' can also be tricky. That said, I think the foundations of the solution have already been posted here, so I'll summarize some of that and add to it: - Accept that it's hard, and that you may make mistakes. - Use any connections you have to get someone technical involved with the selection if you can. - For this kind of work, also make sure they can explain software development and its challenges to you clearly -- you're going to need someone who can do that with you about your software. - Choose an iterative process for software delivery so that you can see the progress as it happens and evaluate success. - Make sure that if you're not happy, you can move on. Be prepared to do so.

Do you have specific concerns about running a closed beta, or are you just generally trying to be prepared for it? Ideally, you would know or seek out an initial group of youth ministers who might be interested in using your application, interact with them directly, perhaps conducting some usability testing in person, but also monitoring their use of the app and continuing to work with them directly throughout the beta. If you are successful at convincing these ministers of the value of your web application, they will help you convince others, which is usually the best way to grow. You might even select some of these initial customers to join a customer advisory board over the long term if that ends up feeling useful. If you have concerns about scale, you can always move from a closed beta to an invite-only beta that helps you manage scale, but I'm not certain that's going to be one of your immediate problems.

Salary surveys, talking to other people in similar positions are reasonable starting points. In my opinion, getting a competitive offer now and again (by interviewing elsewhere) is the easiest way to make sure that you're being adequately compensated.

Usually, personal contacts. Those are the ones most likely to gamble on an unknown, which you are for your first customers. If that won't work, then working with some kind of recruiting firm, doing a lot of legwork yourself with postings and/or networking opportunities are next up.