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

Here was our basic workflow:

1\. Marketing site set up using Squarespace

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

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

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

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

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

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

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

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

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

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

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

~~~
wingerlang

        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.

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

~~~
lifekaizen
Thanks for sharing your thought process, I found it interesting.

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

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

~~~
joshstrange
Thank you! I'll check that out

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

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

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

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

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

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

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

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

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

~~~
clay_the_ripper
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!

~~~
bitcoinmoney
7 figure profit or revenue?

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

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

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

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

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

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

------
asdojasdosadsa
AirBnB:

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

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

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

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

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

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

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

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

~~~
krallja
People were emailing you their credit card numbers?

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

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

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

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

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

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

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

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

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

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

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

~~~
blueboo
> 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

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

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

~~~
acct1771
Thanks for the levelheaded correction, m8.

------
lettergram
I created an application which can help people invest:

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

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

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

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

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

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

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

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

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

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

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

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

~~~
imhoguy
> 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

------
trulykp
Here's one popular example:

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

~~~
sidcool
Borderline unethical.

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

------
fomopop
We built the first version of
[https://thestreamable.com](https://thestreamable.com) using Google Sheets.

1\. We used Google Sheets as pseudo database.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
fomopop
Send me a message on twitter @jasongurwin

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

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

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

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

~~~
schappim
>> Sounds exciting? We're hiring.

Does the position require dog-fooding the product?

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

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

------
txprog
Using redis as a main database.

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

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

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

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

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

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

~~~
trulykp
Interesting

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

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

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

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

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

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

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

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

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

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

~~~
trulykp
Great hack! Thx for sharing

------
andyidsinga
We've started an analytics service [1] focused on the operational aspects of
automating analytics for life sciences.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
Axsuul
FYI your first URL is broken

~~~
JunaidBhai
Fixed it. Thanks.

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

~~~
100-xyz
How do we get in touch with you?

~~~
pryelluw
Email in my profile :)

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

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

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

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

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

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

~~~
trulykp
Great story -- thanks for sharing

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

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

~~~
trakout
awesome :) do you take payment in crypto currency?

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

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

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

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

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

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

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

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

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

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

------
jeffchuber
This is a few years ago. Processed thousands of 3d scans manually with a tight
turnaround for close to a year. Finally automated it!

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

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

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

------
serg_chernata
Stripe founders used to do manual implementations for customers in the
beginning.

~~~
trulykp
Yep! Famously called "Collison Installation"

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

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

------
browsercoin
The comment section is absolute gold. I may have favorited this thread.

