Ask HN: What are some hacks of real founders who did things that don't scale? - <AUTHOR> Inspired by Paul Graham's phrase, I'm curating an open list of hacks/stories of real founders who did "things that don't scale" to power through their initial startup days.<p>What are some of the hacks you have heard or have personally experimented? Thank you in advance! <comment><USER3> We prototyped [https://www.moonlightwork.com](https://www.moonlightwork.com) without code.

Here was our basic workflow:

1\. Marketing site set up using Squarespace

2\. Developers apply using Typeform. We add them to a Google Sheet with Zapier.

3\. New jobs submitted through Typeform, which triggers an email to us

4\. We manually set up a new Google Form to collect proposals. We send the results google sheet to the client.

5\. We manually search for developers that match the skills of the project and email them all manually to ask them to submit a proposal using the Google Form.

6\. Project owner selects a developers. We docusign a contract to both parties.

7\. We send a google sheet to the developer to log hours

8\. Every week we go through the developer timesheet and manually issue an invoice using PaidLabs.com (with Stripe at backend)

9\. When the payment gets deposited, we pay the developer (wire transfer outside USA, Payable.com inside the USA)

We slowly automated each step with a web app, which was published part-by-part as we finished automating a particular step. We did about $100K GMV with this no-code stack before we completed the end-to-end web application.

Today, Moonlight is profitable and bootstrapped. We still manually prototype things. For example, we came up with the idea of a subscription product on Tuesday last week. We had a client agree to it, so we issued an invoice through Stripe Invoices on Friday, collected the money, and are now starting to build subscriptions into the app.

<comment><USER4> Pretty off-topic but I'm going to throw it out there anyways. I play a game call Factorio, a quick run down it is a procedurally generated, top-down (2.5D ish) game where you can move around your character to mine materials, build things, etc. A huge part of the game is automating the creation of various items. For example iron gears are used in a number of lower-level items and while when you go to craft an item it will automatically build all the intermediate items (providing you have the materials) this becomes tedious very quickly (by design).

I find that playing the game requires a healthy balance between #AutomateAllTheThings and "Don't waste time building a huge factory for something you need very little of OR you don't know how much of it you will need". This same experience/way-of-thinking applies heavily to development/programming in the form of "Premature Optimization". In my first Factorio game I spent WAY too much time building massive factories to pump up every single item I needed. This lead to a boring grind and wasn't efficient at all. I was overwhelmed with making sure I always had a chest full of X item ready for me that I wasted a bunch of time (which, to be fair, in Factorio I didn't exactly waste the time as I had fun).

For me this resonates heavily with as it lead to a sort of "analysis paralysis" that I immediately recognized from my attempts at a side business. The next thing I attempt I am going to make a conscious effort to focus on a MVP above all else and ignore scale completely. My last attempts at building a side business have spiraled out of control quickly as I attempt to right all the wrongs, foresee all the potential issues, side steps all the mistakes I saw happen at work, etc.

In some ways I really miss my days in high school when I would open up a blank php file and start coding instead of wasting HOURS looking into various tech stacks/frameworks/libraries/etc in an attempt to "future proof" my setup. I realize now it's a fool's errand. That's not to say you should never think about how you would scale but at the same time don't let the idea of future success keep you from creating the exact things you are trying to future proof.

<comment><USER5>
        In some ways I really miss my days in high school when I would open up a blank php file and start coding instead of wasting HOURS

Is there anything stopping you? I never went into 'web' so that's still my goto solution. A few months ago I had an idea and I had something up and running in PHP within a few days.

<comment><USER4> No there isn't, I get into a head space that goes a little something like this:

* I think I'll create a little website for XYZ

* Better setup a GitHub repo for this

* Hmm, I really like using Angular/Typescript since I use that so I'll use that

* Better make sure Webpack is all setup and working

* Should I do my development in Docker since that's how I'll deploy it?

* Maybe I'll try this new NodeJS backend framework that looks interesting

* I need to make sure all my config lives outside of my app so that I don't hardcode values

* Oh crap, I want to share code between server and client but they both have their own Webpack configs and merging the two without screwing something up doesn't sound fun

* What, was was I going to create a website for again?

My most enjoyable non-work programming over the last year or so has been in my ~/git/temp-scripts folder where I can just create a new folder for something, run npm init, and be coding in less than a minute. This is mainly used for, as the name suggests, temporarily scripts or better yet, scripts that I'm not sure if they will have legs or if I'll just use it once. It's pretty much my little playground where I don't have to worry about scaling, reusability, etc.

<comment><USER6> Thanks for sharing your thought process, I found it interesting.

I get the sense that there's a gem in your scripting, and one of those might become useful and need more work, and then you'd have a reason to scale it.

There's [a recent interview with PG]([https://www.startupschool.org/videos/36](https://www.startupschool.org/videos/36)) where he talks about the joys of hacking, you might find it interesting.

<comment><USER4> Thank you! I'll check that out

</comment></comment></comment></comment></comment></comment><comment><USER7> When I was starting Suiteness (YC S16) I found out after talking to hotels that it costs tens of thousands of dollars to connect to their backends. So I wrote a basic app in a weekend for "booking suites" but what actually happened was...

1\. The user was filling out a form that was sent to me.

2\. I would email hotels asking if they had suites available on the users dates.

3\. I would enter their responses manually and the app would send a push notification to the user to see what I had entered.

4\. Payment and everything else was done over email.

It looked legit, and during its peak I was doing it up to a hundred times a day. We are directly connected to hotels now so this doesn't happen anymore thankfully.

<comment><USER8> I do contract work for a company in the travel industry and the founder of that company told me that they did basically the same thing when they started. He set up a website with hotels, etc. When customers called in, he would make the sale and _afterwards_ call up the hotels and try to book rooms etc. If needed, he would call back the customer and change the booking. Basically optimistic strategy with rollback :-). Interestingly, he told me that at first he had no agreements with the hotels and had only a vague idea of rates, etc. He would just make it up as he went along, meaning that sometimes they would get a huge margin and sometimes he would take a loss. After he booked several rooms with a hotel he would then call them up to set up a contract. He apparently also started up the whole thing carrying just enough debt to cover the billing gap. Took no outside investment. Totally ballsy way to start up a travel company, but it worked pretty well (Doing hundreds of millions in sales per year these days).

</comment></comment><comment><USER9> Encouraged users to send emails for support, and answer every single one, no matter how unpleasant (one exception). At first I got angry with "stupid" questions, but then I realized that angry is not going to stop new emails, so I rolled up my sleeves and started fixing UX problems as they came in. At the peak I had 40k active users, and the deluge of communication was like drinking from the firehose, but with continuous improvements the stream of support emails withered and then dried up completely. Eventually I got to a point where had only one or two per day, and they were more of a leisurely conversation than support requests.

<comment><USER10> Similar story here.

In terms of scalability, my takeaway has been this: in every company I've worked since, I've fought tooth and nail to make sure that the engineers are the ones handling the level 2 support and up.

Support is invariably happy because they only need to triage and process the really dumb questions. They offload the time consuming stuff and end up cutting their budget needs.

The engineers, on the other hand, invariably get extremely annoyed by the deluge of UX and/or recurring questions that swamp them. Oftentimes it's to the point where they spend so much time on them that they've no time to build new features anymore. And then, magically, they aggressively prioritize _and fix_ the more time consuming/support intensive issues to get them off of their hands.

Everyone is better off. Clients are happier; support is happier; marketing and sales are happier; finance is happier; and so are the engineers. The latter are less happy initially, but they rapidly get a better feel of (and end up appreciating) how their work impacts end-users.

<comment><USER11> This is great in some cases, but can also be really dangerous.

It's structuring the entire company around the selection bias of people who complain about your product, and not focusing on the hypothetical majority of users who never have issues with it, who may outnumber the group of complainers by 10x or 100x.

At that point the right thing to do is to pay way less attention to things that represent a support load, and iterate on already working features used by the 10x or 100x.

Sometimes it's the best thing to do, sometimes it's a horrible idea. It's not some no-brainer that software development in general should be structured like this.

<comment><USER10> Agreed in principle, but not in practice.

I've yet to join a company that had a marketing department on top of things enough to pinpoint what the hypothetical majority of users who never had issues actually want.

