Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What are some hacks of real founders who did things that don't scale?
539 points by trulykp on Nov 7, 2018 | hide | past | favorite | 265 comments
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.

What are some of the hacks you have heard or have personally experimented? Thank you in advance!

We prototyped 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.

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.

Coincidentally, I just saw this Reddit post yesterday - https://www.reddit.com/r/factorio/comments/9uxeq3/factorio_a... - "Factorio as an exam for computer engineers recruitment in Japan. If you play the game well, you can get a job!"

"What is the most effective way to mass-produce blue potion, considering the following geographically-distributed resource locations, and impending attacks from several maximum-hostility alien swarms? Assume that bots are restricted to maintenance only. You have 20 minutes to design a scalable solution. Go."

    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.

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.

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) where he talks about the joys of hacking, you might find it interesting.

Thank you! I'll check that out

This thread gives me major anxiety because that's basically how it goes for me too much of the time. Things have got a bit better but I still spend sometimes months reading docs before starting a project (I use tons of diff types of sw though so that extends it a bit)

The programming subreddits and also HN LOVE to make PHP and Javascript look like garbage. In reality, you can still make damn good software with it.

I also love Factorio - it gets better when you play multiplayer and with mods.

I've found, getting back into it, that Project Euler really helps me 'just start coding'. Last time I got into it (around 2014) I would focus on trying to understand the mathematics and solving things by hand. Now I look at a problem or two every few days, and have fairly streamlined solving them.

Breaking the problem into chunks, making sure those chunks work with tests, gluing the chunks together to get the fact needed by the question, running with the specific input needed for the answer, realising the naive way I implemented the solution is way too slow, adding timing information, analysing the algorithmic complexity, reading pages and pages of mathematical theory...

Sometimes it goes off the deep end, but getting some result almost immediately is so useful.

It's the reason Factorio is fun (you can just build it by hand, most of the time) and Excel is used everywhere (you can see the algorithm and its results together, as you build it). It takes a bit of discipline to do yourself, when the gratification loop isn't built in to the tools you're using, and that's why I think Project Euler is so useful. You get short, achievable programming problems that you can solve quickly and build a habit of solving efficiently.

I believe the Shopify CEO mentioned it recently in a podcast, together with Starcraft 2, as one of his favorite games that translate well to skills applicable to startups.

I really need to try SC2, I played a ridiculous amount of SC:BW back in HS. Do you remember which podcast? I'd love to listen to the episode.

Keep those beautiful SC:BW memories, don't go down that dark SC2-path. At least I don't dare.

Thank you!

That and SpaceChem arebtwo games that transfer a lot of skills to the SE space. I need to pick up factorio again, one if the best I've ever played.

Yep, played a little SpaceChem as well and I liked RimWorld a lot (not exactly the same but in a similar vein for me) but Factorio is my favorite.

Upvote just because I love Factorio.

Love it. I wrote a blog post about a subscription notification business I started called Amazing Airfare. I iterated in much the same way - everything was manual, automated things as I grew and scaled and it made sense to. Wrote a post about it here: https://medium.com/@zacharycohn/on-mvps-glueing-things-toget...

Did you guys apply to YC this cycle?

If I signup as a developer, how easy/hard would it be to find a gig? I assume the supply of good developers is not an issue so finding work would be hard.

> Did you guys apply to YC this cycle?

Yes, we applied to YC. We didn't get an interview. I assume that the market size isn't big enough for VC.

> If I signup as a developer, how easy/hard would it be to find a gig?

Contracting kind of depends on how much energy you put in. We've seen smart people not try that hard, and get zero gigs after 20 applications. On the opposite end, professional contractors who give thoughtful applications get many jobs at high hourly rates.

Moonlight can only net increase your job flow. If you are in need of contract work, you can always email us (team at moonlightwork.com) and we'll manually coach you on improving applications, and make warm intros to clients. (We have had success doing this manually over the past month, and are contemplating on turning it into an automated "I'm available right now" flow in the product.)

