

Ask HN: Review my Startup - dejan
http://www.syncfu.com#dosyncfu

======
gridspy
Okay, so from my vantage as an electrical manufacturer the point of syncfu is
to help me achieve economies of scale. The more people that purchase, the more
I can lower my price.

You don't currently obligate buyers to make an actual purchase, so the price
that the other buyers pay might be too heavily discounted. For example, 100
people reserve, but only 20 actually buy - in this case I might not make a
profit since the per unit costs for 20 are much higher than for 100.

I'd rather see a similar grouping mechanism that requires full commitment from
both buyers and sellers, like ebay does. You'd probably have to do this with
accounts, points and validation.

As for the actual purchase you could do this:

The seller creates a graph of price vs size of the production run, as now.
They specify how often they would like to do production runs (sales).

Each buyer specifies the maximum amount they would be willing to pay, by
clicking on the purchase graph. They specify how long they are willing to wait
until it reaches that price. They enter all their credit card and billing
details into the system, and have made a promise to purchase at that price or
below.

When the sale ends, the system attempts to solve the graph for price. Everyone
who "bid" above this price pays the solved price, everyone below is moved to
the next run, unless their stated "latest date" would be passed by waiting
that long.

You then bill everyone who said that they would pay. You make the lump sum
available to the retailer who then satisfies the orders. This way there is no
risk to a buyer that they will pay more than they want, and no risk to a
seller that you will set the wrong price.

When I say solve for price, what I mean is that

\- 1 person chooses the 1 user price (A)

\- 2 people chose the 5 user price (B)

you solve, 1 user (A) gets the 1 user price, they get billed, B moves into
next round (unless their time limit has expired)

now more people come along

\- 5 users choose the 10 user price (C)

\- 6 users chose the 12 user price (D)

\+ 2 people chose the 5 user price (B)

So now you can manufacture at the 13 user price because that will satisfy
everyone.

~~~
dejan
I gave it a bit of a thought. Maybe this can be done post-reservations. The
solver would consider how popular the item was, the prices at which people
accepted to participate and the lowest achieved price. According to all of
this, the solver would calculate the suggested item price.

That's cool, I might do that, just for fun.

I wouldn't limit the usage to only manufacturing and operations management. I
am trying to keep it as a universal tool.

Thanks again for valuable thoughts.

~~~
gridspy
What I want is for buyers to make a real committment. The major difference
between my system and yours is that buyers can say "I don't want to buy it for
$1000, but if it reaches $600, I am in. Here are my credit card details if it
does"

[Edit] Is this what all your competitors do too? I didn't mean to remove your
point of difference, but perhaps this way works better.

~~~
dejan
All competitors do as you say - take the credit card info and store it. Only
if price reaches the threshold, then they are charged. I believe a different
approach should be tested against, as the resistance to making a commitment is
lower.

The assumption is that if the price gets discounted at all, that becomes the
best offer online.

------
akamaka
This is very cool idea, but the whole thing gives me the impression that it
was developed without customer feedback.

Is anyone using it? Group buying is something that can be done without any
special tools. If people are already doing it, then there are probably group
buying forums out there that could use your support in making them more
efficient.

If people aren't already doing group buying, then the real work is in
convincing people to do it! If you don't already have connections to merchants
who are doing this, then you need to find them, or start doing it yourself.

I hope this works out for you, because it seems like an awesome idea. The app
looks good, but comes across as being a technical tool, rather than something
that generates sales.

~~~
dejan
If people are already doing it, that is no reason not to try something
different =) Currently, major group buying happens on GroupOn and Buywithme,
as well on their European copycats. However, they are pretty much limited to
services, as the prices are easiest to rip-off a percentage cut. BuyWithMe
e.g. takes 20-50% of the price for them. That doesn't seem right to me?

Sure, the biggest challenge is in convincing merchants to actually use it.
However, I think I will start with own goods first (3 retailing companies
here).

I will see to change that to be a more sales feature instead of technical.

Thanks for the great advices!

~~~
akamaka
Sounds fantastic, it's great that you have some early customers. I'm sure
they'll give you some good feedback.

I hope you post again in a year or two to report where you business is at!

------
jeffmould
I tried to do the demo, but was asked for an email address. While I trust that
you won't spam me, I don't understand why I have to provide an email address
for demo purposes. If you are going to provide a demo, I would recommend
either doing a video, some screenshots, or have a demo that doesn't require
any interaction from the end user.

I think the problem with your homepage text that others have noted is not so
much in stating the concept of the problem the app solves, but really in
stating what the benefits are to both the buyer and seller. Most suppliers are
going to understand economies of scale, but many buyers are concerned more
with end price. You have to convey to the buyer WHY economies of scale is
better for them. With that done, you also need to convince suppliers that your
app will increase sales for them.

~~~
dejan
The email is absolutely needed as this is the contact point between the seller
and the buyer. I didn't go into modifying the demo component but used actual.
As I see, most people use random mail addresses to test it out, so can you. It
is just an address to which confirmation is delivered with the discount codes.

