15 ms·

Ask HN: What are some hacks of real founders who did things that don't scale?

539 points by trulykp 8y ago

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!

trulykp 8y ago
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 8y ago
  Borderline unethical.
  - sokoloff 8y ago
    > 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?!
  - nostrademons 8y ago
    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.
- gnicholas 8y ago
  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.
  - graeme 8y ago
    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.
- freehunter 8y ago
  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.
asdojasdosadsa 8y ago
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
- elvinyung 8y ago
  The original blog post from PG talked about that: http://paulgraham.com/ds.html http://paulgraham.com/ds.html
- echevil 8y ago
  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
- sonnyblarney 8y ago
  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 8y ago
    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 8y ago
      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.
Hortinstein 8y ago
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-created-oculus-rift-180953049/ https://www.smithsonianmag.com/innovation/how-palmer-luckey-...
- bsamuels 8y ago
  not terribly uncommon in the hardware world - injection moulds are expensive!
- sneak 8y ago
  Prototypes are not expected to scale; I think OP means things that most would automate.
  - mygo 8y ago
    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 8y ago
      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.
      - lifekaizen 8y ago
        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.
      - mygo 8y ago
LeonM 8y ago
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.
- disqard 8y ago
  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.
  - griffinkelly 8y ago
    x.ai: https://www.bloomberg.com/news/articles/2016-04-18/the-humans-hiding-behind-the-chatbots https://www.bloomberg.com/news/articles/2016-04-18/the-human...
    - dullroar 8y ago
      And this: https://www.bbc.co.uk/news/technology-46055595 https://www.bbc.co.uk/news/technology-46055595?
      - nsenifty 8y ago
        That's just getting data for training isn't it? You can't train AI systems by AI.
        dentemple 8y ago
        Sounds like a new startup idea to me
        8y ago
AznHisoka 8y ago
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.
- Chunkyated 8y ago
  That's interesting. Telegram crowdsourced their own filters: https://instantview.telegram.org/#instant-view-editor https://instantview.telegram.org/#instant-view-editor
- trulykp 8y ago
  Great hack! Thx for sharing
serg_chernata 8y ago
Stripe founders used to do manual implementations for customers in the beginning.
- trulykp 8y ago
  Yep! Famously called "Collison Installation"
iamwil 8y ago
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.
philip1209 8y ago
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.
- infinitone 8y ago
  What does Paidlabs.com do that stripe doesn't? Stripe does invoicing AFAIK.
  - philip1209 8y ago
    When we started in Spring 2017, Stripe did not do invoicing. (Paid is a YC company, btw!)
    - toomuchtodo 8y ago
      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.
seibelj 8y ago
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-startup-ran-undercover-project-to-buy-up-its-own-products https://www.bloomberg.com/news/articles/2016-08-04/food-star...
- findjashua 8y ago
  If this was done to juice metrics shown to investors, doesn’t this constitute fraud?
  - jackcarter 8y ago
    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 8y ago
      That is so unethical. If you want to buy shelf space, be upfront about it.
  - hn_throwaway_99 8y ago
    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.
- lifekaizen 8y ago
  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.
eric_khun 8y ago
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 8y ago
  awesome :) do you take payment in crypto currency?
  - eric_khun 8y ago
    shoot me an email ! eric [[at]] nodablock . com
- jonnydubowsky 8y ago
  This is a great idea! Do you have plans to add other features/integrations?
dwyerm 8y ago
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...
PopeDotNinja 8y ago
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 :)
- atm0sphere 8y ago
  what size (any metrics you care to share) did you grow into?
  - PopeDotNinja 8y ago
    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.
- sanketskasar 8y ago
  Any guidance/advice on how to do this?
  - PopeDotNinja 8y ago
    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
- clay_the_ripper 8y ago
  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!
iagooar 8y ago
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 8y ago
  > 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
replyingtoyou1 8y ago
Andy Rubin used money to “own” many wives, which obviously didn’t scale.
kevin_morrill 8y ago
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).
dclaysmith 8y ago
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 8y ago
  Great story -- thanks for sharing
