Gut decisions can result in great results. Here are some considerations as you decide whether to take a more evidence-based approach or to rely on your instincts: 1) Will you need to ensure that this decision is implemented by a large team of people? If so, working to explain the rationale for your decision, and going beyond your gut may be justified. 2) Is the decision counter-intuitive in any way? If so, it may be worth taking the time to decompose your decisions into pieces (more on that below) to explain your rationale. 3) Does this decision depend on assumptions that are non-obvious? If so, you may want to be explicit about the assumptions you are making, and then to track those assumptions so that, if they change, you'll revisit the decisions. 4) Are you trying to achieve more than one outcome with this decision? For instance, are you trying to maximize both short- and long-term margins? Are you trying to achieve financial results while also doing some social good? If so, then your "gut" may not be great at keeping track of all of those factors, so you might want to do a more detailed analysis 5) Is it possible that you may have to change this decision frequently? If so, then you're going to quickly lose credibility with your team unless you can explain your rationale, e.g. "this decision was based on an assumption about our competitor's pricing, which changed three times in the last week, therefore we're adjusting the decision so that it achieves the goals we originally intended instead of an unintended consequence" 6) Does this decision interact with other decisions? If so, there's a limit to how much you can track and keep in your head. You may want to map the decision. Again, see below. 7) Are you sure that you and other stakeholders are aligned around your decision outcomes? If not, then even if you end up making a "gut" decision, it might still be worth the effort to meet to discuss those outcomes to ensure you're all on the same page. 8) Are your desired outcomes likely to "drift" over time? If so, you may want to revisit the outcomes with your team periodically to ensure that you're all "rowing the boat" in the same direction. 9) What is the cost of making this decision incorrectly? If it's going to impact lots of dollars and / or human lives, it's probably worth a more diligent approach than a "gut" approach. If you read the above points, you might think that I am recommending against gut decision in general. On the contrary: the human brain stores experiences and evidence in very sophisticated ways, and creates elaborate "decision surfaces" that are often no longer able to be articulated. One of the best-known stores about this is the experienced fireman who, inside a burning building, felt very uncomfortable. Although he couldn't explain his reasoning, he went with his gut and yelled at his team to run out...right before the roof collapsed. So there are many situations in which a gut decision is both necessary and effective. If you do choose, for whatever reason, to go beyond your gut instincts, here are some tips: 1) Set aside the data at first. It interferes with structuring the decision making process. This is sort of like asking coders to stop coding until the requirements and design are done. 2) hold a meeting in which you align the team around desired outcomes. Start with brainstorming: there are no wrong answers, "what are we trying to achieve?" If you do nothing else, this step can have a huge benefit 3) Next, talk about your decision "levers". These are the things that you can change. Again, start with a brainstorming session, then trim back after the ideas peter out to the levers that everyone agrees to. 4) Next, it's time for "externals" These are the environmental / situational factors that combine with levers to lead to outcomes. You can make assumptions about externals (e.g. the finance charge on a new piece of capital equipment) but you cannot change them. 5) Now, work with your team to understand how decision combine with externals to lead to outcomes. Think about how this plays out over time. 6) Look for feedback loops and other system dynamics effects. Ideally you're seeking a "sweet spot" where you can inexpensively get a "virtuous cycle" winner-take-all network effect going. For instance, an investment in a health education program might lead to more screening exams for a disease, which in turn leads to a greater fraction of the population that is healthy, which leads to greater productivity and morale, which leads to greater profits, some of which can be re-invested into improved screening, etc. Be sure to not overlook "intangible" effects involving things that might be hard to measure, like morale, reputation, trust, and satisfaction. Just because they are harder to measure doesn't mean that you should treat them as zero. Your data / analytics can help in three ways: a) to provide information about externals; b) to provide predictions of future values of externals; and c) to help you understand how, and under what circumstances, X leads to Y, where X and Y are the two sides of a cause-and-effect link. For instance, you might have a study showing that investment in a health education program increases the percentage of people being screened for a disease. Alternatively you might not have this data, and so may choose to invest in the study or data collection exercise. Do this *after* you've answered the above questions, otherwise you can spend a lot of unnecessary time gathering data that actually has no impact on your outcomes! I would love to help you with any of the above.

I'll second the recommendation for Zendesk. Their agent support portal is professional, highly customizable, and they are responsive and friendly. Their help desk portal is less mature, but quite a good value. We used it for a while with just one or two agents and loved it!

If you look at history, the great problems of the world took decades to solve. Unlike a lot of fast-growth stories, often you have to be in it for the long haul. So the key question is: do you want to give it your all to make this happen? If so, then you know what to do: pivot, pivot, pivot, until you find the market fit, keep talking to everyone who might buy. Continually test whether there is a need for your product. Treat your pipeline as sacred. Get a cofounder. And listen to your gut.

Some great advice in these answers. Here are some specific questions to ask: 1. Will you be selling to consumers or businesses? This will impact your choice of stack 2. What level of sophistication do you need in web functionality? If you simply need to display information, such as in a web site, then you will make a very different choice than if you are building an application with interactivity. If, in addition, you'll need to store data, then you'll need to make choices about the data back-end. If, in addition, you'll need to do a lot of processing on the server, then you're going to make a different choice than if your performance needs mean you can stick to client-side processing. 3. Have you validated the concept? If not, then consider starting with "pretotyping": building a landing page and an adwords campaign to test interest in your offering, and then doing A/B testing to pivot until you've found a point of resonance. This is particularly helpful for consumer plays. You can build this in less than a day. 5. If you're B2B then consider a B2B interview campaign. Even a short study, with a dozen or so participants, can go a very long way. Ask people who might ultimately be users to give you advice. There are some tricks to getting decision makers on the phone, too, in such a way that everybody wins. 6. What ultimate level of performance will your application need? Cloud- and web-hosted apps will eventually hit a point of diminishing returns. But you might not hit that for a very long time. 7. Will there be particular security or privacy requirements? This can have an impact on your cloud choices, and also on the software you'll need to build. You should know that javascript has come a long way in the last two years: there is unprecedented power and functionality in the hundreds of javascript libraries out there. for instance, you can do gorgeous ray-traced, interactive 3D graphics in a web browser now, using a library like three.js. This is a sea change, imho. Finally, I'd like to reiterate a point made above: get it out fast, get some feedback in whatever way makes sense to you. Technology is hard, but finding a fit of technology to a point of pain that really solves an important problem, and that isn't solved elsewhere, is hard to the power of hard. It's easy to get distracted by technology and technologists. Market/technology fit should always be your primary focus.