February 17, 2020

What strong opinions do you have?

Team Indie Hackers @TeamIH

We're all allowed to think and approach things differently.

What opinions, ideas and philosophies do you currently have?

  1. 20
    • Never rebuild. Refactoring is always a better business decision.
    • Use boring, reliable tech. Until you actually need the performance gains of cool new stuff and you have the money to hire someone to learn it, chasing trends is a waste of time.
    • Learn marketing. If you're a solo founder, spend half your time on marketing/sales, and don't expect a magical non-technical founder to fall into your lap.
    1. 6

      I (almost) completely disagree with your first two claims.

      Use boring, reliable tech. Until you actually need the performance gains of cool new stuff and you have the money to hire someone to learn it, chasing trends is a waste of time.

      6 of YCs top 10 successes ever were built on Ruby back when it was cool. One could make the argument that Python was still pretty trendy and cool back when Dropbox, Reddit, etc were using it, too. Not only that, but of YC's newer successes, a disproportionate number have chosen to work with relatively new stacks.

      I think you're right that chasing trends is a waste of time but if a newer tool offers more productivity in the hands of an expert, then a tiny startup is exactly the place to use it. Bigger companies are locked into their prior choices and can't easily switch.

      Never rebuild. Refactoring is always a better business decision.

      I've had great success with rewrites. In particular, having parachuted into a few projects that were in terrible shape, it's often better to just blow it all away and write it from scratch if possible. Similarly, since reading this pg essay, I've taken to re-writing my own code when I have the time and it's definitely paid off in the long run.

      1. 1

        If you're going the YC route, chasing funding, and hiring a big engineering team, you might have the resources to use cutting edge tech and rewrite it whenever you want. I've seen plenty of startups do this.

        That doesn't mean it wasn't a waste of effort though.

        And if you're bootstrapping, that wasted effort is a heck of a lot more painful.

        1. 1

          Why do you assume that "boring" tech will be easier? Would Stripe have been more productive if they'd used PHP instead of Ruby? Would Airbnb have gotten off the ground faster if they'd used J2EE? If so, then would they have been even more productive if they'd used something even older like C++... or Fortran?

          IMO languages and frameworks have been trending towards greater productivity and that productivity gap is why people keep moving from older technologies to newer ones.

          1. 1

            Older languages are also trending towards productivity. C++ and Java have changed dramatically in the last few years, though not as quickly as some of the trendier languages, because they tend to do something once it is tried and true and has a very well thought out solution. I love writing in modern C++, and you get some nice power out of the box with a vast collection of libraries out there for all kinds of stuff.

            But to be fair, I very much prefer Kotlin to Java. And there are some very nice syntax benefits to Kotlin vs C++ etc.

        2. 1

          What if it isn't a waste of effort though? What if the tech choices they made give them the advantage they needed to be successful?

          Chasing trends is a waste of time, I give you that. But there's more to it, there's often a reason why a new piece of tech is becoming trendy. Sometimes those are bad reasons (MongoDB?), but sometimes there are great reasons (React). People build new things to try and solve problems they're having, it baffles me a little how even people in the maker community often disregard that. Just because you don't have the problems that the new tools are trying to solve doesn't mean people shouldn't be using those newer tools.

          1. 0

            ANYTHING they built on Ruby they could've also built on other backends and ANYTHING React can do jQuery can too

            1. 3

              But that's trivially true and meaningless. No one's arguing otherwise. Yes, any problem can be solved in any language as long as it's turing complete -- so why don't we all work in brainfuck? Because some languages are more productive than others. And for writing large SPAs, React is more productive than jQuery. What do you think?

    2. 2

      +1 for #3, but don't get too crazy with spending time on optimizations. I'm product oriented and went to some marketing events to learn some techniques. I was blown away about how much mental energy and time is wasted tweaking things to possibly gain such tiny improvements, while adding no value to the product itself.
      Obviously, the same could be said for design or development, but save these types of optimizations for mature products that are past the rapid growth stage.

      1. 1

        So true.

        It's so easy to get data now that a lot of new marketers don't stop to think if that data is actually meaningful or useful yet. In other words, you can't run a meaningful A/B test when you get 100 visitors per week to your website.

        I've found that big company marketers get jazzed about those kind of 1-5% lifts, but if you're in an early stage company, you need results in the 50%-100% improvement range or else it's not worth it.

        You don't have to do everything. I like the idea of finding 1-2 channels that work profitably, then exploiting them for all their worth.

        1. 1

          My first career was in mass manufacturing - multi-year, multi-million dollar projects and getting a 5% cost reduction was a big deal. Then I went to discrete fabrication where the time frames and sale prices were much lower, and the products were customized. So it wasn't worth chasing such small gains - just get more sales. A totally different mindset.

    3. 2

      I strongly agree with 2 and 3. I am on the fence with the first one, as I think it depends on the project, most importantly on the complexity. If the number the features you are planning to add is larger than the number of features that are already implemented, you might want to consider rebuilding if the outdated codebase makes it really hard to add new features.

      1. 2

        Rebuilds don’t work well when you have competitors. While you are rebuilding your product, your competitor is spending more time on either new features that customers want or change the product to fit customer needs. From a business standpoint, that’s a big no-no unless you have millions in funding to have multiple teams.

        Rebuilds always sounds great but with enough complexity, most rebuilds either fail to finish or become the next spaghetti code base. Most programmers don’t realize time constraints are what cause the problem in the first place. If the source of that never change, a rebuild won’t change the outcome.

        A better approach is to think deeply whether features solve a customer problem. If not, cut it from the code base and try to reduce the amount of spaghetti code.

        1. 1

          I am a bit biased, as I did just rebuild the entire frontend of my app instead of refactoring, but I'm really happy with the result.

          While you are rebuilding your product, your competitor is spending more time on either new features that customers want or change the product to fit customer needs.

          Yes, but you are not wasting time. I assume the rebuild is happening because of a limitation or the speed at which features can be implemented, not just because you want to. Also by rebuilding you can usually bring in huge performance improvements or market disruptance quality. You also save yourself time for new features (in the future).

          Most programmers don’t realize time constraints are what cause the problem in the first place. If the source of that never change, a rebuild won’t change the outcome.
          I agree. It's either the programmers are a lot more experienced now (were newbies at start) or the codebase is a legacy codebase written by someone else.

      2. 1

        Interesting. I actually think the complexity of the project means it's an even better idea to refactor over rewriting.

        I say this because large, sprawling, messy projects often have a lot of "hidden features" that business people know about, customers use, but you may not get in any design spec. I have successfully done module-based rebuilds though where we used the old app as a data source and slowly replaced each page/UI flow with a new app using some kind of proxy in front of it to gradually shift traffic over. It sounds complicated, but again, it prevents us from nuking a ton of functionality that customers care about that we don't know about.

        I'd only go for a rebuild if the company were changing markets/customers completely. Even in that case, it only makes sense if we know we can remove lots of functionality, and we can stop supporting the old app completely. Otherwise, I'm firmly in the "refactor at all costs camp".

        1. 1

          "hidden features" that business people know about, customers use

          Exactly, it’s a business risk because to the customer it’s not a bug but a feature. I’ve heard of some smes go down because of a rebuild. Customer gets frustrate these hidden features don’t work anymore and UI changes (most rebuilds include UI changes) means they need to relearn to do the same things. At that point, customers are usually looking at your competitors because who knows when you will do a rebuild again in the future.

    4. 2

      I agree with no 3 so hard... you have no idea.

    5. 1

      +1 for using boring tech. The devil you know is almost always better for your money-making stack. If you want to play with the new and shiny, save it for the parts that aren't mission critical; this way, the inevitable rough spots won't derail your main focus.

      The caveat here is that boring means something different to everyone: your boring tech stack might be cutting edge for me and vice versa.

    6. 1

      Agree with 2 and 3 but I would generally disagree with the first.

      For a large monolithic project with thousands of man-hours in it then rebuilding may not be viable and, as a result, you may find yourself working with out-of-date or unsuitable technologies with no easy upgrade path.

      This also relates to what you say about boring, reliable tech: I have seen (and built!) many projects using flavour-of-the-month technologies which become a pain to maintain after a couple of years.

      In an ideal world I would architect a project in such a way that its components can be individually rewritten without impacting the project as a whole (using largely boring, reliable tech).

    7. 1

      Refactoring is not always the best solution. Some code bases are rotten to the bone. Spare yourself the headache.

      Boring reliable tech has its fair share of problems too. Sometime using what everyone has been using for years goes in the way of modeling your domain properly. I'm not saying "jump to the newest shiny thing" but doing the same thing like you always did is not always the best solution.

      I 100% agree with the third point.

    8. 1

      I would disagree on 1. Sometimes. The old code has to be built in a way that allows for slow replacement. Otherwise, it would be a huge pain. Of course, the times I have rebuilt things, it was due to fundamental changes to how it worked.

  2. 10
    • A landing page to capture email addresses is not an MVP (is that unpopular?)
    • You need to actually build the thing to see if people want it
    • Its ok to not charge money on day 1
    1. 2

      +1 for #1, a landing page is not a product, someone can't use it to derive any value or pay you for a service etc. (Edit: if you're getting credit card numbers from your LP then you're a boss.)
      I had a startup mentor trying to push this on me 4 years ago when I was starting to productize my already successful consulting business. It really didn't make any sense for me as I would be going backwards.

    2. 1

      I am often disappointed by landing pages with only email addresses. I mean at least add a demo video, explanation graphic, etc.

    3. 1

      Thank god, I am tired of seeing that lmao.

      I agree with all three of these.

  3. 7
    • Not testing your code gives you the illusion of velocity. Tests force you to apply Lean principles and check what you really need before doing it.
    • You might like no code tools but you don't own your business logic with them. You are tied to a platform and they can shut you down if they want. In this case you will have trouble putting your product back on.
    1. 2

      definitely agree with #2.
      not sure if I agree with #1 or not but I'm definitely guilty of lacking tests!

      1. 1

        My 2 cents about testing: when you know how to write short tests that help you make your app work and avoid regressions, then it's faster to play your tests than alt tab to your browser constantly to check if everything works fine.

  4. 7
    • Don’t take yourself to seriously.
    • Work hard but most of all Have fun.
    • if it’s sounds like easy money it isn’t.
    • find a problem you love not an idea
  5. 6

    SPAs are not a good tech choice for small teams.

    1. 4

      I have found good old html and JavaScript works great and customers don’t really care. Your customers are unlikely to be tech savvy and all they see is a screen. To them there is not much difference between spa and plain old html. It’s the information on the page that matters.

    2. 3

      I've found that SPAs (particularly Angular) do a lot of heavy lifting for me and make my life easier.

    3. 3

      My product couldn't be built without a SPA framework. What should I do?

      1. 1

        If you can only implement a specific feature with one then by all means go for it, I'm not your mum! ;-)

        It's probably fairer to amend my original comment to "SPAs are not a good [default] tech choice for small teams", but if you know why it doesn't apply to you then you probably don't need to get opinions about SPAs from some guy on the internet.

        (I'm guessing it's something related to media streaming?)

    4. 1

      Could you elaborate or drop a link for more reading?

    5. 1

      Why is that?

      1. 2

        Unless your app requires no reloads to function, it's pointless overhead. You introduce build tool dependencies, and re-implemented browser APIs. The vast majority of web apps are just a series of forms and documents, which is what browsers are good at by default.

        1. 2

          Is a React app technically a SPA?

          1. 4

            If you're re-implementing routing in JS, yes?

          2. 3

            It depends. If you use React with "create-react-app", then it is. If you use things like Gatsby or Next, it might not be.

  6. 5

    Work on yourself. Above everything else.

    Show me a human being with courage, a big heart, an open mind, an honest soul, a work ethic. And that human can conquer whatever he sets his mind to.

    It's all about mindset. It's all about approach.

    Everything is linked. Josh Waitzkin won the U.S. Junior Chess championship. Nine years later he won the Taiji Push Hands world championship.

    Specific tactics pale in comparison to the importance of your character. Develop a world championship mindset. Everything else will fall into place.

  7. 5

    Behavior is rooted in identity. If you want to control what a person does, convince them to take on a matching identity first. If you want to change your own behavior, adapt a new identity for yourself.

    1. 1

      Atomic Habits by James Clear talks about this

  8. 5

    Lessons learnt in last two weeks of problem & idea validation

    • The best way to get feedback is to give it first and then ask for it

    • Make effective use of search feature in IH, Reddit and other forums to find people who have posted queries related to the problem you're trying to solve

    • Just create the hero section of your landing page and pass it around. Ask people if they have any unanswered questions or what would they like to know about your product. Voila! they will let you what they expect to from your landing page. Design the rest of the page accordingly.

  9. 5

    Be good! Whatever you do, create sustainable value to the society 🌿

  10. 4

    Cold calling is not dead.

    1. 2

      For B2C in Northern America, maybe it is... who honestly answers their phone or even listens to voicemails? Haha.
      I agree though for B2B in the commercial world. If you've done your homework and believe that your product or service can reduce my expenses then I want to know and get the info as quickly as possible. I can't get the same sense from an email exchange, if I even bother to open and respond.

      1. 1

        That’s exactly why it’s so hard to align sales and marketing teams! Marketing wants emails, sales want dials! A true love hate relationship.

        1. 1

          People leave jobs and their email goes stale. But, the phone number and extension for their replacement will likely remain the same ;-)

          1. 1

            Exactly! No matter how often the marketing team says ''We built this brand new bit of content, can you send it to the same email we've been trying'' will ever change that!

  11. 2

    The typical bootstrap wisdom of 'Always Charge' is killing IH businesses: https://www.indiehackers.com/post/your-pricing-model-is-killing-your-growth-4b99ada1ba

  12. 2

    As long as you are learning on your startup journey, you are not failing. Your startup might be though... so learn to separate your startup from your identity. Identity can outlast multiple startups.

  13. 2

    Playing is at the core of learning.

    1. 1

      play do not work!

  14. 2

    There is no "best" way to live the life. We create the goals and meaning.

  15. 2
    • Businesses live and die by their distribution channels. Mediocre product with good distribution channels will usually beat a great product if no one knows about the latter.
    • If you feel that the particular way of acquiring customers isn't the right fit for your personality or values, then don't do it! It is doubtful that you will succeed, but you are guaranteed to feel miserable.
    • The true validation is people paying you money. Email addresses and interviews can give you rough signals, but they can only take you that far.
    • Keep your costs low. It is easy to indulge in a spending spree thinking it takes money to make money. Running a lean operation is a competitive advantage (but I firmly believe that you shouldn't compromise on your core competencies. I'd also add support to the list of things you shouldn't skimp on).
    • Most minor decisions won't matter in a few months', let alone in a few years' time. Don't overthink it. Make a fast decision, and if necessary, re-evaluate it down the road.
    • Don't compromise on your values. It leads to a slippery slope.
  16. 2

    My truisims:

    -If people don't add to you, then they take away. There is no neutral.
    -You can only help those willing to help themselves.
    -At the end of your life, only the genuine relationships and experiences you've had matter.
    -Follow your bliss.
    -Find someone to share the journey with.
    -Hold yourself accountable for all of your actions, but don't take yourself too seriously.
    -Keep grinding until you achieve failure. You're almost there.
    -The road to happiness probably isn't paved with knowledge.
    -Find meaning. If you can't find it, create it.
    -Find beauty. If you can't find it, create it.
    -Don't be consumed by hate or regret. It will only hold you back.
    -If it won't matter in 20 years, it probably doesn't matter now.

  17. 1
    • Happiness does not exist
    • Competition does not exist
    • 99% of freelancers, agencies and entrepreneurs in general have jobs, not businesses
    • We are multi-dimensional spiritual beings having a human experience
    • We are all one <3
  18. 1
    1. Coding is the last thing you should do while evaluating your idea. Find some other way to demo your idea to spark a conversation (it isn't a MVP): Demo video, landing page with expected screen shots, zapier + forms + something else. Anything but code.

    2. Before jumping in to code, consider all other options to avoid it. For example, Wordpress + plugins is surprisingly powerful if you can use some imagination and re-purpose something that is already available. For example, look at Build a Stack. I built this on Wordpress + WooCommerce + 60 other plugins. No custom code.

    3. Also consider Visual coding tools like Bubble, etc. The fact that it integrates with APIs of other products really helps.

    4. Also look at ready options for part of your functionality. For example, using keen.io for white-labelled analytics, GetStream.io for newsfeeds, Twilio for chats, etc.

    5. Good developers are hard to find. Even harder to convince to join you as a start-up. If you do not code yourself, be ready to spend a lot of time explaining what you want and testing what has been delivered. Don't let the fact that you have years of product development experience lull you in to false sense of confidence. It is different when you are resource constrained.

    I learnt the above after spending best part of 2 years getting a product developed (it should not have taken that long) only to find it wasn't at all necessary for my business. For what my customers wanted, HubspotCRM + Zapier + Zoom + Google forms + WooCommerce was a good enough stack. This was after 14+ years of successful product development before that.

  19. 1

    MVP or user validation is not strictly necessary or even useful to be successful (especially in highly regulated industries)

    1. 1

      could you expand on that? You're saying you should only release the finished product?

      1. 2

        In some cases, you only allowed releasing a relatively finished product. See, for example, medical devices, drugs, embedded software in critical devices, and the list is very long. Related reading: https://www.bitlog.com/2020/02/12/why-are-we-so-bad-at-software-engineering/

  20. 1

    If you haven't ever moved to a faraway place, learned its language and made a life as part of its culture, you're probably blind to the one you grew up in.

  21. 0

    We should refuse to work with, pay or use products from companies that exploit or harm others.

  22. 0

    This comment was deleted 2 months ago.