Can somebody who's worked with legacy J2EE applications get a gig? All the buzzword right now is fullstack react/angular + lots of tools to make javascript development scale. Most of my recent experience right now is stopping/starting JBoss and figuring out how to sneak in yet another feature into a 15 yr old java codebase.

> Yes, we applied to YC. We didn't get an interview. I assume that the market size isn't big enough for VC.

Worse ideas with smaller markets have been funded by YC. I'm guessing you could have gotten in if you pitched a larger vision.

"As the Gig Economy hits Tech, ALL TECH JOBS will be performed through Moonlight! Market cap > 4q"

Surprisingly I never heard back from you guys once I followed up on your email.

Hi - I don't see any messages from the email in your profile. Reach out to me at philip at moonlightwork.com if you have any questions!

That is a great story of grit! Love it, thanks for sharing.

Thanks! We're approaching the 2-year anniversary of starting Moonlight. That's a long time to work on a business!

It's been a long journey to understand what customers want. I think that a subscription product is our future, and we didn't figure that out until last week! But, we even tested that manually - and, in doing so, have done more net revenue in the previous seven days than we did in the first year of our business.

We've fortunately been ramen profitable this year, but I hope that in 2019 we can start to focus on growth!

I'm sorry to say but 2 years is not a long time when starting a business. That's just getting started. It's a long road. The fact you are profitable is great, but it's a marathon not a race.

I definitely agree! I more refer to the fact that we have not yet hit the turning point of clear product/market fit after two years.


A marathon is a race ;-)

Very similar for my business’ various pivots. When you don’t have seed funding, this feels like the ONLY way to go.

Wanna use https://wakatime.com to automate 7, 8, & 9?

Hi All, I want to start something similar and I have a list of around 175+ Good Remote developers from around the globe who are looking for Gigs. I am currently looking for a US Based partner who can oversee getting client proposals. My email is in my bio.

Toptal does a pretty good job packaging/marketing remote devs to US based corporate clients...>https://www.toptal.com/

Is your idea different?

What does Paidlabs.com do that stripe doesn't? Stripe does invoicing AFAIK.

When we started in Spring 2017, Stripe did not do invoicing.

(Paid is a YC company, btw!)

Do you plan on continuing to use Paid? Or will you migrate away to Stripe's invoicing?

EDIT: My apologies for the misunderstanding! I didn't realize that you've already built that functionality from your top comment.

We built invoicing into our product!

One of our technical needs was auto-charging clients for overdue invoices that were neither approved nor disputed. That's application logic, not something we can use an external system for.

Why does your website ask to autoplay sound on firefox?

It could be that chat system in the bottom right? Maybe it makes a notification sound?

Ah, that could be it. It's intercom.io - which is fairly ubiquitous on the internet.

No idea - I'm not seeing this on my end. Can you email us (team at moonlightwork.com) and we can debug?

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.

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).

That's a great example of manually bootstrapping an automated system!

> We are directly connected to hotels now

Once you implemented the backend connections, was the quote of "tens of thousands of dollars" accurate? Was that your development cost or some access fee required by the hotel (or their booking system provider)?

That sounds like a really good idea for testing out an idea. But im wondering - how did you go from this MVP to an actual product, when you were busy manually answering emails. How did you find the time? Advice is appreciated.

Why does it cost so much to connect to their backends? Aren't there platforms which they load their inventory on like Cloudbeds etc? I assume most of those would be modern enough to have web services to integrate with?

Why is it so expensive to connect to hotel's backends? Is that their fees?

I'm not sure this doesn't scale. I assume you made enough on a reservation to pay for cheap third world labor to do this at scale

Wow @killion. Legit as legit can be! Thx for sharing your story, will add it to the knowledge base I'm putting together.

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.

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.

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.

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.)

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.

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.

Not sure that google is a good advert for this method. Their products tend to be increibly frustrating to use...

Your comment makes me think of one of the saddest tragedies of software development that bit me in the past. Ages ago I used a 'shareware' (thats what it was called back then) FTP client called BulletProof FTP. It was magnificent. It performed its task marvelously well and only had one bug I was aware of that ever caused me any trouble.

