AlexBlom's comments

Feel free to shoot me an email (on profile) and I can share details / connect you with some involved.

I'm an Australian who has been in Canada since 2009. The current iteration of the startup visa has some odd restrictions on Canadian capital imo.

You are generally better doing WHP to FSW

Disclaimer: ianal

I went through a similar thing in my first few trips to the Bay area, and ultimately decided to not move there for the same reasons.

I've found subsequent trips to be much easier. Unfortunately, the most vocal and easiest to meet within the community were the most abrasive / kool aid driven. Keep digging.

Link is down. Cached page at: http://webcache.googleusercontent.com/search?q=cache:ybdWn7-...

tl;dr: most feedback on twitter ads assume it is intent driven (i.e. google adwords), when in most cases it is not.

IMO, it's the root of many social companies struggle to monetize with ads. We've been spoiled the last while because we knew what people were looking for, and could promote directly against that. In some ways, social ads are a step backwards from this.

The 4 and 7 has been an ongoing debate among marketing academics, it seems. I recall the "right" answer alternating course by course through school, pending the professors interest.

If I recall, the 4 P's are the standard marketing mix, with the 7 P's being called the extended marketing mix. FWIW, the 4 was definitely more central at my school.

On top of this, once the coding starts, too many languages focus on command / effect (note: not cause / effect). This is arguably fine for basic looping and data structures.

The problem is I see this knowledge break when 1) it is applied to a more difficult problem that 2) is outside of the scope of the provided loop.

Spending time understanding the conceptual elements (when, where, why) before the how doesn't give immediate results, but it saves many headaches down the road and makes future tools / languages much easier to learn.

Thanks for organizing, Dave.

I think you make some valid points, and as somebody who self-taught, I get the pain. That being said, I also agree with the common sentiment here "help yourself a little first".

If you consider yourself a technology company, you need an understanding of your technology and what goes into making it. You may not be a master at each part, but you need _something_. It doesn't mean you are not marketing, but like marketing a technology implementation has several nuances that can't be overlooked. Tension always arises when these aren't well understood. Times this problem by 10 if you want "magic" / algorithms which little concept of how they will work (note: you don't need computing studies to figure this out, generally).

Note that I said 'consider yourself a technology company'. There are many companies based on technology that are not, themselves, technology companies (you can argue either way whether this is the right model, but it works). From my experience, these are the companies hunting less for technical co-founders (and who have less excuse for no traction pre product).

I found the SEE (free Stanford) courses to be best: http://see.stanford.edu/see/courses.aspx

I'm unsure this is true anymore. If you know how to play B2B (the same lies true for B2C), it's entirely plausible to get the first 1-5 deals pre-build (I did).

If you consider that equal to the first traction burst in B2C, then I'd argue that the ambiguity for B2C is just as large, if not larger, in the early days.

It is my no means an overall risk / reward inflection point (and if you are referring to 'this company is guaranteed to exit' I agree), but as an early 'this might have something' B2B can validate fast.

I'm unsure the perception of B2B among VC's is as bad as commonly thought.

My last startup was pure B2B, and during our valley runs I found most potential partners / vc's / workers were very excited (in part because of the opportunity, in part because of perceived market movements, and in part because B2B can be fun) at the prospect of growing in B2B.

B2B companies may not spawn a media darling, but it doesn't make the business itself unsexy.

Thanks Yoseph

Hi, just to address, there are two options I'm working on at this point:

1) App-less (just changed your contact settings); and 2) I am tinkering with some local app stuff for the folks who want it.

The focus right now is 1), but the point of getting out so early is to validate these assumptions.

Thanks for the feedback / questions.

Good call. Would love to see it integrated.

Perhaps I mis-spoke above. An issue can be associated with multiple tickets, just as a ticket can be associated with multiple issues. The latter is not beefed as much in the code, as I found the use case to be less once live.

Appreciate the feedback. Will see how often this is reported. The fading is also handled in the main JS file, so you can disable it there.

I'll admit there is not much logic here. Was not needed for my use case. Feel free to contribute it, though!

Sure. You create a support e-mail. Customers send to this e-mail, and tickets are auto-created.

Hi. I may flesh it out, but I've also opened up the software. If you have extension ideas, please feel free to fork / contribute. You can flip me an e-mail (my first name @ my HN username . com) if you want to go further, or flip a note on Twitter.

An issue has a one to many relationship with tickets. I built it, as I found I'd get many tickets about the same thing from different users. I wanted to be able to focus on solving the macro issue and not manage many issues. Terry Smith is one of the thinkers behind it.

Thanks. It's easy to keep things simple when you are building for my use case, which was rather basic.

That being said, I see the value of tagging. Perhaps a future addition.