Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Square Said to Acquire Team from Struggling Social App Yik Yak

bloomberg.com

Post reply on HN
Print view View original

101–110 of 144 posts

Re: Square Said to Acquire Team from Struggling Social App Yik Yak

#101

Post by btown »

ryanwaggoner wrote: post #67
posguy wrote: post #60

Earlier quoted context omitted.

Huh, well Square seems to be in the right place at the right time to make this acquisition of talent. I still don't get how Square intends to retain/gain customers at the price point their at, Mercury, Heartland, etc are eating their lunch.

Heartland is such an utter piece of garbage. I'd use almost anything before I'd touch it (or any typical shitty enterprise processor) again. Source: spent a year helping a client migrate from Stripe to Heartland to save a few basis points. Things like faxing docs to terrible APIs to constant lies from sales, who is a bunch of ignorant, rude good ol' boys, just like most of their competitors. Pure incompetence at virt…

As someone who's worked with faxed API docs before, that's usually just the tip of the iceberg of despair. Never again.

Re: Square Said to Acquire Team from Struggling Social App Yik Yak

#102

Post by dheera »

I loved the idea of Yik Yak, but every time I tried to start a semi-intelligent conversation I was downvoted to death. And this was smack in the middle of MIT. I guess the people I was hoping to interact with was exactly the opposite of the actual user base.

It would be potentially interesting if the upvote/downvote thresholds and ranking took into account your Facebook or other social graph, and then extrapolated to other people that might find your posts interesting.

Yik Yak could have been Waze. Yik Yak could have been a tool for students to ask questions during class when they didn't understand what the professor said. But it wasn't.

Re: Square Said to Acquire Team from Struggling Social App Yik Yak

#103

Post by pjungwir »

evan_ wrote: post #90
pjungwir wrote: post #70

Earlier quoted context omitted.

A problem I've mused on for a few years is related to this: when a phone submits a lonlat to an API server, how can you make the server more confident it can trust the location? I mean with curl I could POST any lonlat I want---I don't even need a phone! I don't think this is truly solvable, but how can you make spoofing the location harder? The scale I'm thinking about is "Are you really in the store you say you're…

you could maybe just trust them but flag/disable accounts that jump between locations extremely quickly. Might be tricky accounting for air travel but even then you could safely assume nobody's taking more than two flights a day and six a week or something like that

Yep, trusting every submission initially is fine, and we do use tricks like you suggest to flag suspicious accounts. For instance if you submit "11111" then "11112" then "11113" on up through "99999" (I've seen it happen!) then we might disqualify you from the raffle. :-) (We have better heuristics than that too.) But having the phone send some kind of extra proof would still be helpful. To point is just to make location spoofing "hard enough," not impossible. Also it is a small enough event that fraud isn't a true problem right now, so this is more just a fun mental exercise for me at this point. Still, good to be prepared!

Re: Square Said to Acquire Team from Struggling Social App Yik Yak

#104

Post by tajen »

pjungwir wrote: post #78
s73ver wrote: post #76

Earlier quoted context omitted.

I think the reason that API is private is because people do not want that level of tracking. And there are very few applications which absolutely, positively need this level of accuracy. And, I'm sorry, but marketing/advertising doesn't count.

In my case it is: the store gives you a secret code, and you enter it on your phone to earn discounts and raffle entries. We would like to prevent people taking the code home and sharing it with all their friends. So it's not about tracking. Still I get why the restriction needs to be there.

QR codes. Show them on a screen to invalidate them every time they're used.

Re: Square Said to Acquire Team from Struggling Social App Yik Yak

#105

Post by lazerwalker »

harryh wrote: post #84
lazerwalker wrote: post #69

Earlier quoted context omitted.

Yes, but presumably as part of the acquisition they're getting $X00,000 of stock/cash on a 4-year vest. That's far more than one would get for a standard new hire options package at a company of Square's size/maturity. I'd say that's accurate to describe as "golden handcuffs", since they (probably) can't just walk down the street to another company and get that offer matched.

I wouldn't call that "golden handcuffs." I would call it a better job offer.

If golden handcuffs are "stock that was previously granted but either has not yet vested or has vested but the employee can't keep if they walk away from the job", I'm curious at what point unvested stock becomes "golden handcuffs". The one-year cliff? One month in? After the first day, when waiting for your one-year cliff is one day closer than your one-year cliff would be if you quit and started a new job the very next day?

(Hope this isn't coming across as combative — if we're gonna have a discussion of semantics, I'm trying to nail down where you're coming from :) )