That is good, I think you're right and will consider doing that. Thanks for
the comment!

~~~
jeffmould
Got ya. You may try to come up with a way to do the demo without the email
address for users. If I had just stumbled upon the site, and thought it may be
something I would use but was not quite sure, the first thing I would do is
try the demo. If I immediately saw it ask for my email address I would feel
like you are scavenging addresses and move on to another site. If you
absolutely require an email consider clearly stating that up front and the
reason why an email address is needed for the demo to function.

~~~
dejan
Good advice, will change that. Thanks again for the advice!

------
petercooper
Anyone else notice how the Hacker News domain extractor messed up on this
post? It shows up as _(syncfu.com#dosyncfu)_ on the front page and direct on
the item.

~~~
dejan
#dosyncfu is the autotrigger hash, when added it will start the group buying
box immediately upon DOM load.

~~~
gridspy
It should have been stripped from the title, which usually shows (google.com)
say

------
forcer
I don't know if its just because its late here and I am bit tired but I didn't
get the concept yet.

I understand what group buy is but not sure what problem your website solves?

~~~
dejan
it's late here too :) well, the webApp solves a problem of aggregating price-
aware customers that would accept buying the item later but at a lower price.

It isn't for everything, but selected products/services. It is similar in
concept as GroupOn & BuyWithMe, except it is more a bare-bone feature that is
easy to setup and customize.

It may also be used for promotions, let's say in digital goods, since the
target price can be set down to zero.

~~~
gridspy
It is a system that groups buyers together so that the seller can use
economies of scale.

The more buyers, the lower the price.

------
fnid2
To be frank, I can't imagine signing up to use this service. It is too easy to
build into almost any shopping cart system.

Why go through the process of integrating with a 3rd party and all the
logistical and viability nightmares that come with such a decision when it's a
trivial problem to solve in the real world?

~~~
dejan
Good point, but why isn't it already if so? E.g, Shopify? Shopify actually
lacks even per-item discount codes.

Group buying isn't a proven feature for websites, nor is it cross-site
interaction universal. Visitors have to know what it is and trust it in a form
of knowing what to expect and what not. That is the space SyncFu should
occupy.

Basically, SyncFu is just a free* version of Groupon, Buywithme etc. The main
reason for developing it is bringing this feature to any website without the
20-50% fees that these sites snatch. The only cost is the reservation fee, and
it is charged to the customer, which is a dissolving cost.

You are certainly right about big vendors, if you throw a bunch of resources,
it is too easy - but most little/medium web-shops deploy custom, features-less
shopping carts - e.g. all the customers of Groupon and BuyWithMe.

Plus, I have no clue how would any company justify any costs of developing
such a concept / experimental "feature". Well, for sure it isn't happening
since there is very little innovation in online payments. Therefore this
simple thing is isolated for any company to deploy on chosen products/services
in a very simple manner.

Besides, this little component offers more than just group purchasing.
Promotions are easily made, e.g:

\- free signup for the first 100 reservations (price goes down to 0)

\- pre-orderings of future books, directly by the author

This is of course my personal opinion, but SyncFu was built to verify the
hypothesis :)

Thanks for the comment, and regarding the too easy, well, it took a long time
to ditch features and shape minimal single feature product - praising Unix
philosophy. The js code is of course publicly available:

[http://github.com/dejanstrbac/SyncFu-
Widget/blob/master/widg...](http://github.com/dejanstrbac/SyncFu-
Widget/blob/master/widget.js)

~~~
fnid2
I see the case where someone using shopify could want to do something like
this. If enough shopify users ask for it, they could add it, but it's a pretty
esoteric feature needed by relatively few shops, because traditionally,
individuals shop individually, rather than with a group.

Group buying isn't an unheard of concept. Many buying groups pool their
resources to receive discounts on large orders from manufacturers. This could
be a feature for such manufacturers to add to their ordering systems.

Still, the hurdle if integration is going to be a big one for you. For
example, how do you let syncfu know how many products you still have to sell?
How does the store owner coordinate sales such that they don't sell more than
have been requested to buy from syncfu? Why would a seller want to sell their
goods at a reduced price to the same individuals who are likely to buy it
individually anyway? Also, you still have the logistics problem of shipping
all those orders from the "group" to the individuals who grouped to get the
discount so as a store, your margins decline due to increased overhead for
lower sales. Discounts for large orders are usually only possible because
there is reduced overhead in shipping and account management.

I think you may have a hard time selling this feature to stores. However, if
you create a competitor to shopify that has this as a feature, then all the
shopify customers who want to sell this way could be potential customers for
you.

~~~
dejan
Great comment, highly appreciated!

"because traditionally, individuals shop individually, rather than with a
group"

Exactly, but if there was a possibility in general to buy in bulk with random
people at the same moment, it wouldn't be traditional? I agree with your view,
but one just has to disagree with the traditional in order to see what is
possible today with all this social bits flying around.