Then they kept working on it. With every version, they bolted on some extraneous garbage that made the rest of the application worse and worse. MP3s were popular, so they added searching FTP sites for MP3s... something that I find hard to imagine any human being ever did or wanted to do at any point. I eventually just had to stop using it, they made it far too aggravating. And they never even fixed the bug (after a disconnect, it would use the random port previously used for a data connection to try to establish a command connection and if the reconnect had been quick enough, the server would still be spewing binary data into what the client expected to be a plaintext connection, resulting in random garbage).

I am suspicious of your division: "complainers" and "majority who never has issues".

I agree some people are born complainers, and you should not implement things mentioned by just one user or one especially noisy user. I also agree that support requests shouldn't be the only way one understands users. But I suspect there are very few improvements valuable to people who don't contact support that would never be mentioned by someone who does.

To me the people who contact support with suggestions aren't just the most irritating fraction of your user base. They're also the most dedicated users. The ones who love your product the most. The ones who are doing something you didn't expect because they are an early adopter in a different market. The new users that you'd like to have more of but won't until your product is easier to learn.

The expectation here is not for engineers to see requests that can be handled by the frontline support team. And when you have a sizable number of people asking for features you don't want to build (for a good or bad reason), you can pretty easily turn that into something that the frontline team (or their automation) can come back with:

"Thank you for your suggestion. This is a common request" and then "but we're not planning to build it for [some reason]" or "we're considering it for the future". Depending on if you want articles about how dumb your reasons are, or articles about how you promised you were working on it three years ago, and it never happened.

Presumably, that's why you still have at least level 1 support: make sure they are able to filter out the noise and get 'real' issues sent to level 2. (aggregation can be part of the filter for complaints/feature requests that aren't bugs)

There are other ways to accomplish it, but the basic idea is to never let product development get too far removed from the actual customers. Large companies can get away with not listening to the customer (for a while at least), smaller ones not so much.

I think improvements for products can be devided into positives (e.g. brings value, new features) and solving frustrations (bugs, slow speed, bad UX, etc). By listening to all user complaints you can almost complete eradicate frustrations - which makes your product fun to use and can massively reduce churn.

I've always found it easy to see the whole system, and how it looks to others. (Ironically,) I can't understand how most engineers don't, and get annoyed instead.

I once spent a couple of weeks working out how to give helpful error messages in the yacc parser of an open source project, for issues that arose repetitively, annoying the maintainers... but it was ignored. They are still getting annoyed by those issues to this day. And I'm still annoyed about it.

Same here! I figure there must be places that apprecuate this kind of thinking. So now I'm focused on only working in those kind of placea.

That assumes the engineers can prioritize the tasks and can't just get the list of frequent issues from support.

Also it assumes that the engineers don't find a better way to deal with the support questions, such as canned "answers".

> That assumes the engineers can prioritize the tasks

It doesn't. If the product manager is prioritizing things, he or she invariably gets backlash from the engineers when they put forward that they're swamped and can't deliver unless they deal with X, Y, Z first.

> and can't just get the list of frequent issues from support

Which are then, all too often in my experience, ignored or downplayed by whoever prioritizes tasks over at engineering.

When the engineers have skin in the support game, they pay extra attention to what may or may not lighten their "not very fun" workload.

No, this strategy really does depend on the engineers having a good way to prioritize things.

If you have engineers doing level-2 support and you have product managers saying "Do this other thing", then the engineer now repeatedly has to resolve a conflict among the possibilities of:

A) Check email and slack to see if something new has come in.

B) Check your error reporting/monitoring to see if Sentry has reported any new exceptions/errors from existing services.

C) Issue #1 from a customer

D) Issue #2 from a different sort of customer who has more revenue impact

E) Issue #3 which was actually bubbled up from someone in sales.

F) Non-urgent but important Project X from the product manager which you are actually 30% of the way finished with and consequently, it is the thing that is sitting in your brain.