Re: Square Said to Acquire Team from Struggling Social App Yik Yak

#106

Post by OliverJones »

utmachina wrote: post #4

I think the key problem was the hype train and the lack of product-oriented/technical leadership. remembered them doing very well on campus last two years of college. They had on campus reps to hand out "schwag"; probably not very fun to scale. The obvious bullying was the problem. If they had found some way to solve that and snuck their way back into high schools... then again, kids can be so cruel.

I'm glad to see this one winding down. In my city it was used by high school students to hassle and mock each other. Yeah, I know, according to their terms of service and geofencing stuff high school students aren't supposed to use it. Tell them that.

Re: Square Said to Acquire Team from Struggling Social App Yik Yak

#107

Post by TacticalTable »

pcwalton wrote: post #66
ng12 wrote: post #64

Earlier quoted context omitted.

But it doesn't really matter does it? It's a social application, not a banking system. If your garbage gets users it's not garbage.

If a company gets users but fails to retain them, causing the product to fail and the investors to lose their funds, then it certainly isn't a success.

Yikyak didn't fail because of garbage code, it failed because of absolutely stupid decisions of direction. Adding usernames absolutely killed the app

Re: Square Said to Acquire Team from Struggling Social App Yik Yak

#108

Post by peruvian »

dheera wrote: post #102

I loved the idea of Yik Yak, but every time I tried to start a semi-intelligent conversation I was downvoted to death. And this was smack in the middle of MIT. I guess the people I was hoping to interact with was exactly the opposite of the actual user base. It would be potentially interesting if the upvote/downvote thresholds and ranking took into account your Facebook or other social graph, and then extrapolated to…

People go on social apps to waste time and have fun. I get your frustration but it's not surprising no one cares about discourse in Yik Yak.

Re: Square Said to Acquire Team from Struggling Social App Yik Yak

#109

Post by harryh »

lazerwalker wrote: post #105
harryh wrote: post #84

Earlier quoted context omitted.

I wouldn't call that "golden handcuffs." I would call it a better job offer.

If golden handcuffs are "stock that was previously granted but either has not yet vested or has vested but the employee can't keep if they walk away from the job", I'm curious at what point unvested stock becomes "golden handcuffs". The one-year cliff? One month in? After the first day, when waiting for your one-year cliff is one day closer than your one-year cliff would be if you quit and started a new job the very…

As with many things in life I would say that it's shades of grey. Perhaps they are handcuffs from day one but they haven't been latched closed yet. The longer you stay the tighter they get.

The "tightness" of the handcuffs is, roughly speaking, the % of your motivation to work there based on a previously accrued reward vs reward that is earned day by day.

With powerful enough golden handcuffs the company could reduce your salary to zero and you would still stay (though perhaps be pissed about it).

(not coming off as combative :) )

Re: Square Said to Acquire Team from Struggling Social App Yik Yak

#110

Post by posguy »

ryanwaggoner wrote: post #67
posguy wrote: post #60

Earlier quoted context omitted.

Huh, well Square seems to be in the right place at the right time to make this acquisition of talent. I still don't get how Square intends to retain/gain customers at the price point their at, Mercury, Heartland, etc are eating their lunch.

Heartland is such an utter piece of garbage. I'd use almost anything before I'd touch it (or any typical shitty enterprise processor) again. Source: spent a year helping a client migrate from Stripe to Heartland to save a few basis points. Things like faxing docs to terrible APIs to constant lies from sales, who is a bunch of ignorant, rude good ol' boys, just like most of their competitors. Pure incompetence at virt…

Heartland is only strong in the terminal arena, their entire plan for EMV POS systems boils down to Datacap (fucking nightmare you should avoid) and Pax (which is meh). Mercury/Vantiv aren't bad, and are much more developer friendly if you need complex direct integrations, alternatively FD ISOs vary.

The least painful way to integrate is semi-integrated with Pax or Dejavoo, and that way your customer can choose from the majority of processors with minimal work on your end. Typically I see grocers paying under 1% after interchange, network fees, processor fees, etc, hence why there is motivation to deal with the legacy good ol' boys.

Helpful library: https://github.com/AccelerateNetworks/PHPax

Post reply on HN