3 ms·
Thanks for reading and for the detailed response! >One thing you should try hard not to do is look at the competition and write it off as crap. It's highly unl
by mtlynch 7y ago
Thanks for reading and for the detailed response!
>One thing you should try hard not to do is look at the competition and write it off as crap. It's highly unlikely that your antecedents set out to make a shit product. It's likely that when they were starting out, they wanted to create something efficient and streamlined, but then years of paying customer feedback took things to where they are today.
Yeah, you're right. I definitely had a bias to look for the weaknesses in their product, and I'm probably overlooking the positives. And I might be overweighting the fact that the UI is ugly and seems to have poor design. But it also suggested to me that it's a company that's been comfortably entrenched for a long time and has never had a competitor to force them to continue improving it.
>I wonder how much of the shopkeepers reactions were fighting change vs just not trusting someone who didn't come from where they came from. There's real class anxiety around the blue collars vs the 20-something software millionaire set... In other words, he found someone to spend a month doing free fan service for an idea that if he was truly that excited about it, he would have hired you or at least proposed a partnership and been much more aggressively involved in doing the initial customer development conversations with you.
I agree. There was definitely a disconnect. I'm not sure if it was blue collar vs. spoiled software kid as much as sheet metal vs. not.
The first shop owner actually did offer to partner with me, but I decided against it. I know it would have increased the odds of success, but the independence of this lifestyle is one of the most important parts to me.
>The only way to sell into those shops would be for your first customer to make the leap, and then have someone else that already agrees with that customer make the leap and show everyone else that it's safe.
Yeah, I think there's kind of a catch-22 there. Because I'm not super passionate about sheet metal, I wouldn't want to commit the next X years of my life to sheet metal unless I had assurance that I could make at least a few thousand dollars per month. But my first customer doesn't want to take a leap of faith with someone who's going to disappear if 4 more customers fail to materialize, so we're sort of stuck.
If I found 3-5 customers who showed strong interest in purchasing, then I'd be willing to invest 3-6 months building an MVP for them, but with just one customer, I'm afraid to put months of my life into something and have just one customer for years.
>I agree that scraping is a fools errand. However, it's also really important that you replace scraping not with your time but with someone you hire from the internet. Not only is your time way too valuable, it's not a realistic test of what will be necessary to scale it even a little bit.
Oh, I actually disagree with this. I think scraping is too expensive for the MVP, but I plan to eventually move to scraping. The website I mentioned, KetoHub, works on scraping. It scrapes 16 different blogs, and I've only had to fix the scrapers 2-3 times in 2 years. I can usually write a scraper for a previously unseen cooking blog in about 2 hours.
I expect comedy clubs to be pretty easy to scrape because they don't change their layouts very often, and there are probably O(1000) comedy club websites in the US.
>You might find it useful to watch this presentation by the founder of Bandcamp at #XOXO. https://www.youtube.com/watch?v=MaUkS-lr-ZM https://www.youtube.com/watch?v=MaUkS-lr-ZM
Interesting, I'll check this out. Thanks!
>I do have a small beef: you say that you were making an MVP. What could possibly justify using Vue or any SPA to build something this simple? When did it become the default to start an MVP using tools that are designed to solve Facebook scale problems?
I'm a bit confused by this point. What is the simpler alternative to Vue? Just write bare HTML and copy/paste it for every route? PHP?
I developed KetoHub using Angular, and I think your feedback applies to that project. Angular was such a hassle to work with because there are a million configuration things that are a pain, and then there are breaking changes every 6 weeks. It's fine for enterprise, terrible for a one-person dev shop.
The project I did after that was just Flask, Jinja templates, and two lines of JS. But that was kind of a pain to work with, too. There wasn't much complexity, but there was a lot of repetition and it was hard to organize the code. I ended up with lots of small template files but without any of the compiler support I'd get from an Angular/React/Vue.
For WanderJest, I just reused the architecture I had from a previous project where the backend is Go, frontend is Vue. I haven't yet run into an issue where the tech stack has been a bottleneck. I feel like it's actually been the opposite, and I'm moving faster on this project than I've ever moved on a previous project. I'm comfortable with the stack, and I feel like it's fairly simple.
>Your filtering needs were pre-solved by Isotope, for example. https://isotope.metafizzy.co/ https://isotope.metafizzy.co/
That requires me to research options, understand Isotope's commercial license, buy it, then learn how to install and use it. And then repeat that process for every feature I need.
I already know how to get around in Vue, so that's the most expedient path for me.
- peteforde 7y agoCaveat: you are clearly much more proficient at scraping than I am. It's an enviable skill. What I'm about to say is pretty fuzzy, but I have noticed that services based on scraped datasets trend towards being predictably shittier than services lovingly harvested by a human. Obviously it's domain dependent but my bias is that it seems like scapers pick up a lot of crap; in music, it'd be the singer-songwriter showcases that literally even the performers families don't want to go to more than once a year. I would filter out a service sending me 100+ mediocre, repetitive listings every week. I would consider paying for 5-6 human curated listings that strike a blend between "don't miss Judd Apatow" and "you might like Little Esther" up-and-comers. It's the human giving a shit that is providing value. I am someone that if I go to something I don't love, it is far worse than if I didn't leave the house. So, yeah. It's all going to come down to what kind of customer you want. O(1000) comedy consumption sounds like someone who doesn't care how they are entertained so long as they don't have to contemplate how small they are in the universe. Like, if someone in my circle said "let's go see some comedy!" I'd say "oh, who?" and if they looked at me perplexed and said, "I dunno... comedy!" I would consider this grounds to reevaluate this relationship. "Let's go see some music!" "What band?" "Oh, just some music!" gun Anyhow. :) And hey, if you're moving fast and love Vue, keep rocking it. I just meant... use Rails. Use PHP. Use anything that emits HTML that doesn't need to be rendered in JS on the client. This is just my opinion. If you've never tried Rails, perhaps consider trying Rails. Most of the other server frameworks (Laravel, Express, Django) are just efforts to copy Rails in other languages, but they never quite nail it.
- mtlynch 7y agoThanks for the response! Oh, I think scraping and curation are orthogonal. I agree that if I just scrape anything from the web that looks like a comedy show and don't do anything to help the user sort the good from the bad, it's going to be a bad time. I want my site to be useful for casual comedy fans who just want to see big names like Judd Apatow or Jerry Seinfeld. And I also want it to be useful for comedy nerds who do want to see open mics and alternative comedy shows. Both experiences should be possible with automated scraping + curation/ratings/filtering. > And hey, if you're moving fast and love Vue, keep rocking it. I just meant... use Rails. Use PHP. Use anything that emits HTML that doesn't need to be rendered in JS on the client. This is just my opinion. If you've never tried Rails, perhaps consider trying Rails. Most of the other server frameworks (Laravel, Express, Django) are just efforts to copy Rails in other languages, but they never quite nail it. Ah, okay. I've never tried Rails, but I have been interested. Moreso in the last few years as I become a bigger fan of Basecamp. Maybe I'll find an excuse to learn it this year for a hobby project. PHP, I used for a while ~15 years ago, and I don't really miss it, but maybe the experience has gotten better since then.