G) Check hackernews as a salve to the stress of a bunch of ambiguously-prioritized tasks.

Accomplishing engineering tasks requires allocating your brain's working memory and directing your focus on ONE thing at a time. The harder that is, the harder it is to do anything but option G.

If you put engineers in this situation, but you don't give engineers the training and structure to arbitrate decisions about prioritization, then you're setting them up for needless conflict and failure. If you just designate all of your engineers as being responsible for level-2 support without any additional structured then each one needs to tell the product manager, "I'm not going to work on this project which will bring the company $X Monthly Recurring Revenue for another week, but I'm going to deal with these support requests. I am in charge of prioritizing what gets worked on. Your job as a product manager is not to decide priorities."

Which is a silly thing to tell a product manager. There should be an existing consensus around how this sort of thing is handled and prioritized. If your product managers aren't allocating time for fixing frequently-encountered bugs or UX problems, then the solution isn't to set them up for a conflict with engineers. The solution is to have someone exercise leadership of the product managers so that they is alignment on the general importance of getting bugs fixed quarterly goals and so that when someone (PM or engineer, whoever is triaging level-2 support queries) exercises judgement about the priority of a bug relative to other work, others broadly agree on that decision.

You need to have some structure accomplishes this.

That requires a good support team that follows process.

It falls apart when support doesn't train newcomers in what engineering needs, or when support just "throws things over the wall" to engineering.

I once worked with a very bad "director" of support who couldn't figure out that a customer was sharing something to the wrong email address. She did absolutely no diagnostics. When I called her on it, and explained that she couldn't throw everything over the wall to me, she quit the next day. Her replacement was much, much better.

> That requires a good support team that follows process.

> It falls apart when support doesn't train newcomers in what engineering needs

It requires as low skill level from support as you can get. Some rudimental diagnostics skills and understanding of the product itself are needed; from there, if it's not in the FAQ, let engineers handle it in full.

One of three things then happens - in my experience, anyways:

* The engineers prioritize fixing the stuff they don't want to repeatedly deal with.

* The engineers populate a FAQ for the stuff when it's low impact enough that they're OK with support copy/pasting the FAQ item until they address it - if ever. Which can lead to further questions that get fixed or expand the FAQ, but that's fine too.

* (In rarer cases) some of the engineers quit because they think support is beneath their pay grade.

> It requires as low skill level from support as you can get. Some rudimental diagnostics skills and understanding of the product itself are needed; from there, if it's not in the FAQ, let engineers handle it in full.

Management has to enforce that tickets aren't thrown over the wall. I can't count the number of times that your approach is misinterpreted as, "I don't need to know much about the product or try to understand the customer's problem and communicate it correctly."

Anyway, without support that takes pride in, well, support, it leaves customers very unsatisfied.

Wow that takes some serious gumption!

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 :)

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!

7 figure profit or revenue?

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.

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.

Depends on your margins & efficiency. I was charging $100/hr & paying $20-$30 (which wasn't a secret to anyone, clients or employees). But it was hard to save because I needed automation I didn't have, and paying for it was not tenable for internal reasons. Eventually I sold my stake for a modest amount and became a software engineer. I decided I wanted to have the option to automate.

There's a lot of weird conventional wisdom that is all based around the hypothetical VC lottery ideal: grow a business from nothing into a multi-billion dollar "unicorn" in a handful of years, and reap massive RoI for the investors in the process. This is great if you're a VC investor but it's often harmful for everyone else. You don't need a billion dollar startup to be financially secure or to have a robust and rapidly growing business.

To add to this, you have to figure out if it really won't scale, or if the specific individual you're talking to just doesn't know how to scale it. Are they the right person?

I had the option to scale more, but I chose not to. It was more work than I wanted to do, and perhaps more than I could do. I decided to cash out instead.

Service businesses definitely scale. See Accenture, WPP.

Could you hint at your market? What business are you in? I think I get your point about the workflow being "teachable". I am unsure it's generalisable. I'd love to hear more if you fell like telling. Marco

Any guidance/advice on how to do this?

Here's part of the path I took:

- Pick something you really wanna do

- Sell something with big fat margins

- Don't run out of cash

- Go where the customers are

- Don't outsource your critical path to anyone ever

- Figure out what customers want to spend money on but can't

- Figure out how to get customers to pay you in advance for work you haven't done yet

Service businesses get told they can't be scaled all the time. Thanks for proving it can still work!

I'd call it offering hope, but I'm glad you sound inspired :)