As I've mentioned group buying exists in GroupOn for example, but it is
insanely how much the sellers lose. With such a component they could provide
the same services. Yet, there is no "target" quantity where the discount
becomes available, as it happens immediately with each reservation. The
quantities are set by the seller, and for sure are not infinite. The seller
really has all the power over the group purchasing.

Once the item is closed with either its deadline or maximum quantity, the
seller can provide with payments instructions and a deadline for actual
payment. I doubt all will complete the payment, but most of them will. The
seller of course counts on this when setting the price, so the risk is the
least.

I've been digging a long time, but I haven't seen the concept with
"reservations" as SyncFu. Do you know any? All of them I know would take your
CC info first, and charge once target is met. (That is one way how SyncFu
reduces friction in comparison)

The whole point with SyncFu is about laying down some grease in online
payments. There is a lot of space for innovation in online payments as well
usage of micropayments as sales catalysts, not actual charges.

------
coryl
It looks interesting, but I'm REALLY confused as to what I'm looking at with
the graph, countdown timer, lowest price, etc.

What is all that junk? Why does the graph show a price in $000 but the price
per unit is $2.00

~~~
dejan
In the demo given, price per unit is $2000. The $2 are reservation fee paid
through a cell phone / cc as a micropayment.

'Buying' doesn't actually happen, only reservations are made to 'participate'
in the group purchase. After the deadline expires (the countdown timer), the
item closes and all that reserved get a notification that it closed. Now the
seller contacts all those (the admin side supports it), and tells them that
they have 72h to purchase the item in the existing shopping cart with the
discount code provided. That is of course if there is a shopping cart,
otherwise an invoice or payment request can be sent, but that is however
completely a matter of the seller.

There is no mediation, only a reservation making tool that is easy to setup,
use and configure. Thanks for the comment, I see how that can be a bit
confusing.

------
zackattack
you have way too much text on your site and not nearly enough pictures

~~~
dejan
lol. Thanks, it's nice to have a laugh this late :) (Sorry, I'm not being
sarcastic, just it's a common misunderstanding)

Well, it says it's a webapp, not a rock band's fan page. People are actually
ment to login, do their stuff and leave. I wish I could dump that login too,
but it is the collateral damage of shifting apps to the web.

All the text is there to help the technical people searching for answers, but
the actions are clearly shown. I doubt one can't find her way around.

I wonder when will "webapps" truly be understood as different than websites. I
am comparing webapps to desktop apps, not to brochures. Am I alone here?

~~~
dmor
I think you're missing the point of this feedback - the UI is confusing so it
is making it hard to grasp the value of the service for a first time viewer.
you might be suffering from being too familiar with your product, and only
dogfooding from the "logged in an clued in" perspective

this isn't about webapps vs. websites vs. desktop apps, it's about the
importance of communicating the problem you're solving clearly and having a
big f*ing button that makes the call to action completely clear

~~~
dejan
Thanks for the comment. I hear you, but what is confusing about this UI? If 4
sentences are "too much text", then hell, how people understand others in the
same field that induce more complex processes: <http://www.groupon.com>

Big f*ing button is there, in size and color.

IMHO, this web app doesn't need to be explained a whole lot. Those that hear
"Group Buying" and understand what it is from those two words, they'll know
how & what & where. After all, this web address is meant for sellers, not
buyers.

~~~
coryl
Its confusing for anyone, seller or buyer. And if it confuses buyers, sellers
wont use it.

I still don't really get how to use it after reading the site and your
explanations. Why is there a P vs Q graph? What does paying a fee upfront
entitle me to? What is a reservation and what does it give me?

I'm a first time consumer, and you've just thrown a complicated buying method
at me, with a graph, current price/lowest price, for which I have no clue how
to follow. I think it needs to be bared down to the minimal information
necessary.

~~~
dejan
[updated]

Isn't it obvious that price drops with quantity?

A reservation is a pledge that the customer will purchase the item later. The
reservation costs $1-3 depending on where the buyer is, and is paid through a
cell phone. By having it be paid, it is simply more reliable. No one wastes
money, and these are dissolving costs in the total discount.

I believe this is the minimal information. The unit price, the current and the
maximum quantity price. What do you think is excess?

Thanks for the comment.

~~~
gridspy
Both your website and your widget must be able to answer these questions
within 30 seconds for the most ignorant, distracted user with 3 children
trying to climb into their lap.

This user might have never bought online before, and if they have - they have
no idea what the backend order process looks like.

Answering these questions here is only a beginning. If _anyone here_ cannot
get your site before getting frustrated, you haven't explained your system
well enough yet.

Remember, the majority of users (by a huge percentage) are going to see your
widget first. Your widget is going to advertise your solution to potential
sellers who see it on someone else's website.

If _any customer_ gets frustrated at your widget, it is going to get pulled
from sites.

~~~
dejan
good points; I am thinking on how to simplify and better present this concept.
Thanks for the comment!