hkronick 8y ago
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.
- xae342 8y ago
  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.
  - hkronick 8y ago
    did you overcome this? learning to delegate can be challenging!
    - org3432 8y ago
      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.
- trulykp 8y ago
  kudos to you.. how do manage time between all those tasks?
  - hkronick 8y ago
    I have a great technical business partner and we have worked hard hiring the right people so that we can delegate with little intervention.
- andyidsinga 8y ago
estsauver 8y ago
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 8y ago
  Neat project. I wonder if our agricultural borrowers / partners in Kenya should be talking to you.
  - estsauver 8y ago
    I think our partnerships manager is talking with you guys right now actually!
- cimmanom 8y ago
  What was the business you were building, and did it eventually scale? How?
  - estsauver 8y ago
    https://apolloagriculture.com/ https://apolloagriculture.com/ We built a network of agrodealers that we use to check people out. It's scaling pretty effectively now.
    - cimmanom 8y ago
      What a wonderful idea!
- manglav 8y ago
  Hi e :) that's awesome! Seems like things are going well!
  - estsauver 8y ago
    Hey V! It's been a long time since The climate corporation. I hope you're doing well!
killion 8y ago
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.
- cpeterso 8y ago
  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)?
- trulykp 8y ago
  Wow @killion. Legit as legit can be! Thx for sharing your story, will add it to the knowledge base I'm putting together.
- ambicapter 8y ago
  Why is it so expensive to connect to hotel's backends? Is that their fees?
- manoftoday 8y ago
  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.
- ikeboy 8y ago
  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
coderholic 8y ago
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.
- kanon 8y ago
  How did you acquire the customers if I may ask?
  - coderholic 8y ago
    StackOverflow has been a big source of users for us: https://blog.ipinfo.io/i-answered-99-stack-overflow-questions-and-now-2-million-developers-know-about-my-product-502b6b9f1eb3 https://blog.ipinfo.io/i-answered-99-stack-overflow-question...
    - fourthark 8y ago
      You can get knocked for spam if you do that.
      - coderholic 8y ago
        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-location-from-an-ip-address/17864552#17864552 https://stackoverflow.com/questions/409999/getting-the-locat...
        wayoverthecloud 8y ago
        If I may, where do you get the data?
echevil 8y ago
Triplebyte founders started by doing tons of technical interviews themselves with candidates. https://triplebyte.com/blog/three-hundred-programming-interviews-in-thirty-days 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.
- trulykp 8y ago
  Interesting
mherdeg 8y ago
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 8y ago
  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.
Vanderson 8y ago
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 8y ago
  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 8y ago
    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?
DenisM 8y ago
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 8y ago
  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 8y ago
    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.
nickmolnar2 8y ago
Aardvark, the question and answer service that was later bought by Google, initially routed and answered all user questions from their internal team.
- trulykp 8y ago
  Can imagine that :) I wonder how many of Quora's initial questions were internally answered too?
- sundarurfriend 8y ago
  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.
crooked-v 8y ago
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.
txprog 8y ago
Using redis as a main database.
biztos 8y ago
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 8y ago
  I still see Facebook site URLs with .php extensions, so they definitely didn't just throw away their roots.
  - disgruntledphd2 8y ago
    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.
  - Ayesh 8y ago
    I suppose these .php URLs are there to not break old shared/bookmarked links.
    - omarchowdhury 8y ago
      A simple htaccess rewrite ruling can cover handling that, though.
- elwell 8y ago
  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.
andyidsinga 8y ago
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 8y ago
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]
fomopop 8y ago
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 8y ago
  > 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 8y ago
    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.
fomopop 8y ago
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 8y ago
  this is interesting - I'd love to learn more about your experience with a coupon business.
  - fomopop 8y ago
    Send me a message on twitter @jasongurwin
simplydt 8y ago
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 8y ago
  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.