what size (any metrics you care to share) did you grow into?

I grew from just me, my first $5K customer payment, and a checking account overdrawn by $1K to 15 people & doing ~$100K USD/month in about two years. Funded entirely from cash flow.

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.

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.

...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?)

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

I pitched a local language startup idea to a few companies. I was summarily tolf that it didn't have any "zing" to it. So I added "AI" in all my pitches and got a lot of interest.

Didn't pursue the idea further because I didn't really believe in it, but it just proved to me that investors often chase buzzwords instead of ideas

There are a few of these already - Mechanical Turk is the most famous.

https://testzap.com does exactly that for app testing, although there are few products in market claiming to do AI based testing.

There was an article on here like two days ago about a company in Kenya that does training sets for big tech. 1000s of people marking cars on pictures etc

That reminds me that in an AWS conference a few years ago, the presenter touted Amazon Mechanical Turk as "Artificial Artificial Intelligence"

AI: Artisanal Intelligence

I like to call it "aggregated intelligence", because that's what basically all AI solutions really are. Even ones that are actually using embeddings & CNNs are just aggregating the opinions of the thousands to millions of humans who supplied training data.

That's a good name. It contrasts pretty well with the 1970s' paradigm of "expert systems"—where you were encoding the opinions of one human, or the consensus opinion of a conference room full of humans.

I like “Artificial Artificial Intelligence”.

I'm not trying to undermine you, but can you share a link or source? I too, have a vague feeling that many "AI Startups" are trying to ride the buzzword train, and actually doing their work using humans.

However, I haven't read any good journalism actually showing that this is the case.

That's just getting data for training isn't it? You can't train AI systems by AI.

NIs train NIs, so in principle why not?

(yes, we're a long way from there today but fixing that is what I'm working on)

A human baby can't learn to walk by having it demonstrated to them; they actually have to try walking themselves. (Though maybe this would be different if adults were shaped exactly like babies, and babies could understand speech well enough to parse a description of the process of walking.)

Heck, even after we learn to talk and read, we still don't learn to write by having it explained, and only vaguely learn by demonstration. We mostly just learn by generating outputs and having them evaluated by the other NI (sort of like how AlphaGo Zero works.)

Sounds like a new startup idea to me

I just saw this and came back to HN to share it :) Thanks!

Thank you for sharing this.

This is 100% true. So, so, so true. In actuality, A.I. will not ever 100% solve all problems and some sort of human intervention is typically needed to serve as a QA purpose.

AI can get you 80%, 90%, 95%, and 99% of the way to solve a problem. When you first start out, a human element will be doing most of the heavy lifting and creating training data for you. As you iterate on the model and improve it, the human intervention element will be less and less time consuming over time. As you near 100% accuracy, you will probably still want a human intervention element acting as QA because all models have some rate of error.

You can use the model's output probabilities to optimize QA routing - any cases with less than 90% confidence to humans but save humans doing the cases that can easily be done by models :)

seriously how do people get away with such things legally? this is total fraud


'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]


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.

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.

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.

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 - other 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.

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.

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

It seems straightforward, but the alternative would have been to establish a network of local photographers with contracts and agreed rates, scheduling software, performance management, QA, etc...

That would be more scalable, so if you just do it yourself instead of going for scale its a "hack".

Agreed, but "Do Things that Don't Scale" is counter-intuitive enough that PG wrote an essay on it, mentioning AirBNB.


I am surprised that they have not kept up with the professional photography, though. Who is going to be the guinea pig to book a property with 6 blurry photos in a foreign country? It's a waste of everyone's time: host, guest, and AirBnB approving the listing. One time I saw a listing for a shared room in Paris that had one picture containing only a bed.

