Ask HN: What are some hacks of real founders who did things that don't scale?
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!
270 comments
[ 2.9 ms ] story [ 289 ms ] threadRecruit new users by manually installing your s/w on their computers by @patrickc” link: http://paulgraham.com/ds.html
What could possibly be 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.
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.
That's the total opposite of what happened to you. In fairness, GP could have been more explicit when describing the approach.
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.
'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
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.
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.
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".
http://paulgraham.com/ds.html
https://www.smithsonianmag.com/innovation/how-palmer-luckey-...
so yep, prototypes are things that people do 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.
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.
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.
However, I haven't read any good journalism actually showing that this is the case.
(yes, we're a long way from there today but fixing that is what I'm working on)
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.)
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.
(Has anyone done this particular sci-fi plot?)
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
The solutions by themselves don't illuminate unless you also illustrate what they were trying to achieve and how they got around the limitation.
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.
(Paid is a YC company, btw!)
EDIT: My apologies for the misunderstanding! I didn't realize that you've already built that functionality from your top comment.
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.
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.
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.)
Worse ideas with smaller markets have been funded by YC. I'm guessing you could have gotten in if you pitched a larger vision.
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!
A marathon is a race ;-)
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.
* 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.
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.
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.
Is your idea different?
Also, the mayo-jar-eating-itself gif in this article is brilliant.
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.
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.
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...
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 :)
- 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
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.
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.
but one needs to know/learn this first, otherwise there wouldn't be an innovation
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!
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.
"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 ..."
We built a network of agrodealers that we use to check people out. It's scaling pretty effectively now.
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... :)
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.
> 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)?
Here's an example answer: https://stackoverflow.com/questions/409999/getting-the-locat...
https://triplebyte.com/blog/three-hundred-programming-interv...
After the first few hires, their engineers all took part in interviewing candidates. That has deferred the scaling problem quite well.
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.
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?