edoo 8y ago
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.
gwbas1c 8y ago
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.
dzink 8y ago
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.
sbilstein 8y ago
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.
JunaidBhai 8y ago
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 8y ago
  FYI your first URL is broken
  - JunaidBhai 8y ago
    Fixed it. Thanks.
Axsuul 8y ago
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.
encoderer 8y ago
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.
jedberg 8y ago
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 8y ago
  > 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
  - jedberg 8y ago
    > 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.
  - acct1771 8y ago
    Yeah, what a sly word to avoid breaking down what's included: "content". Experienced in carefully choosing words =]
    - jedberg 8y ago
      It wasn't sly, OP is wrong. There were no comments on reddit till there were plenty of users to make them.
      - acct1771 8y ago
deleted 8y ago
[deleted]
pryelluw 8y ago
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 8y ago
  How do we get in touch with you?
  - pryelluw 8y ago
    Email in my profile :)
pbiggar 8y ago
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.
deleted 8y ago
[deleted]
wyld_one 8y ago
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
browsercoin 8y ago
The comment section is absolute gold. I may have favorited this thread.
chadwittman 8y ago
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.
lettergram 8y ago
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.
wpietri 8y ago
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.
jeffchuber 8y ago
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!
____Sash---701_ 8y ago
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
andrest 8y ago
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 8y ago
  >> Sounds exciting? We're hiring. Does the position require dog-fooding the product?
  - andrest 8y ago
    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.
bramham 8y ago
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/
cx42net 8y ago
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.
bfdm 8y ago
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.
bonestamp2 8y ago
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.
trulykp 8y ago
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

nostrademons 8y ago
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 8y ago
  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.
philipodonnell 8y ago
> 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".
cromulent 8y ago
Agreed, but "Do Things that Don't Scale" is counter-intuitive enough that PG wrote an essay on it, mentioning AirBNB. http://paulgraham.com/ds.html http://paulgraham.com/ds.html
wnissen 8y ago
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.
- prawn 8y ago
  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.

mr_puzzled 8y ago

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.

philip1209 8y ago
> 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.)
- shanghaiaway 8y ago
  > 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.
  - civilian 8y ago
    "As the Gig Economy hits Tech, ALL TECH JOBS will be performed through Moonlight! Market cap > 4q"
- profalseidol 8y ago
  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.
- anikdas 8y ago
  Surprisingly I never heard back from you guys once I followed up on your email.
  - philip1209 8y ago
    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!

joshstrange 8y ago

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.

deleted 8y ago
[deleted]
halbritt 8y ago
Upvote just because I love Factorio.
jayant123 8y ago
Coincidentally, I just saw this Reddit post yesterday - https://www.reddit.com/r/factorio/comments/9uxeq3/factorio_as_an_exam_for_computer_engeneers/ 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!"
- extragood 8y ago
  "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."
dccoolgai 8y ago
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.
- joshstrange 8y ago
  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.
akurilin 8y ago
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.
- joshstrange 8y ago
  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.
  - akurilin 8y ago
    All yours: https://fs.blog/tobi-lutke/ https://fs.blog/tobi-lutke/
    - joshstrange 8y ago
      Thank you!
  - huxflux 8y ago
    Keep those beautiful SC:BW memories, don't go down that dark SC2-path. At least I don't dare.
wingerlang 8y ago
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.
- akuji1993 8y ago
  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.
- joshstrange 8y ago
  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 8y ago
    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.
Cogito 8y ago
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.

ddebernardy 8y ago
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 8y ago
  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 8y ago
    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.
  - nicoburns 8y ago
    Not sure that google is a good advert for this method. Their products tend to be increibly frustrating to use...
toast0 8y ago
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.
otakucode 8y ago
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).
wpietri 8y ago
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.
blihp 8y ago
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.
badestrand 8y ago
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.

tomjen3 8y ago

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

ddebernardy 8y ago
> 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.
- afarrell 8y ago
  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.

gwbas1c 8y ago

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.

ddebernardy 8y ago
> 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.
- gwbas1c 8y ago
  > 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.