How to open a Virtual Store from Havana?

A generalized question can only get a generalized answer. The most significant accomplishment is validating that the product you have built is a fit with your target market. This is demonstrated primarily by engagement (the people who sign-up or who previously visited, continue to return) and secondarily by growth, ideally based on word-of-mouth or viral growth but effectively converting paid traffic is a great second prize. Other significant accomplishments include: Not running out of money Recruiting and retaining great talent who believe in the founders' vision. Your loved ones not thinking you're as crazy as they thought you were a year ago. I'm happy to talk to you in a call to give you more specifics about what you want to set as your goals more specific to your startup.

If I was just starting out, I'd consider learning Meteor (https://www.meteor.com/). It's just entered version 1.0 and after working with it for a little less than a year I do have some issues with it but it still makes for a very solid framework that gets you up and running very fast. You would only need to learn Javascript, and you can slowly work your way towards nodejs from there (which Meteor is based on) if you want to, or you could get the basics down and focus on learning design if you prefer.

Usually Programmers are only slow when they don't know how to solve a particular problem. So they will spend a lot of time researching and a lot of trial & errors to solve a problem. It is important that before you engage a programmer on a project, you break down the entire project into simple, easy to understand modules. Let him give you an estimate of how many hours he will require to complete each of the modules. Example: a typical site will have a login module, registration, My account, profile etc. So let him estimate how much he will require to do the login. You can go even detail here. (e.g. how much extra time if you were to implement Facebook/Twitter Login?). Once he start developing, track his progress closely and make sure he is following his given timeline. If he goes over his budgeted time on a module, talk with him and see what went wrong. It is often seen that they may be wasting their time on something very insignificant that you may have asked him to implement, but you can totally go by without it too. So by understanding what is taking longer time, you will be able to prioritise things better. You definitely need some tools to get this done. Google Spreadsheet or Excel works just fine. But if you don't mind spending a few bucks there are many agile project management tools that you might look into. Here is a list, google them all and sign up for trials: * AgileZen * Agile Bench * Assembla * AssiTrack * Blossom * Basecamp * Breeze * DoneDone * Eidos * Fogbugz * GreenHopper * Jugggla * Kanbanpad * Pivotal Tracker Or the reason why he is slow can be purely non-technical. Sometime your developer may don't share the same level of enthusiasm as you about the idea that you are working on. They often don't often see the "bigger picture" (since you don't share everything with them explicitly). If you can somehow get them excited about what he is a part of, it will work like a drug :) He will work day and night without questioning you. But you need to work equally as hard as him. The moment he sees that you are the boss and he is just the guy doing work for you -- his mentality will shift from being part of something to being the low paid developer. Ultimately its all about motivation and making him a part of your venture. After all he deserves it, if he is really playing a crucial role in the entire development.

You ask the customers, and gauge their level of interest. Better yet, get yourself in front of some customers, and instead of telling them what you make or do, ask them what they need. When you notice that many of them need the same thing, and if it is something you can make or provide, you then have a business idea worth pursing.

Whenever you assign them a task, break down the task into small chunks. Make the chunks as small as you can (within reason, and to the extent that your knowledge allows), and tell your devs that if any chunks seem large, that they should further break those chunks down into bite size pieces. For instance, for the overall task of making a new webpage, _you_ might break it down as follows: 1) Set up a database 2) Make a form that takes user email, name, and phone number and adds them to database 3) Have our site send an email to everyone above the age of 50 each week When your devs take a look at it, _they_ might further break down the third step into: A) Set up an email service B) Connect it to the client database C) Figure out how to query the database for certain users D) Have it send emails to users over 50 You can keep using Asana, or you could use something like Trello which might make more sense for a small company, and might be easier to understand and track by yourself. In Trello you'd set up 4 columns titled, "To Do", "Doing", "Ready for Review", "Approved" (or combine the last two into "Done") You might want to tell them to only have tasks in the "Doing" column if they/re actually sitting at their desk working on it. For instance: not to leave a task in "Doing" overnight after work. That way you can actually see what they're working on and how long it takes, but that might be overly micro-manager-y At the end of each day / week when you review the tasks completed, look for ones that took a longer time than average (since, on average, all the tasks should be broken down into sub-tasks of approximately the same difficulty). Ask them about those tasks and why they took longer to do. It may be because they neglected to further break it down into chunks as you had asked (in which case you ask them to do that next time), or it may be that some unexpected snag came up, or it may be a hard task that can't be further broken down. In any case, listen to their explanation and you should be able to tell if it sounds reasonable, and if it sounds fishy, google the problem they say they encountered. You'll be able to get a better feel of their work ethic and honesty by how they answer the question, without worrying as much about what their actual words are. Make sure that when you ask for more details about why a task took longer, you don't do it in a probing way. Make sure they understand that you're doing it for your own learning and to help predict and properly plan future timelines.