They do still offer it to the better options on their service. Often the ones without pro photos are new or not popular. I think they can make the assumption that if an owner won't put in much effort with their own photos, they won't make a very attentive host. It's trivial to take average photos, ask a friend for help, trade accommodation with a photographer or even pay for a professional.

Interesting! I think it could be scalable even at much bigger scale -> Hiring more professional photographers to do that as the company grows doesn’t sound like a terrible idea. Just like Google having tons of people driving cars around cities to create content for street view

The original blog post from PG talked about that: http://paulgraham.com/ds.html

I didn't build out an account page for 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.

People were emailing you their credit card numbers?

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.

How did you acquire the customers if I may ask?

StackOverflow has been a big source of users for us: https://blog.ipinfo.io/i-answered-99-stack-overflow-question...

You can get knocked for spam if you do that.

Only if you're spamming, and not actually answering questions with a useful solution while declaring your affiliation.

Here's an example answer: https://stackoverflow.com/questions/409999/getting-the-locat...

If I may, where do you get the data?

How long did it take to get 500 customers?

3 - 4 years.

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.

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.

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?

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

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.

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.

You're literally the first startup I know that sells tons of shit at scale, for which this is a positive description :).

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

I think our partnerships manager is talking with you guys right now actually!

It's ok, this is the internet. You can say that you literally schlepped tons of shit for your customers. :)


Fortunately for us, it was DAP (planting fertilizer) and CAN (topdress fertilizer). The nice thing about Kenyan agriculture is that most farmers, if they have a cow, already are making sure to use their manure. The bad news is there's not nearly enough cows making nearly enough poop in Kenya to provide the nitrogen the crops need. We're literally shit out of luck... :)

What was the business you were building, and did it eventually scale? How?


We built a network of agrodealers that we use to check people out. It's scaling pretty effectively now.

What a wonderful idea!

Hi e :) that's awesome! Seems like things are going well!

Hey V! It's been a long time since The climate corporation. I hope you're doing well!

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.

> 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

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

That's not correct. There were no comments on reddit for a long time. By the time we launched comments, there were plenty of users to make them.

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

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

Thanks for the levelheaded correction, m8.

I received a tour from u/alienth when I dropped by the Wired office in 2012 on a cross-country motorcycle trip. I appreciated the visit!

I created an application which can help people invest:


It's really just a demo of platform which creates a knowledge graph in any network: 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.

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.

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 ..."

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

Did you fail somewhere before reaching the actual milestone? What would you do differently? And what was your biggest mistake/failure while founding ordermetrics?

This was a pain for me too, despite having nearly 60 employees they were all new to the problem domain which left me and my co-founder still wearing way too many hats.

did you overcome this? learning to delegate can be challenging!

Mostly yes, it came to a point where the teams had enough understanding to be able to make a mistakes that impacted customers without them jeopardizing the whole company. Bizdev and sales are a WIP still since it's a niche industry.

kudos to you.. how do manage time between all those tasks?

I have a great technical business partner and we have worked hard hiring the right people so that we can delegate with little intervention.

thats an interesting product!

Thanks, Andy!

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).

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.

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.

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.

> 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

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

Someone cajoled me into installing his startup's app on my iPhone when I met him at an alumni event. His pushiness was off-putting, and I had zero interest in the app (which I deleted that night).

TBH, even if I had been somewhat interested in the app, I would have been inclined to uninstall, just because I don't approve of this tactic.

In the Stripe example, the prospects had expressed strong interest in using Stripe, during the conversation. So the founder said "great! I'll set it up for you right now"

That's the total opposite of what happened to you. In fairness, GP could have been more explicit when describing the approach.

I used this to close a sponsorship deal the other week. I had been talking to this potential customer for weeks at this point, and every time their answer was "we really want to pay for a sponsorship but just haven't had the time to go online and pay for it yet". So I asked "what if I do the paperwork for you and you just have to type in your card number"? She handed me her phone and went to grab her credit card. By the time she came back I was at the payment screen and the deal was closed on the spot.