(I'm sure there are some out there; but I've yet to find one that will hire me. And for clarity, I usually join companies as part of the marketing team. After a few weeks of getting a feel of what end-users actually want, fixing the existing product niggles turns out for one reason or another - maybe it's just the type of companies I work with - to be the or one of the lowest hanging fruits from an ROI standpoint.)

<comment><USER11> You wouldn't give this to marketing, but make the decisions data-driven where you try as hard as you can to get a sample of what your average user is doing, and whether they're being hindered by bugs or some features.

This is easiest with hosted SAAS. It's why companies like Google care so little about user feedback. They can e.g. do an A/B test on their UI and find from their data that moving some button makes it easier to find (fewer false clicks), no matter what the minority of users who contact them and swear up & down that the new UI sucks say.

With self-hosted or desktop software this is harder. You might have some phone-home feature that sends aggregate statistics, or simply pro-actively contact a random segment of your userbase. "Hey, you use our product. Does it mostly work for you, or are you being hindered by issues? If so which?".

That's still a huge selection bias (people who care enough to respond to a survey), but still beats the even bigger bias of people filing bug reports.

And I'm saying this as exactly the sort of person who'd be annoyed enough to file a very detailed bug report against some piece of software I use.

<comment><USER9> Moving the button around the screen is the kind of thing that will drive you to a local optimum and dump you there, with no sense of purpose or direction to a better place.

Direct user feedback shakes you out of that dead-end, and towards a newer, much better dead-end on the path to success. Maybe the button is solving the wrong problem, but users latch onto it as the first thing that comes to mind. You can't find that out unless you interrogate your customers, and most engineers wouldn't do it unless their back is against the wall. Happened to me last week - spent an hour on the phone+hangouts with a customer, and it turned out they needed something other than what they asked (and we didn't have). Happens all the time.

[BIG-CO] employees are just talking to each other, and then A/B testing their way to success along the nearest promotion-worthy metric. The courage, or the necessity, to overcome the aversion of the users is a competitive advantage for a small company.

EDIT: want to add that I am enjoying our conversation here, thanks for joining.

</comment></comment></comment></comment></comment></comment><comment><USER12> One "hack" is too simply not listen to people who say it won't scale.

I wanted to grow a service business, and everyone will tell you that service businesses don't scale for any number of reason. I grew my consulting business by identifying stuff my customers really needed, was teachable, and had great margins. Once my customers saw the value, I switched from hand to mouth survival waiting for invoices to get paid to working for upfront payments. With cash in hand, I could hire people to so the work as fast as I got the business. Maybe my business wasn't infinitely scalable, but it grew way bigger in a short period of time than anyone expected :)

<comment><USER13> As a service business owner, it's great to hear this perspective here. Service businesses might not be "the next google" but you can absolutely make 7 figures a year pretty handily if you know what you're doing. who cares that it doesn't scale infinitely, and you get to keep all the money unlike VC funded startup!

<comment><USER14> 7 figure profit or revenue?

<comment><USER15> 7 figure personal income for the owners of a services company is not unheard of.

The owner might elect to keep money in the business account instead of transferring it to a personal one for tax reasons. If you are fully in control of the business there isn't much difference. For example you can buy a house with company money and lease it to yourself for $100/month. This would not register as profit for you or the business.

<comment><USER16> That all sounds widely inaccurate from my experience. It's just pass-through income, it was even addressed in the recent tax overhaul. Additionally, a requirement for rentals (or check at least) is whether it's being rented at the current market rate.

</comment></comment></comment></comment></comment><comment><USER17> 99% of the 'AI' startups, because the 'AI' is usually team of humans somewhere in India. Fake it till you make it, I think?

I'm not saying this to be negative, as this will actually work to validate product-market-fit before investing in the AI development.

Most of these companies will fail though, as their pricing will be based on a 100% AI solution, which is rarely achievable.

<comment><USER18> There are so many of those fake AI startups now that you could probably build a successful startup specifically to provide offshore human staffing services and workflow automation to them. During a gold rush, sell shovels.

<comment><USER19> ...and then lower your costs by building a real AGI to pretend to be humans pretending to be AI.

(Has anyone done this particular sci-fi plot?)

<comment><USER20> Yes, in the book Life 3.0 by Max Tegmark! (An AGI is implemented that makes money on Amazon Mechanical Turk.)

</comment></comment></comment></comment><comment><USER21> AirBnB:

'Let's send emails, teach [users] professional photography, and test them. "We said, 'Screw that.'" [4] Instead, they rented a $5,000 camera and went door to door, taking professional pictures of as many New York listings as possible. [1]

[https://growthhackers.com/growth- studies/airbnb](https://growthhackers.com/growth-studies/airbnb)

<comment><USER22> Should be noted that the founders were effectively trained designers and had probably better than amateur photog skills. They knew what they were doing when staging/taking snaps.

<comment><USER23> It's true, but I think this case is still counterintuitive. This was in the middle of the YC batch, like "Where are the AirBnBs this week? Oh, they're in New York taking pictures of apartments." At the time it just wasn't obvious that was what they should be doing.

<comment><USER22> It's funny because I would see that as a spectacularly good use of their time.

I don't even see why it's considered a hack.

People are visual - we make decisions based on how things look. Their product is online, the pictures are basically everything. The snaps are 90% of what's being presented, so making sure those are good would be worth 1/2 of their time overall. The technology part of AriBnB at smaller scale is just not rocket science, it's almost commodity.

<comment><USER24> It's a good example of knowing your market. It's _not_ universally true that more photos = better for your users.

Google is a good counterexample. Google in its early days was famously _not_ visual - the visual design was incredibly sparse, there were no pictures on the results, there were no pictures on the _ads_ \- and that was a huge contrast to most other sites, where you had animated punch-the-monkey graphics scrolling across the screen. The reason for this is that the primary utility for Google (in the early days) was to get you _off_ the site and to your destination as quickly as possible. Anything that drew your attention - <USER2> than the result you wanted - was a distraction. Google's made attempts to put pictures on the results pages since - we had plenty of data showing that peoples' attention is instantly drawn to images, and when your department's name is "Search Features" it's awfully tempting to draw attention to the features you're developing - but every such attempt seems to cost Google in brand equity in the long run, and ends up getting reverted eventually.

The key insight for AirBnB was that they are selling an experience, not information. When you're deciding where to book a hotel, you want a visceral sense of how it would feel to be on vacation at that place, and a picture is the best way to achieve that.

<comment><USER25> The reason for this back then was a slower internet connection. If Google had the bandwidth when they first started they would have inserted images and videos to their search results and ads.

</comment></comment></comment></comment></comment></comment><comment><USER26> I didn't build out an account page for [https://ipinfo.io](https://ipinfo.io) until we had about 500 paying customers. If you needed to update your credit card or make other account changes you had to email me, and I'd update the database manually. Only after I was spending at least an hour every day dealing with those sort of requests did we go and build out a full account dashboard, where users could manage their accounts themselves, plus also do bulk uploads, see a graph or request volumes, and interact with the API via a UI. Before that the focus had been 100% on the API and the data quality.

<comment><USER27> People were emailing you their credit card numbers?

<comment><USER26> No, I'd create and share a one time link that'd take them to a page where they could enter their CC details via stripe Checkout.js.

</comment></comment></comment><comment><USER28> While I am not a success story yet, I am a founder. If my clients had a problem on their site, sometimes I would just fix it for them instead of showing them how to do it themselves. Then I would improve the system on the next update so I didn't even have to show the user how to do something because I made it super obvious.

Long story short, instead of making documentation, I fixed everything that my clients would ask me how it worked. This has limitations, but it saved me tons of time on support, training and documentation that would later change anyway. And my product got consistently easier to use, and dropped training requirements to near zero.

<comment><USER29> I like this approach - especially when customers are hiring you and/or buying a product that is support to work well for them without burdening them with a DIY maintenance ..which results in training etc.

<comment><USER28> I have resellers of my product, and they use it build websites for their clients. And one of the things my clients had a hard time with (a while ago) was retraining their end users. This would happen because their users' had employee turn over or simply "forgot how to do xyz" because they hadn't logged in for 6 months.

It's amazing how often I can re-train someone on the exact same thing multiple times and have it not stick. All it takes is something you do rarely (couple times a year or less) and retraining/support is needed.

The mental frustration and training time/support costs is a big motivator to fix the underlying problem.

I think this fundamental perspective maybe be harder to implement the larger your team/business though?

</comment></comment></comment><comment><USER30> My cofounder from 2010-12 is an amazing product manager. Here's he giving a 5-minute talk on "How $40 Saved Us 9 Months and $2MM" [https://vimeo.com/24749599](https://vimeo.com/24749599)

The short version is that we were looking at building a complex social experience that had Facebook newsfeed items as a key component. We used GreaseMonkey to fake it entirely: user testers would log in to Facebook on our tricked-out computer, a GreaseMonkey script would steal faces and names from below the fold, and then insert fake news items into their feed that were apparently from their real friends. (At the end of the user test we'd come clean so they weren't confused.)

What we learned is that people hated the idea. So that meant I never had to write a line of production-grade code for this. Some of our competitors had very similar ideas and ended up building full products to learn the same lesson. What they built was way more scalable, of course. But that's not a virtue in a code base that just gets thrown out.

</comment><comment><USER31> We delivered fertilizer to our customers in rural Kenya. We rented 10 ton lorries, hired trucks, and set up distribution points around rural schools and churches. For two weeks, we literally schlepped tons of fertilizer.

<comment><USER32> Neat project. I wonder if our agricultural borrowers / partners in Kenya should be talking to you.

<comment><USER31> I think our partnerships manager is talking with you guys right now actually!

</comment></comment></comment><comment><USER33> At reddit, any time someone bought merchandise, we sent them a hand signed postcard thanking them. Every once in a while we'd have a signing party where Alexis would bring a bunch of postcards and pens and we'd all sign a stack of postcards.

And of course, the most well known hack was Steve and Alexis submitting most of the content for the first few months until there were enough people to keep the front page fresh.

We did other stuff too, like office tours for anyone who asked (and showed up in SF), giving free reddit gold to anyone who sent a postcard (which we had to process by hand), sending merch to people who did good things.

<comment><USER34> > was Steve and Alexis submitting most of the content for the first few months > until there were enough people to keep the front page fresh.

To wit, they submitted most of the content -and comments- under a variety of pseudonyms to give the illusion of mass-adoption

<comment><USER35> Yeah, what a sly word to avoid breaking down what's included: "content". Experienced in carefully choosing words =]

<comment><USER33> It wasn't sly, OP is wrong. There were no comments on reddit till there were plenty of users to make them.

<comment><USER35> Thanks for the levelheaded correction, m8.

</comment></comment></comment></comment></comment><comment><USER36> I created an application which can help people invest:

[https://projectpiglet.com/](https://projectpiglet.com/)

It's really just a demo of platform which creates a knowledge graph in any network: [https://metacortex.me/](https://metacortex.me/)

I can't technically say a lot of things due to myself not being a registered financial advisor. However, what I can do is post my stories and predictions (which I used to do regularly on Reddit).

I managed to get around 100 highly engaged users (many lesser engaged) to help me develop the system. I did this by offering 1 month free every time they provide feedback. I then manually wrote a response and implemented a fix for each suggestion (plus provided one month free).

The users that didn't provide feedback ended up paying for the service. Everyone else helped find bugs in the platform, which helped a ton.

</comment><comment><USER37> I am the CEO of a bootstrapped SaaS business approaching $1mm ARR.

I still do all of the customer/technical support. To be honest, it is a bit overwhelming and starting to take away from other tasks so I likely won't do 100% of it for much longer. However, it has really helped us hone in on our customer needs & sell them on new features. I don't regret it one bit!

p.s. we are searching for a CTO to help us build out a team (large equity stake + modest salary). Email me hank (at) ordermetrics (dot) io if interested.

<comment><USER38> Just a side note, I checked out your site and saw this snippet:

"About Order Metrics OrderMetrics.io is built and maintained by ex-ecommerce professionals who were dissastisfied by the tools ..."

I read this as you are "ex-professionals" which probably isn't true ;) My 2 cents, change it to just be: "OrderMetrics.io is built and maintained by ecommerce professionals who were dissastisfied by the tools ..."

<comment><USER37> Thanks! We are in process of re-design/re-brand & new copy. Please excuse our amateur v1 site :)

</comment></comment></comment><comment><USER39> The #1 approach that worked for us at Mattermark was having founders talk to every single prospect early on. Most of the best approaches I have heard are just a business contextual version of this (eg Airbnb sending a company rep to meet customer first hand and take pics).

</comment><comment><USER40> When I was an early employee at Syncplicity, I only optimized the desktop clients to meet my needs as a power user.

Most users didn't use the product at as much of a scale that I did, so they were happy. The users who tried to use the product at a higher scale were so few that we just accepted that we couldn't meet their needs and grow our business.

So, to generalize:

1: Growing your business is more important than scaling for 100% of your users. Scale for 98% of your users and invest in use cases that will grow your business.

2: An early stage startup doesn't need to scale like Google. If your business takes off like that, you'll be able to hire enough smart people to fix the problem. Instead, spend time growing your business.

</comment><comment><USER41> Dolly's original fulfillment algorithm (pairing supply with units of demand) was predominantly SMS'ing independent contractors (that had previously signed up) to see if they were interested in the gig. A ton of text messaging behind the scenes.

Eventually we automated out a whole suite of fulfillment systems that have scaled into 6 figures worth of orders.

It's amazing what you can do with clear inputs & outputs and the illusion of a black box until you can actually build your black box.

</comment><comment><USER42> Careful. While doing things that don't scale is generally good advice for startups, don't build stuff that you already know will NEVER EVER scale.

If you develop stuff and still have to put manual effort because you save time - fine. But don't just get lazy and stop thinking about the consequences of your decisions - it will bite you sooner or later.

<comment><USER43> > don't build stuff that you already know will NEVER EVER scale

but one needs to know/learn this first, otherwise there wouldn't be an innovation

</comment></comment><comment><AUTHOR> Here's one popular example:

Recruit new users by manually installing your s/w on their computers by @patrickc" link: [http://paulgraham.com/ds.html](http://paulgraham.com/ds.html)

<comment><USER44> Borderline unethical.

<comment><USER45> > At YC we use the term "Collison installation" for the technique they > invented. More diffident founders ask "Will you try our beta?" and if the > answer is yes, they say "Great, we'll send you a link." But the Collison > brothers weren't going to wait. When anyone agreed to try Stripe they'd say > "Right then, give me your laptop" and set them up on the spot.

What could _possibly_ be unethical about that?!

</comment></comment></comment><comment><USER46> We built the first version of [https://thestreamable.com](https://thestreamable.com) using Google Sheets.

1\. We used Google Sheets as pseudo database.

2\. We stored Services, Channels, Locals, & Plans.

3\. We wrote a basic Python script that exported the data in structured JSON files to be used by our CMS.

<comment><USER47> > 1\. We used Google Sheets as pseudo database.

Was your service programmatically reading and/or writing the Google Sheet "database"? I've built some small sites that used JavaScript to load data from a read-only Google Sheet. It was a surprisingly productive way to get a prototype running, but I never had to handle more than a few hits a day. :)

Did your MVP using Google Sheet impact or influence the design of future versions of your backend?

<comment><USER46> The data we were using didn't change more than a few times a week. So we would generate JSON files using Python and the Google Sheets API. Since we never had to hit the Google Sheets API in any live fashion, it was basically small cached data files.

This was fine even as we approached >100K monthly uniques.

We moved more the data to our CMS as traffic grew for ease of use, but we could have used this method basically indefinitely.

</comment></comment></comment><comment><USER48> 1\. Wrote and optimized DreamList [https://www.dreamlist.com](https://www.dreamlist.com) (solo founder) in Go for the fastest Time to First Byte so it naturally outranks much better funded and staffed competitors in SEO. Some other tricks:

2\. Channel many normally automated tasks through high touch customer service - encourage users and their guests to email us about anything and everything. We've learned tremendously from user feedback and by responding often within an hour, we've earned a lot user loyalty. One example was a grandmother who wanted to buy a gift for her grandchild, but the linked item was out of stock. She called the DreamList customer number straight to the founder. We found a different store for her to buy from. Now we have a product graph at different major stores and more leverage as a business.

3\. Watch for user culture as well as team culture. A small set of users may find your site tremendously useful, and another small set may find it useful for malicious purposes (such as spamming people to sign up for some scam using your invitation forms, for example). We track all errors, log email bounces, etc, and wait a while before opening features that can be abused (including payments). Max Levchin has a story about how abuse and the 90 day payment refund process almost sank PayPal and they had millions in the bank.

4\. Don't assume anything is a "best" approach. Try out counterintuitive measures and you will find ways to beat the competition far cheaper. Examples: Using Go when competitors use Rails and you need far less servers to handle the same number of users with a faster experience; We also invented several new words to test how pages with static content, vs JS painted built-in JSON, vs JS painted with external JSON do on SEO. We then leave the test going and re-check our assumptions periodically. I'd underline the last sentence for companies using JS frameworks - some slow you down more than they help.

5\. Any new feature is launched and customer-serviced manually until we know we are serving those users in the best way possible. We went through a bunch of different wordings for every single email in our usual workflow, and little things, like an extra sentence that shows your humanity, made a huge difference.

There is so much more you can do, but the gist is there are dozens of approaches to every feature and problem, and it's worth considering more than one or two used by competitors. It doesn't take much to delight users and build a better product these days.

</comment><comment><USER49> At a previous job, we were trying to get always-on internet for a pre-IoT energy management product. This was when the fastest wireless you could get was Sprint's 1xRTT and most of the nation was stuck at even slower speeds, if you could get internet at all. We would purchase "Unlimited" dialup internet, then nail the connection up.

It was never going to scale. We charged our customers less than we were paying for the phone line, let alone the ISP service. If the ISPs discovered we were consuming their lines and not paying enough for them, we would have been thrown off.

Still, it was enough to get the company to a sale. All they needed to do was hang on until the tech caught up with them. Today, you could build the same product in a weekend...

</comment><comment><USER50> This might be apocryphal, but I heard that Facebook started as a PHP website and ended up having an enormous amount of C code propping it up while still having all the UI logic in PHP for a long time.

OTOH, if this is true, maybe it _did_ scale, in terms of performance at a certain architectural cost, and maybe more importantly in terms of their ability to hire as a very young (in every sense) startup.

<comment><USER51> I still see Facebook site URLs with .php extensions, so they definitely didn't just throw away their roots.

<comment><USER52> I suppose these .php URLs are there to not break old shared/bookmarked links.

<comment><USER51> A simple htaccess rewrite ruling can cover handling that, though.

</comment></comment></comment></comment><comment><USER46> My last company was a grocery coupon app. We used to go to Apple Store's around the Bay Area (especially on iPhone Launch Day) and pay people $1 to install and try our app.

<comment><USER29> this is interesting - I'd love to learn more about your experience with a coupon business.

<comment><USER46> Send me a message on twitter @jasongurwin

</comment></comment></comment><comment><USER53> At [https://www.chessable.com](https://www.chessable.com) we manually, line by line, imported a full chess book to our digital format! Takes ages... later, after some validation, we built a tool that automates most of this.

<comment><USER54> Interesting, I expected this was a manual process. After all, the author has to manually write it the first time round, and inputting the moves takes only a tiny proportion of the time spent writing a chess book. And there are only (a few dozen? A hundred?) books that have been ported from hard copy to Chessable, so there isn't a huge degree of scale.

</comment></comment><comment><USER55> When CircleCI started, we manually set up customers' builds for them. They'd give us access to the code, and we'd look through their codebase to figure out how to build the thing. Each new customer we'd add their rules to our "inference engine" (eg if you have a dir called vendor/bundle, you need to pass the --vendor flag to bundler). After about 20 customers it had gotten good enough that we could update it via support request instead.

</comment><comment><USER56> At The Farmer's Dog we built a subscription based pet food management backend on Google Spreadsheets. Customers would sign up for a phone consultation on a Squarespace website, we'd then call them back and figure out their subscription details. These would be manually entered into a spreadsheet

The main sheet contained information about each customer and their subscription, e.g. pets, chosen recipes and subscription frequencies.

One sheet would dynamically populate what and how much we needed to cook for a given week by looking at active customers and their subscriptions. This was broken down per ingredient basis. We'd then place POs, cook and pack the food.

Another sheet would generate orders for the given week based on similar logic. We then used Google Spreadsheets scripting support to generate packing slips, customised feeding guides and food labels. Each asset type had its own Google Docs template. The script filled in the blanks and created a new folder. The resulting files were then exported as PDFs and passed to our fulfillment.

Oh, and we did our own deliveries in NYC too in the early days.

We've since built out our own ecommerce platform from the ground up and we continue to automate fulfillment, customisation and operational processes. Sounds exciting? We're hiring.

<comment><USER57> >> Sounds exciting? We're hiring.

Does the position require dog-fooding the product?

<comment><USER56> It'a made from human grade ingredients in a FDA certified facility so you're welcome to, if your pup lets you get away with it.

</comment></comment></comment><comment><USER58> If you're doing this, it helps to also talk about the context and the constraint they were currently operating under.

The solutions by themselves don't illuminate unless you also illustrate what they were trying to achieve and how they got around the limitation.

</comment><comment><USER59> Using redis as a main database.

</comment><comment><USER60> Not my story, but useful and interesting no less... Somebody I used to work with told me about a project they did (about 25 years ago now) where they were developing a movie on demand service for a cable provider.

Given the year, it used tapes to play the movies. The user would dial in with their phone, enter a code for the movie they'd want to watch, a motorized catalog system would fetch the tape, insert it into a player and then the user could control the tape player with their phone.

Well, it was a couple days before launch and the catalog system was still not working. They ended up launching with the system printing a receipt, then a human would fetch the tape and insert it into a machine. This went on for several weeks before the automated catalog system was working.

In hindsight, they realized it was actually easier to scale the humans fetching tapes than the machines and therefore the humans were even faster at busy times. System subscribers didn't even know humans were used in the beginning and it launched without a hitch as far as users were concerned. So, like many stories in this thread, sometimes it's easier to bootstrap with manual labor and it can scale with machines doing the right parts of the process.

</comment><comment><USER61> reddit discussions were seeded for a few weeks with a series of sock puppet conversations among multiple accounts controlled by the founders and a couple of friends: [https://news.ycombinator.com/item?id=1337359](https://news.ycombinator.com/item?id=1337359)

<comment><USER62> Always thought it was super interesting/smart that they even implemented functionality just to make this easier, i.e. an extra textbox only they could see that let them set a username for comments they right.

</comment></comment><comment><USER63> Triplebyte founders started by doing tons of technical interviews themselves with candidates.

[https://triplebyte.com/blog/three-hundred-programming- interv...](https://triplebyte.com/blog/three-hundred-programming-interviews- in-thirty-days)

After the first few hires, their engineers all took part in interviewing candidates. That has deferred the scaling problem quite well.

<comment><AUTHOR> Interesting

</comment></comment><comment><USER64> Not a success by any means yet but I got my first 10 customers for Trunk ([https://www.trunkinventory.com](https://www.trunkinventory.com)) by cold- messaging users on e-commerce forums and focusing only on features that would help solve their problem. I still don't have any account management features (forgot password, change password, etc) or even obvious features that would make their lives easier (filtering, proper search, etc). Instead, I dedicated all my energy to making sure inventory syncing covered all edge cases and worked reliably.

Furthermore, my current sales process is having people enter their email address on my outdated landing page and then reaching out to them personally to see if they are a good fit. This worked great early on since too many users signing up at the same time can take a massive toll on my servers due to the initial import load (some users have TONS of listings in their stores).

I'm now working on a proper marketing page and introducing a scalable way to have users sign up themselves.

</comment><comment><USER65> The Just Mayo guys paid people to buy cases of their products at supermarkets to juice sales [https://www.bloomberg.com/news/articles/2016-08-04/food- star...](https://www.bloomberg.com/news/articles/2016-08-04/food-startup-ran- undercover-project-to-buy-up-its-own-products)

<comment><USER66> If this was done to juice metrics shown to investors, doesn't this constitute fraud?

<comment><USER67> Supposedly, they weren't trying to trick investors so much as the stores themselves. Demonstrating high demand convinces the stores to allocate better shelf space and stock in more locations.

<comment><USER68> That is so unethical. If you want to buy shelf space, be upfront about it.

</comment></comment></comment></comment><comment><USER69> We bring high quality freelancers to perform and teach for seniors at assisted living facilities. Hack: my cofounder is a professional opera singer so she does the first gig at every client.

</comment><comment><USER70> One I did. Self modifying Lotus 123 Macro code to format information downloaded from a System/38-IBM AS/400 to make 'nice looking labels'. Because lotus had graphics (PC) and could print them to a Laser printer and the System/38 did not. Ran that way for years

</comment><comment><USER71> This is an engineering example, not a marketing one but the team over at FiveFilters manually created schema rules for extracting the text of articles for every single semi-popular website (ie. similar to how Pocket works), and sells an API for it.

<comment><AUTHOR> Great hack! Thx for sharing

</comment></comment><comment><USER29> We've started an analytics service [1] focused on the operational aspects of automating analytics for life sciences.

We've got good chops in both biotech/life sciences and software development ..and the default urge is to build a fully automated system and tools.

however, what we're doing instead, is focusing on customer development at the front end - the "customer onboarding" process. This is involves a bunch of human interaction to understand exactly how customers are approaching their data and experimental processes - it feels a lot like consulting on the front end and definitely doesn't "scale".

Over time, we'll start creating very specific tools that help a) make onboarding quicker and easier for the customer and b) reduce the onboarding burden on us - the key is to only do this when we have clear understanding of the required features and the ROI for developing them.

Current customer feedback is very interesting it ranges from: "analytics still requires a lot of high-touch expert consulting" to "feature _______ is a simple feature that customers need right now ..make it, and that will lead to other feature insights and customer use."

...would love to hear any advice / thoughts ..we're in the struggle :)

[1] Yukon Data Solutions [https://yukondata.integralappsystems.services/t1/](https://yukondata.integralappsystems.services/t1/)

</comment><comment><USER72> This is not exactly a hack, but a good comparison of "good enough for now" vs. "future proof."

10 years ago I worked for a solar monitoring startup called Energy Recommerce. This is one of the most satisfying jobs I've had in my 20 year career. I did all of the embedded programming to implement our data logger: the provisioning UI, the drivers to collect data from devices, the database, and the mechanism to deliver data to our backend. We collected performance data from residential and commercial solar systems, and reported production data to state governments so the system owners could collect production rebates. We helped commercial solar companies manage their systems, including some big-name companies. The engineering team was literally me and one of the founders.

There were a lot of hacks and short cuts, but I will tell the story of one particular design decision that carried us for years, but was ultimately replaced.

We made the decision to define classes of devices (power meters, inverters, string monitors, weather stations) with a fixed set of datapoints, regardless of what each individual device could do. We then collected the data provided by the device and filled in the object. Sometimes a datapoint in our object was not available and we stored a NULL value. We scaled values to the units we defined in our objects (e.g., kw to w). More often the devices provided more data than would fit in our object, and some customers started asking for these datapoints. This meant we had to defined extended versions of some of our datapoints; meter_ext, inverter_ext, etc. This meant now we had two sets of objects, but the basic model still worked. We also sometimes had data collection bugs: collecting the wrong datapoint, or a scaling a value incorrectly. This meant the data was invalid and we had to update the software on the data logger to correct the issue. Still, our team was small and we moved fast.

Our biggest competitor at the time was a company called Fat Spaniel. We were always a bit baffled by the size of Fat Spaniel - our team was 5 people, including business development and software dev. Fat Spaniel had, in comparison, lots of funding and a much bigger team, but their customer base was not much larger. What were they doing?

Eventually an inverter company called Power One acquired both us and Fat Spaniel, and combined us into a single organization in San Jose. This turned out to be great. We combined into a single, really effective team, and I had a chances to peek under the hood of what Fat Spaniel had built.

They had made a fundamentally different design decision: they collected all the data provided by every device and delivered it to the backend. Once on the backend there was a complex xml-based system that defined what the data meant and put it into the same sorts of objects we had. If they found a bug in the way a datapoint was assigned, or the way it was scaled, they could fix the definition and then re-play all the data they had collected. Because they had the raw data from the device they could always go back and add a datapoint or fix other issues in the historical data.

This system was fundamentally more complex to develop, and required a bigger team, but it was grounded in good principals. It became the system we based our combined operation on. In fact, what we did was adapt the hardware and firmware that we had developed at Energy Recommerce to use the backend that Fat Spaniel had developed.

The system Fat Spaniel developed was technically better, and resulted in less technical debt. However, it was considerably more complex and took more money to develop. This meant their burn rate was much higher and they moved more slowly and we could compete head-on with them using a smaller team and less money.

[edited to fix cut&paste error]

<comment><USER73> That's pretty interesting, especially in how it made two apparently differently-capable companies into relatively equal competitors.

</comment></comment><comment><USER74> Aardvark, the question and answer service that was later bought by Google, initially routed and answered all user questions from their internal team.

<comment><AUTHOR> Can imagine that :) I wonder how many of Quora's initial questions were internally answered too?

</comment></comment><comment><USER75> We ([http://draftss.com](http://draftss.com)) are a company providing graphic design & landing page UI/UX on a monthly subscription. Our core as a design company lays in what we do best. Design. Using the skill-set of designers that we have on board, we created a product for founders to get constructive UI/UX feedback for their landing page. ([http://draftss.com/feedback.html](http://draftss.com/feedback.html))

The depth of the feedback comprises of everything from logo, font, color, size, call to action, images, and every other component on the website. With feedback we also provide constructive steps that founders can take to make their product better. All of this being completely free.

The non-scalability part: The time taken to evaluate a website is proportional to the quality of feedback we deliver. If the time invested is less, the feedback looses value. To keep it up to the mark where the feedback is valuable, a proper evaluation & time investment is necessary. This may account to almost 5-7% of a designers time for each feedback everyday. When the number of feedback requests shoots up, there are only limited feedbacks that can be provided everyday.

How we benefit from it: In this complete process, we learn alot about generic errors, optimal UI/UX, trends, ideas and lot more. We learn about the little innovative things that founders do which stands out on their website. Other things we gain are; network, prospects & karma.

Although the product is still in the beta, but we have already provided 100+ feedback to founders for their landing page UI/UX. Considering the amount of insight that we gain, we can write a complete ebook over it. It may turn out to be the next not-scalable-thing we do for scaling.

<comment><USER64> FYI your first URL is broken

<comment><USER75> Fixed it. Thanks.

</comment></comment></comment><comment><USER76> Im building a small online store focused on selling products from other small(er, ish) stores/manufacturers. Havent written a line of code yet. Been meeting and working with potential partner stores/manufacturers and helping them with their sales/marketing. This allows me to learn about their pains and needs/wants. It also helps them see how working with me would be a benefit. Been doing it for months now, and am projecting that first line of code will be written in Q1 2019.

To give you the most recent example, I collaborated with a small store owner and helped him increase his conversion rates. This put hin on track to hitting a very important milestone of selling $1000 worth of product each month. Doesnt sound like a lot, but his margins are insanely good.

This is not scalable at all, and costs me a good amount of money to do. But the insights and connections are more than worth it. To give you an idea, I used to have a business doing the very same things and charged goid money for it.

If you sell anything online, get in touch. Id love to collab with you.

<comment> 100-xyz How do we get in touch with you?

<comment><USER76> Email in my profile :)

</comment></comment></comment><comment><USER77> This example is banal but that is sort of the point:

When we started Cronitor we handled our monthly recurring billing for the first ten users by dropping a stripe checkout form on our site (like 5 lines of JavaScript) and then manually charging users at renewal. In that period before product validation we didn't want to spend even an hour on anything that didn't add value for users.

</comment><comment><USER78> Being bootstrapped means that you need to do a lot of things by yourself. You can't hire a team yet because of the lack of money and at first, everything is manual until you identify repeatable patterns that you can automate.

With [https://pdfshift.io](https://pdfshift.io), I'm in the same situation. As a tool to convert HTML to PDF, I get many requests about documents not being rendered well on PDF. I take the time to help my users tweaking the CSS to have the perfect result. This takes a lot of time and doesn't always make them convert, but for those who do, I have a lower chance they churn because __they know they can count on me __.

</comment><comment><USER79> I'm currently the only Customer Success Manager for our bootstrapped Customer Success Management startup Akita --[https://www.akitaapp.com](https://www.akitaapp.com) (in addition to being CEO/Head of Product Development).

I felt like it was the best way to get continuous feedback from customers and dog food our product.

It has really helped us improve our product but is now going from something that "doesn't scale" to something that "prevents scaling". I hope to hire my replacement pretty soon!

<comment><AUTHOR> Great story -- thanks for sharing

</comment></comment><comment><USER73> Technical co-founder (VoiStory - [https://voistory.com](https://voistory.com)), and we just added "sharing" for stories told by users. Except this "share" form just sends us an email with their share request and we implement the link in the back end manually (after connecting with the target recipient, if needed). Eventually we'll build out an automated share/invite/link system, but for now it's just me and some node scripts.

</comment><comment><USER80> On a "DoThingsThatDontScale" mode now for [https://nodablock.com](https://nodablock.com) . Customers contact me by email or I find them via conferences. They tell me the plan they want or their usecase. I then deploy manually the blockchain node they want, send them by email the API key and endpoint and invoice. Didn't automate yet until I figure out what most of the people want. (Happy to get any feedbacks too)

<comment><USER81> awesome :) do you take payment in crypto currency?

<comment><USER80> shoot me an email ! eric [[at]] nodablock . com

</comment></comment></comment><comment><USER82> I am sure hardware startups are littered with these kinda stories, but Oculus seems to be a good example. I remember reading somewhere initial prototypes were basically duct-tape'd together

[https://www.smithsonianmag.com/innovation/how-palmer- luckey-...](https://www.smithsonianmag.com/innovation/how-palmer-luckey- created-oculus-rift-180953049/)

<comment><USER83> Prototypes are not expected to scale; I think OP means things that most would automate.

<comment><USER84> nothing that doesn't scale is expected to scale by people who know they don't scale.

so yep, prototypes are things that people do that don't scale.

<comment><USER85> I think the point of the comment you replied to is that nobody builds prototypes in a scalable fashion, since if it was scalable (implying you spent some resource to make it scalable) it wouldn't be prototype.

<comment><USER84> The whole point of doing things that don't scale includes..... doing things that don't scale.

That includes things that can't scale.

That's the whole point.

Why discriminate against prototypes when we're doing things that don't scale and they're... well... things that don't scale? Making prototypes and testing assumptions with them is 100% in the spirit of the methodology.

<comment><USER6> I think there's some nuance about charging for the thing as if it were not a prototype - so the prototype part is (somewhat) hidden to the user. People just respond differently, and you get market testing.

Somehow in hardware this seems crazy and there's a million reasons not to actually sell the product (certification, hard to change in the field, it's expensive!), so I think it's done less often.

</comment></comment></comment></comment></comment></comment><comment><USER86> Things that don't scale was really inspiring actually I haven't gone through it yet but after this, we are able to start a new startup which suddenly started growing like a charm and then I came to know that I should consider things that don't scale to measure my scales and sales. [https://newpipeapk.xyz/](https://newpipeapk.xyz/)

</comment><comment> crooked-v My company (CrowdStreet) definitely took a "fake it 'til you make it" approach. The early days involved the founders manually juggling spreadsheets and emails to maintain the appearance of an automated platform while they gauged interest and built out the actual code to handle things.

</comment><comment><USER87> This is a few years ago. Processed thousands of 3d scans manually with a tight turnaround for close to a year. Finally automated it!

Not exactly do things that don't scale but when I moved to SF I shared a double bed with my cofounder for 9 months (room came furnished). Saved a lot on rent!

</comment><comment><AUTHOR> UPDATE: Hey there hackers, after this thread blew up in engagement, I curated many of these suggestions and built a quick repository simply called "Do Things That Don't Scale". The idea is to keep it crowdsourced and let people find/discover creative hacks from other founders. Check it out.. it's currently live on Product Hunt.

[https://www.producthunt.com/posts/do-things-that-don-t- scale](https://www.producthunt.com/posts/do-things-that-don-t-scale)

</comment><comment><USER88> Stripe founders used to do manual implementations for customers in the beginning.

<comment><AUTHOR> Yep! Famously called "Collison Installation"

</comment></comment><comment> ____Sash---701_ If anyone here wants to partner with a coffee company that donates money to help animal conservation, you can email me. oahcoffeeworks.com. Commenting on HN is something that doesn't scale :P

</comment><comment><USER89> I had a founder that was so cheap he only hired the most entry level engineers for all aspects his projects and it was always a disaster. At this point it is obvious that approach is actually more expensive and usually failed him. Once the company accidentally became a success he was forced to hire real engineers that rewrote everything from the ground up at the last second and barely met customer scaling goals.

</comment><comment><USER90> The comment section is absolute gold. I may have favorited this thread.</comment>


Why mobile advertising isn�t as huge as it�s hyped to be (yet) - <AUTHOR> http://thenextweb.com/dd/2014/07/04/mobile-advertising-isnt-huge-hyped-yet/ <comment><AUTHOR> Why mobile advertising isn't as huge as it's hyped to be (yet) [http://tnw.to//l/FvWk](http://tnw.to//l/FvWk)</comment>


Ripple has been open sourced - <AUTHOR> https://github.com/ripple/rippled

<comment><USER2> This is something I really looked forward, Ripple is full of opportunities and I believe that it will enable a revolution.</comment>


Amazon lobbies to exempt employees from labor protections (non-compete) - <AUTHOR> https://apnews.com/5c01ffdd9fbb48639fc43bc376f501e4 <comment><AUTHOR> Amazon is a great product and I am a huge fan, I run most game backends and APIs on AWS, so this is very disappointing...

> _The protections would partially prohibit non-compete clauses — > controversial agreements used by tech companies and others to block > employees from going to work for competitors or launching rival startups._

> _The bill passed the Washington state Senate Tuesday with the salary > threshold set at $100,000 - the level sought by Amazon. Employees above the > threshold would be exempted from the labor protection. The original wage > threshold in the measure was about $180,000._

Amazon lowered it to pull in most software developers.

> _Other provisions require some protections for workers making more than > $100,000, including an 18-month limit on any non-compete clauses they sign > and a requirement that employees must be compensated while they are barred > from working._

At least they have to be compensated but this is still a troubling move from a company that was started by an engineer and devs have been a huge key to their rise.

California is innovative and non-competes are illegal. That shows that non- competes are anti-competition, anti-entrepreneur, anti-small/medium business, anti-worker and most of all anti-innovation.

NDAs are enough, non-competes are excessive. NDAs cover confidential information, existing clients and processes which should be covered if they were invented there, but taking someone's ability/skill that originally got them to your company to help Amazon is a bad move towards developers. Especially bad when Amazon runs a developer cloud platform in AWS where developers/startups choose which cloud to run on many times.

As a smaller company and freelancer/contractor, companies all the time try to give you 2 year non-competes non-compensated for a 6 month to year long project, laughable. Most of the time there you are bringing skills to a company that they didn't have, then they want you to not use them after? That is a no.

Let's hope more states go the way of California on non-competes and that if this ever goes to SCOTUS that it doesn't end up becoming law nationally. Though SCOTUS did recently uphold forced arbitration so that isn't good.

Bezos forgot, the MBAs and lawyers are in charge, ladders that built giants are being pulled up.</comment>


Ask HN: WebEx alternatives? - <AUTHOR>

The company I work for (B2B publisher) currently publishes sponsored webinars using WebEx.
I'm sitting down today to rework some related code -- and it occurs to me that it is 2010, and I can't believe there are no viable competitors to WebEx (at least for larger presentations, e.g. over 100 people).
WebEx continues to be the same bloated, clunky, overpriced, enterprise-y service from 2003. How has no one yet found a way to compete?
If anyone has had positive success with another service for large scale events, I'd be so happy if you could share that here.
If not, hopefully one of you guys will get inspired to take on a dinosaur that, as far as I know, is continuing to rake in the cash.
EDIT: To be clear, I'm specifically curious about webinars as opposed to smaller meetings or presentations. The publisher I work for has produced webinars with over 1,000 participants so the need to scale is paramount. (That said, the need for every participant to be able to participate as in a traditional webinar is actually a bit unnecessary.) <comment><USER2> This is a market that is ripe for innovation. The large incumbents are very expensive and offer an experience that borders on abuse.

My company has about a half-dozen heavy users and we spend more than $300 per month on this junk. A lighter-weight $20/month solution could do very well I think. Here would be my feature list:

* Cross-platform HTML5, not a java plugin or Flash

* Cope with multiple screens and very high screen resolutions for presenters (so viewers on crappy hardware don't suffer)

* Simple interface. Nothing but "share screen" and "invite participant." No chat, surveys, hand raising or other cruft.

You would also want to support corporate pricing as a lot of users are at big cos.

<comment><USER3> I agree with you here. But the only problem is... you need the stomach for the enterprise sales cycle. Meaning 6-12 months. Anybody looking to jump in should do lots of homework here and if a willing corporate pre-buyer is there, line them up and let them pay to build the product. Leveraging their connections could also be a benefit. What company feels the most pain from this/would pay for it?

<comment><USER2> I think the very biggest companies (with hundreds/thousands of users) would require a long sales cycle, but I would start by ignoring that market since those companies aren't going to move to this new upstart until it has some history.

So the bulk of this business probably starts with individual accounts and small departments/companies (<50 users). This group is making purchase decisions much like consumers. That group can be sold on the web, and just needs bulk pricing options to feel good about their purchase decision.

</comment></comment></comment><comment><USER4> I had the same problem when searching for a WebEx alternative a little while back. Didn't really find anything viable.

They all seem kind of Fortune 500ish with complicated pricing matrices and awful looking websites plastered with stock photos of people in suits.

Definitely seems like there's plenty of room for a new entrant to come in and eat their lunch.

</comment><comment><USER5> GotoMeeting is better than WebEx.

Microsoft SharedView isn't terrible for free: <http://connect.microsoft.com/site/sitehome.aspx?SiteID=94>

<comment><USER6> I've never used WebEx, but GoToMeeting is horrible. Their app/plugin re- downloads EVERY meeting, certain clients of mine behind firewalls can't use it, etc. They are the perfect example of dinosaur screenshare technology.

</comment></comment><comment><USER7> Webex works fine behind firewalls and not. It also lets you use your computer as a MIC and speaker instead of dialing in. It can also handle large volumes of people.I've been in some large meetings myself and haven't seen terrible slowdown. For personal stuff you can use the adobe connect now(<http://www.adobe.com/acom/connectnow/>). It's free for 3 people and pretty darn good. It's got 3 way webcam. That way you can see when someone is sleeping. Skype will let you screen share with one person.

</comment><comment><USER8> It does far less but for simple screen sharing and confereces, Skype's free service has worked beautifully for small meetings, though I know you're looking for something that supports bigger audiences.

</comment><comment><USER9> <http://gotomeeting.com>

<comment><USER10> Does it really scale to 100 participants?

<comment><USER11> Yes, and beyond.

I just did a joint webinar with 100 attendees over my Verizon USB dongle on GTM. Worked great.

</comment></comment></comment><comment><USER12> Doesn't Acrobat Connect scale that far? I don't know off-hand.

<comment><USER13> [http://www.adobe.com/products/acrobatconnectpro/webconferenc...](http://www.adobe.com/products/acrobatconnectpro/webconferencing/marketingsales.html)

According to this, it supports up to 80,000 participants.

Having looked around for a similar product, Adobe Connect Pro seems the smoothest so far. The Flash/Air install is fast and easy. I'm not completely in love with how the window ("pod") management works, but it's not the horrible suck that is WebEx.

Microsoft LiveMeeting is so so (better than WebEx IMO), supports hundreds of users, and is very cheap. But, it requires a big Windows client. Their Java client is lacking basic features, like VoIP.

</comment></comment><comment><USER14> If you don't need video and is looking for a similar hosted solution like WebEx, I say go with GoToWebinar. They can support larger groups, even up to 1,000.

If performance has been an issue in the past, maybe you should consider self- hosted products. Since its on-premise, you'll have more control over it. A good one is RHUB (<http://www.rhubcom.com>).

</comment><comment><USER15> AT&T Connect is the best I've used

[http://www.business.att.com/enterprise/Service/unified- commu...](http://www.business.att.com/enterprise/Service/unified- communications-enterprise/conferencing-services-enterprise/web-conferencing- enterprise/)

</comment><comment><USER16> Checkout a list of many more alternatives at [http://vzhai.blogspot.com/2010/06/30-amazing-remote- desktop-...](http://vzhai.blogspot.com/2010/06/30-amazing-remote-desktop- sharing-and.html)

</comment><comment><USER17> It may not be exactly what you're looking for, but it is open source so you might be able to bend it to your will: Big Blue Button (<http://bigbluebutton.org/>)

</comment><comment><USER18> <http://dimdim.com>

<comment><USER19> Quite clunky, but I've used it a lot-- hard to beat "free".

For pay versions, I have to second GoToMeeting-- it's pretty solid.

</comment></comment><comment><USER20> Check out <https://www.readytalk.com/> ... I used it this morning and it was great.

<comment><USER21> I was hoping someone would mention ReadyTalk - I worked there a few years ago and can attest that they are very focused on user experience and personalized support and training, and have been building a really strong webinar offering. Give them a shot!

</comment></comment><comment><USER22> logmein is the best by far for 1 on 1.

logmein pro only lets you share one screen... but it does it perfectly. invaluable for pairing.

logmeinexpress is free and better quality than dimdim

<https://secure.logmein.com/US/products/express/Default.aspx>

</comment><comment><USER23> I haven't had an event that size, but DimDim seems to be fairly strong, and a 'free' service in most respects.

</comment><comment><USER24> Check out vsee.com

They are pretty awesome and in my experience better than WebEx and GotoMeeting.</comment>


Seven Reasons to Choose Node.js for Your Startup - <AUTHOR> https://da-14.com/blog/seven-reasons-choose-nodejs-your-startup <comment><USER2> _It offers steep learning curve_

Let's just let the multiple language issues in the above fragment slide, as they're not native speakers. But this, however:

 _What is more, such overall JavaScript applications require less code and fewer files, compared to those ones, with different languages on the backend and frontend._

Is an extremely broad claim to make, with dubious foundations.</comment>


Mission Creep: NSA's System for Iraq, Afghanistan Ended Up on the Mexican Border - <AUTHOR> https://theintercept.com/2019/05/29/nsa-data-afghanistan-iraq-mexico-border/ <comment><USER2> "the system would enable the .. National Security Agency, to instantaneously share select classified information with America's closest allies in the fight against the Taliban"

Would it also help them figure out who is facilitating the heroin trade out of Afghanistan and where all the money goes ;]</comment>


DNA Collected from found Gum on the streets to Create 3D Portraits - <AUTHOR> http://www.thisiscolossal.com/2013/05/stranger-visions-dna-collected-from-found-objects-synthesized-to-create-3d-printed-portraits/

<comment><USER2> ... estimated portraits showing (according to the artist) "family resemblance", and assuming a 25-year old individual.

Still, very cool.

</comment><comment><USER3> App idea: Take data from two 23andme users, do a random combination, and then show pictures of what their kids might look like. Anybody know where to get the information to generate a face from the raw DNA?</comment>


After selling his company to Google, this man now wants to block ad-blockers - <AUTHOR> http://venturebeat.com/2015/09/07/after-selling-his-company-to-google-this-man-now-wants-to-block-the-ad-blockers/ <comment><USER2> If add's didn't do such shitty things I'd happily run with them on with sites I like so they'd get the revenue but I'm not exposing my computer to their shit to nominally support sites I like.

If you block me for using an ad-blocker _I just won 't use your site/share it/talk about it or anything else_.

<comment><USER3> > If you block me for using an ad-blocker I just won't use your site/share > it/talk about it or anything else.

This. I'm completely at ease with this as a solution, but I think it's why most sites don't (and won't) block folks using ad-blockers.

</comment></comment><comment><USER4> I'm so annoyed with watching ads being my capitalist duty. I do not want to be told to buy things I do not need. What I want is to look at a web site, not to be told to buy shoes.

If you think, website owner, that I am losing you money by refusing to be told to buy home insurance, then just give me a way to give you that money directly and stop nagging me about it.

<comment><USER5> I have to call bull on this. You'd donate to my tiny site that popped up in a Google search, one that you'll likely only visit once? Just by me providing a donation link?

<comment><USER6> I'll just add one word to Jordi's sentence: _" just give me a way to _conveniently_ give you that money directly"_. Like you can't ask people to encrypt their email if it makes their life harder, you can't expect website users to go through repeated hoops for the sake of properly remunerating a website. It's just too much of a hassle, the easy option (installing an ad- blocker) will win.

I will neither make the effort to click the "Donate" link on each site I visit, but what if we could dedicate a Flattr/Patreon-like monthly amount to supporting websites? It could be:

\- Slowly drained during the month, or split at the end of the month in proportion of the visits.

\- Done by the ISP? It would probably be the least privacy-invasive option, since they are already being trusted with knowing what my usage is. Imagine your ISP usage dashboard greeting you with _" You're on a 2MB unlimited ADSL line, for 40 $/month. You are also choosing to pay 10 $/month for proportional website remuneration, which currently will go to these sites: <pie chart showing my money split>. Websites frequently visited but not appearing here might not be part of ProportionalMonetizationPlatform, or be paid apps that you remunerate directly."_

<comment><USER5> Edit: This post is just terrible on my part, leaving it here solely for the fact it has a response below it, but I apologise for it's existence.

\---

I think I'd rather just let you visit with an ad blocker than try to convince anyone that that idea would work

You're effectively trying to take America's tipping system and apply it to your ISP and apply that to the world?

Do you know how many ISPs there are in the world? They can barely agree on where to route traffic sometimes much less a system that wouldn't benefit them in any way

I think you're proposing the impossible to put yourself in a morally good position. "I'll never view ads because <impossible request>" like the people that claim piracy is fine because they wouldn't have bought the content anyway so nobody loses out.

It's just a lie, it'd be more honest to just say "fuck content creators, I'm not watching adverts. Who cares if they can't make money" than this method of remuneration you've come up with

<comment><USER6> Hey, thanks for acknowledging the idea. May I point you to the conditionals in my post implying the possibility of a honest debate? Instead of aggressively caricaturing and strawman-ing me, could you try to discuss it?

\- Where do you see the slightest tentative to put _" myself in a good position"_ ? I'm making a proposal and seeing what other members of this community think about it.

\- Bravo for implying I'm saying _" fuck to content creators"_ . Because, yes, I have both Patreon and Flattr accounts donating to a few of them. But like said elsewhere in this thread by another commenter, this fails to compensate "one-off websites" and am discussing what a solution could look like without the drawbacks of advertising.

\- So because of some technicality (ISPs not agreeing) we are prohibited from even _talking_ about changing anything?! Applause, nice approach to problem solving.

<comment><USER5> My apologies. That reply had been made with outside influence on the grump levels. Not saying that to excuse, just to explain.

I'll leave the comment there for the sake of others being able to follow where this ended up but you are correct and to be frank it was a pretty terrible post on my part. The post only really needed the troubles of implementing it at the ISP level, if anything.

<comment><USER6> No problem, and thanks for the frank follow-up.

\--

Regarding the ISP part, I fully agree it would be tough to implement; I was throwing this idea because I had never seen it being expressed and wanted to see if commenters could point to related "prior art" / similar experiments in some parts of the world.

Mainly, my own starting point for the idea is France's (and maybe other countries?) interrupted path to a "Global License" for music [1]. The idea, expressed as a law proposal in 2005 at a time of majors freaking out about P2P, was to (fr.wikipedia translation mine) _" Authorize non-commercial access and sharing of cultural content, in exchange for a proportional artists remuneration."_

It was interrupted in 2009 in favor of a repressive fine system (HADOPI, [2]). But if such a very much pie-in-the-sky idea can make its way to a law proposal (with assorted technical analysis) somewhere in the world, maybe something similar is worth discussing for ads.

[1] (french) [https://fr.wikipedia.org/wiki/Licence_globale](https://fr.wikipedia.org/wiki/Licence_globale)

[2] (english) [https://en.wikipedia.org/wiki/HADOPI_law](https://en.wikipedia.org/wiki/HADOPI_law)

<comment><USER5> Yup a fair point, my initial reply was indeed just shooting down an idea rather than figuring out whether it would work and how could it work if not straight up (criticism vs constructive criticism). I'd be interested in seeing an ISP-level funding scheme, and moreso if enough would be willing to use it that it could feasibly replace adverts. I'll have a proper look into those links too, thank you

Thinking further (or.. at all) the models that flattr but more successfully patreon provide do seem to work and would appear to be the best model if the community you're providing for is willing to use such a system - and they are, in many cases. I can think of a podcast or two that rather than use sponsored messages are funded by their community through patreon. In fact I can only imagine they're earning more and in a more stable fashion for doing so

I'm not sure if an ISP-level funding source would be feasible on the global scale but that may just be my own limits talking, something that definitely works in replacement of adverts is the product (in this example a podcast) being free but with perks for those that want to support the creator directly. The easiest added extras in this example would be behind the scenes, an additional private podcast, archives of episodes long gone by.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> There's already an internet-scale mechanism to avoid seeing ads while ensuring that publishers are compensated for the content they're creating -- it's the very ad exchanges that show us all the terrible ads we see. All you'd need to do is set up a pixel retargeting yourself, match it against the exchanges, and then bid an uncapped amount against it while displaying a blank creative.

Admittedly this won't block 100% of ads, closer to 50-60%, although it would most likely block all of the worst offenders. Likely net cost would be in the $1-$3/day range, distributed amongst the sites you patronize. And, again, all of the infrastructure to do this already exists. You wouldn't need to do deals with publishers or anything like that.

I've always wondered why nobody's created this yet; I've always assumed it's because people using ad blockers would not actually pay for an ad-free experience. Other ideas?

<comment><USER8> I think Adieu ([https://www.adieu.io/](https://www.adieu.io/)) is attempting something like this.

<comment><USER9> Checked out Adieu, it does sound very much like what he/she described.

</comment></comment></comment><comment><USER10> "Given the legal precedents, it's clear that users have the right to try to block ads," he said. "But at the same time, publishers have the right to respond, either by blocking access to ad-block users, or allowing us to help them serve ads in ways undetectable to ad-blocking software."

That's a bit like saying that encrypting a DVD is going to prevent someone copying it. If you reveal something to the user you reveal it to the computer too and then it's just an arms race.It would be better to have a functioning micro-payments system.

<comment><USER11> >It would be better to have a functioning micro-payments system.

There's some things that seem inevitable to me. True flat-rate music streaming services was one of those things and we're pretty much there. Moving away from ad-supported websites to a convenient subscription model is the other.

I don't think the war against AdBlock can be won. How do you disable a software that simply hides content? Force users to click the ads? Put them into more and more annoying places? We already know the endgame of that and it's shady pop-up orgies. I doubt the New York Times wants to be associated with that. But I also won't pay $10 for every single website I might visit a month (some, maybe, for only an article or two in a link).

What we need is a common subscription flat-rate that fairly splits revenue between websites you actually visit. Not sure about the privacy concerns but at least here, the user data wouldn't have to be used for advertising.

<comment><USER12> Agreed. More to the point, it can be argued that if I do not want to consume ads, my browser displaying them means my browser is broken.

This entire thing where your attention is hijacked because you have a passing interest in subject X is out of date. Yes, we've had passive ad sponsorship of all kinds of events in times past, but it wasn't a situation where the advertisers monitored your every move and were aggressively interfering with your content consumption. It was a situation where they wanted to be recognized for supporting the content you were consuming. Ads have gone from being passive, supportive, widespread constructs to being aggressive, directive, in-your-business constructs. Not good.

<comment><USER13> Also agree. It's especially broken on mobile, which seems to be the Wild West of grabbing accidental clicks and seedy tracking.

I don't mind ads. Trackers need to be outlawed. I'll tell an ad service what kinds of ads I'd like to see if they'd like. I don't want to be tracked though.

</comment></comment></comment></comment><comment><USER14> My problem with ads is mainly that they could be used as vector for attacking my machine. Two secondary problems that are not unimportant are that ads sometimes redirect me to other sites while in the same tab if accidentally clicked and can be quite obtrusive. If those two are fixed, I don't minds ads at all when privacy concerns are minimal (anonymous tracking).

<comment><USER15> My problem with ads is they try and sell me things I don't need.

<comment><USER13> Anybody else remember when Google started, we all worried that their ad-based business model would make the web suck? Their argument was that people would _want_ to see ads. Well, maybe 1998 ads, but the problem is that ad-serving has perniciously evolved into what we have now. Which sucks.

</comment></comment></comment><comment><USER16> One way to push ads into a more palatable direction would be to have a browser that goes much farther beyond current ad blocking. I'm thinking closing all 3rd party domain connections after 2 seconds of loading time and/or turning iframes into click2flash-style empty boxes. I don't care so much about ads showing up, but rather the endless cascade of ad-reselling that happens during page loads and makes my phone have poor performance while the page self- flagellates with ad calls. Get your ads in quick or render them on the server or whatever. I feel like something like this (with white lists where necessary) would help people get to a happy middle ground.

<comment><USER17> Check out uMatrix.

</comment></comment><comment><USER18> > publishers have the right to respond, either by blocking access to ad-block > users

All the best with that. The number of sites on which I will have to disable ad-blocker because you won't show the content otherwise is in single digits.

<comment><USER19> Nobody is against publishers blocking access to ad-block users. But if 80% use ad-blocks, you block out your entire audience and let it surf to the competition who figured out how to serve ads that are not making people puke (ie. sponsored stories, endorsements, non-intrusive ads, social selling etc.)

It really is the fault of publishers that people hate internet ads.

<comment><USER20> I think it's the same reasoning with paywalls. I stopped going on pando when they paywalled. I don't see why I would pay to read Paul Carr feuding against the Intercept, the entertainment value is mild, and frankly I would better use my leisure money at the pub or for renting movies.

</comment></comment></comment><comment><USER21> I have never understood this issue. Companies that are supposedly losing millions, and in some cases billions of dollars to ad blockers can't figure out how to randomize ad sizes, links, div names, etc with each page load to the point where it would be impossible for an ad-blocker to deal with it? No footprint, no blocking. It really is that simple.

The issue is more difficult with ad networks, since they always point to specific domains and run specific bits of javascript. But it seems to me that ad networks could simply offer a PHP et al script that publishers could locally host and include in their content that would basically proxy the connection between the user and the ad network. Clickthrough URL's would appear to be on the originating site, like any other content on the site, and the script would forward them to the appropriate site.

I have given this all of ten minutes of thought, and I'm on my way to a solution. I don't buy that companies with real money on the line can't solve this issue.

<comment><USER22> Most companies don't serve their own ads. They sell an iframe reference in a particular kind of page to someone else who runs their own adserver software, so there's a detectable footprint for organisational reasons.

Quite often there's more than one level of resale; I've seen five and a friend who works in the business told me he's seen even more.

(Digression: I have also heard that Ghostery (.com) makes most of its money by telling companies what ads are on their web pages.)

<comment><USER21> I understand the iframe/network issue, which is why suggested a downloadable script that publishers could host that would grab the ad server-side, reference it as a a locally-hosted image or include the text of a text ad in the native content of the page, and send all links to a local redirect script. It wouldn't be that much more difficult for a publisher to roll such a thing out than it is for them to add the iframes or javascript they use today.

<comment><USER22> That approach would be slower (oddly enough the ad people seem to care about performance) and worse, the ad server loses its cookies. When it's on its own domain it can use cookies and track people across web sites.

<comment><USER21> The alternative is that their ads don't get shown, so would you prefer worse or nothing at all?

<comment><USER22> By not using that possible proxy, they give adblockers something to work with, but they also increase the price of the ads they can sell for the rest of the audience.

I wouldn't be surprised if a lot of the recent squealing is really a sanitised form of "the loss from the adblockers has grown bigger than the gains from the increased ad prices, but noone understands our webapp tomcat CRM monster well enough to adapt."

</comment></comment></comment></comment></comment></comment><comment><USER23> I'd love to see something along the lines of Spotify's model for the web. Let me pay a set amount per month, then distribute it among all the websites that I visit, weighted by number of visits (or some other more suitable metric).

Adverts for those not signed into the scheme, a blissful ad-free existence for those who do.

<comment><USER24> Isn't that what Google Contributor is? [https://contributor.google.com/](https://contributor.google.com/)

<comment><USER25> Not totally... They only say you'll see 'fewer' ads. I'm in a similar boat... I'd like to set my monthly amount and that amount be split up among my most used sites, because I do want to support them, but I'm going to continue using uBlock. The entire point is to get rid of ads in favor of something else.

What would rock is if uBlock or Adblock had a subscription service for exactly this.

</comment></comment></comment><comment><USER26> I genuinely hope he will succeed. Adblocking is becoming too mainstream and too easy. Nerds are loosing competitive advantage.

And current ad-blockers are not effectively blocking Adwords, Facebook and other major players. We need something to level the field, to bring smaller players and more innovation.

<comment><USER27> They are also blocked. AdBlock charges the major players to let their ads pass through as "Whitelisted Ads". IMO, that is just plain extortion.

</comment></comment><comment><USER28> Wouldn't be difficult. Especially if you are happy with requiring javascript on your site.

</comment><comment><USER29> how about a feed reader than displays the ads of the source sites, I hate checking a site and there's nothing new but I still get the ad.

</comment><comment><USER30> When reading a lot of the comments from the ad-blocking people I hear this:

"I want to browse every website for free, I don't want to pay for any of the sites that inform me, entertain me, help me to better do my job.

But god forbids if someone touches a cent from my salary..."

In the end it's just a question of entitlement and don't wanting to pay for things.

If you are annoyed for seeing some ads think about the anoyment of the people generating value for you without seeing a fucking cent.

Don't be so selfish, please.</comment>