Having a name like that is very bad, because a) you will be forever trailing on the 6473th page of Google Search results and b) it will be difficult to grow a meaningful brand around a name, which already has such a strong emotional charge.
If I were you, I would definitely rethink the name.
One simple way to find new problems is to follow the advice once given by Deep Throat: "Follow the money!"
What I mean is look into your own spending patterns (or those of your friends/ parents/ neighbours/ colleagues) and ask yourself why does something cost as much as it does? Can it be made more cheaper? Or if it is already cheap, can the difference consumer saves be used for some meaningful, complementary services/items?
Thinking this way can reveal many interesting and unexpected answers and the best thing is that this quest takes you out of your room, since you have to follow the money trail and understand how different businesses work. Doing that as an outsider is likely to spark many interesting thoughts.
hardware security aside, if credit card readers employ proper encryption, that in itself would probably be an effective deterrent against such leaks, but only IF such encryption is implemented.
Isn't such idea counter-intuitive? The most successful websites, the ones who rake millions from targeted ads & deals with third parties, will have least reasons to open their system up. So you will ultimately end up with several hundred niche, privacy-friendly websites never visited by the general surfing public.
http://swisssign.com/en might not be the cheapest option, but definitely has some extra cachet. They are really conservative and most of the approval process is manual, but support staff is friendly.
I have been using AirBnB very actively during the last couple of years, mostly in the Northern Europe and South East Asia, and my experience was nothing but wonderful.
However, as some people in this thread have already pointed out, you need to stick to certain rules of a thumb:
a) always check response rate and average response time to weed out any sloppy profiles;
b) BEFORE you place a reservation, write a host introducing yourself and telling a bit about the purpose of your visit;
c) after the host OKs you (or makes a special offer through the system), go ahead an make the booking.
Of course, the optimal time to book is 1-2 weeks before you arrive, do it earlier and hosts' plans might change, do it later and they might simply miss your message.
Eric, I deal with my programming handicap in several ways.
The easiest thing to do is to ask new candidates to walk me through how they would model a specific business problem we've worked on before. Since I like to listen in on developer talk, I am usually aware of technical challenges that different approaches entail and listen to whether the candidate spots them or offers a way to deal with them when prompted.
I am also very curious to see how the candidate approaches the problem itself. In my experience, average developers feel they are done with the task when they explain how the program will work, while great developers are done when they explain how the program will work even when something it depends on doesn't work (e.g. how to you handle errors and outliers).
Obviously, I ask my developer colleagues to evaluate candidate's sample code.
Talking about testing is pretty fun too, just asking candidates what were the most nerve-wrecking debugging stories they had, reveals how much experience they have in this area. Then I would drill the candidate about testing routines and heuristics he employs; rule of the thumb is that the more specific candidate is, the more he knows about testing. Listening to heuristics also gives you an impression of how creative/crazy people are.
Finally, walking through a specific project the candidate has worked on in the (recent) past helps to understand what workflows & routines he follows in his daily routines. Here though you have to remember to ask clarifying questions along the way.
What I am missing on your website, is a clear vision of use case for this app. You know, stuff like - "hey you, overworked real estate agent, I have something to make your life so much easier. A system that sorts your incoming mail in a split of a second, bla bla bla".
Plus, the website lists many features, but it skimps on user benefits/concerns. For example, you have a "feature" called beauty (which is actually not that pretty - perhaps you can change the picture to the one featuring a family or smth) - why not say instead, our beautiful UI makes it so easy to navigate and sort your emails, you will forget you are working!
And security, why don't you talk about security? To me it is one of the major concerns if I am giving ANYBODY access to my inbox.
OK, I am a business type guy and I have to say... I completely agree with this article. In my experience, developers become good at what they do not through learning languages, but rather through mastering three basic skills:
a) modeling business specs into discrete technical steps (loops, workflows, calls, etc.);
b) developing intuition for tackling bugs, e.g. knowing where to look for causes and how to fix them quickly, even if it often sounds like a completely illogical thing to do;
c) developing and sticking to well-defined procedures, e.g. documenting code, making timely backups, going through security checklists and so on.
So whenever I need to hire a new developer for my projects, I try to assess how well he fits those three criteria.
Having spent some time interviewing typical users I can say that this would work only if we put the distributed service bits under the hood, while leaving service with all the trappings of a normal website.
Regular users often times find it difficult to use regular apps, not to mention things like TOR access. And since we want as many users as possible being able to use it, we cannot just waive them off saying "go learn Internet" :)
Regarding the IP addresses, we use bcrypt algorithm, obviously with salt, to obfuscate IPs and since we're hosted in Germany, gettings hands on these entries the legal way is a long process.
To address the problem of spam, we have already implemented a combination of selective captchas and Akismet filter running in the background.
We also use name entity extraction algorithm to obfuscate any names we identify in the submitted reports. It takes a couple of minutes and is not 100% proof, but at least reduces the risk of names being called.
The major problem that we are thinking about, however, is how do we structure the "vetting", given that reports are sometimes hard to verify without first hand knowledge of situation.
So far we tried to analyze how one goes about these things in real life and recreate natural constraints in the virtual space. The fact that we require every report to be geo-tagged works to our advantage in this situation.
As a practical example, ordinary people usually do not have access to president's palace, so if someone claims to be paying a petty bribe there, it is obviously a fake and we would automatically suspend such report.
I was so excited to discover that something like this exist - a community that gets on with its business without any stupid organization or agency putting sticks in its wheels. I just wish this spirit of freedom would come over to countries of the former USSR where it is badly needed.
If I were you, I would definitely rethink the name.