That one deal tripled our YTD revenue, and opened my eyes to the fact that my sales process was far more complicated than it actually needed to be.

Borderline unethical.

> 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?!

The Collison technique is that you ask people if they want to use your product, in person, and then set it up for them if they say yes. Nothing unethical about that.

I'd heard that one technique another startup used was to go to all the local Apple Stores and set the home page of Safari on each computer to their website. That seems borderline unethical, but that's not what Stripe was doing, nor would it really work for their market.

We built the first version of 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.

> 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?

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.

1. Wrote and optimized DreamList 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.

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...

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.

Facebook still uses PHP heavily. Technically it's a language called "Hack" (PHP augmented with some nice modern features), and runs either on HHVM (JIT: PHP/Hack -> C -> binary) or precompiled to binary.

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

Facebook just kept building compilers:

2004: PHP is quick, let's use that.

2006/7: PHP is slow, let's build a compiler for it (HipHop)

2010/11: Still slow, let's build a VM and compile to assembly (HHVM)

2012: types are cool, let's build an oCaml parser to pretend they exist in PHP!

I kinda view it as Zuckerberg profoundly agreed with the never rewrite code theory.

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

A simple htaccess rewrite ruling can cover handling that, though.

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.

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

Send me a message on twitter @jasongurwin

At 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.

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.

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.

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.

>> Sounds exciting? We're hiring.

Does the position require dog-fooding the product?

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.

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.

Using redis as a main database.

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.

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

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.

Triplebyte founders started by doing tons of technical interviews themselves with candidates.


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


Not a success by any means yet but I got my first 10 customers for Trunk (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.

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...

To me, this is a different thing. I think most founders would say things that don't scale are hacks that let them go faster, but cause extra work on the back-end or a higher unit cost. The upshot is speed to revenue or product-market fit, and if you don't find that then you don't need to waste time building the thing. And these subsidies can go away eventually with product improvement.

The Mayo story seems like something else. While you might learn something by buying the product in retail once or twice, buying in bulk to simulate demand isn't an acceleration to learning something. It's this thought that if only people could find my product, or have an easy way to buy it, it will sell. But once you stop buying, the effect goes away. It reminds me more of a dilemma that larger companies talk about: juicing this quarter's earnings at the expense of next year's.

If this was done to juice metrics shown to investors, doesn’t this constitute fraud?

Yes, of course the probability of suffering negative consequences of this basically depends on if you "make it" before your "fake it" is discovered.

Also, the mayo-jar-eating-itself gif in this article is brilliant.

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.

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

In a similar vein,

As a teen at my first job, we would prime our tip-jar with a dollar bill from the register in order to jump start tips.

You'd be amazed at how well that worked.

Should have primed with $10s instead!

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.

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

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.

Great hack! Thx for sharing

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/

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]

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

man that was something!

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

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

Aardvark was a nice service, both for finding answers (a well-managed online "word of mouth" service), and for finding surprising intersections in interests with your acquaintances.

We (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)

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.

FYI your first URL is broken

Fixed it. Thanks.

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.

How do we get in touch with you?

Email in my profile :)

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.

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, 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.

I'm currently the only Customer Success Manager for our bootstrapped Customer Success Management startup Akita --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!

Great story -- thanks for sharing

Technical co-founder (VoiStory - 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.

On a "DoThingsThatDontScale" mode now for 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)

This is a great idea! Do you have plans to add other features/integrations?

awesome :) do you take payment in crypto currency?

shoot me an email ! eric [[at]] nodablock . com

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


not terribly uncommon in the hardware world - injection moulds are expensive!

Amazing. Talk about "making it happen"!

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

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.

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.

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.

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.

You can go for the other paradigm, however, which is more like hand-building each one, but could be thought of as a high-quality prototype meant for sale. It's much more expensive per unit, but you learn every time, and hey no tooling cost! Boosted Boards is the best example I can think of.

Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact