Personally I'm not a fan of people sharing Bitly links, etc rather than just link to the end result directly. I don't like the idea of being tracked, cookied, etc. Regular links do the job just fine.
Makes me wonder whether there's a market for a privacy-friendly link shortener. That intentionally does not track people, set cookies, etc. I know that would limit the functionality, but the signal "I respect your privacy" might make up for it. You could even add privacy-specific functionality such as hiding the referrer, etc.
I know @jelmerdeboer recently(?) set up his own instance of the open-source YOURLS. I'd be curious to hear what he thinks of BTFY and whether the convenience of it being hosted (and perhaps extra features?) outweigh the price tag.
Personally I'm not a fan of people sharing Bitly links, etc rather than just link to the end result directly. I don't like the idea of being tracked, cookied, etc. Regular links do the job just fine.
Makes me wonder whether there's a market for a privacy-friendly link shortener. That intentionally does not track people, set cookies, etc. I know that would limit the functionality, but the signal "I respect your privacy" might make up for it. You could even add privacy-specific functionality such as hiding the referrer, etc.
I think it's a laudable goal, but to be honest it would be hard to convince me to switch to a new service.
I think most established services are already quite developer-friendly with a lot of available plugins and different ways to integrate their service. For example, I use SendGrid's SMTP because it's easy to configure Ruby on Rails that way. There's also built-in support for ActionMailbox which lets me process incoming email.
For me an HTTP API would actually make things more difficult as I'd need to somehow configure Rails to use that instead. It would also make it harder for me to switch from or to another service.
SendGrid also has a great deal for startups ( wip.chat/deals ) where you basically get 12 months premium for free.
I think you're getting into a very crowded and competitive market. I wonder if there's a specific niche that's currently underserved you target instead of developers as a whole.
Thanks Marc, indeed this is spot on.
It's hard to convince anyone to switch unless they're having difficulties with their current provider (I do think that is an ongoing problem for even the larger players, e.g. Sendgrid were getting heat recently: news.ycombinator.com/item?id=…)
An integration with Rails is something I am considering, but I don't want to maintain lots of integrations so I will be selective about which frameworks to target. There's also something to be said about reducing library dependencies for a lot of app developers.
Obviously buying into the market by e.g. offering 12 months free could help but I would prefer to choose customers that are looking for quality service, performance etc. over the cheapest deal.
Thanks for your last comment especially - looking for and finding the right niche, figuring out how/when those developers/companies make their email provider choice and then influencing that choice is going to be my main focus for the immediate future.
My main piece of feedback is that it isn’t clear to me why I should use this over one of the many established services.
Especially considering it’s mission critical and privacy sensitive.
Thanks Marc! This is a great question.
I want to position OhMySMTP as the most developer friendly way to send transactional email. The API is really, really simple (one endpoint with very few options to trip users up), we're focused on getting to inboxes/staying out of spam folders, and we hand-hold users through getting DKIM setup and setting everything up ready to go.
I'll update the landing page to make this clearer.
I see you use sendgrid for wip, was there a reason you chose them?
I think it's a laudable goal, but to be honest it would be hard to convince me to switch to a new service.
I think most established services are already quite developer-friendly with a lot of available plugins and different ways to integrate their service. For example, I use SendGrid's SMTP because it's easy to configure Ruby on Rails that way. There's also built-in support for ActionMailbox which lets me process incoming email.
For me an HTTP API would actually make things more difficult as I'd need to somehow configure Rails to use that instead. It would also make it harder for me to switch from or to another service.
SendGrid also has a great deal for startups ( wip.chat/deals ) where you basically get 12 months premium for free.
I think you're getting into a very crowded and competitive market. I wonder if there's a specific niche that's currently underserved you target instead of developers as a whole.
Thanks Marc, indeed this is spot on.
It's hard to convince anyone to switch unless they're having difficulties with their current provider (I do think that is an ongoing problem for even the larger players, e.g. Sendgrid were getting heat recently: news.ycombinator.com/item?id=…)
An integration with Rails is something I am considering, but I don't want to maintain lots of integrations so I will be selective about which frameworks to target. There's also something to be said about reducing library dependencies for a lot of app developers.
Obviously buying into the market by e.g. offering 12 months free could help but I would prefer to choose customers that are looking for quality service, performance etc. over the cheapest deal.
Thanks for your last comment especially - looking for and finding the right niche, figuring out how/when those developers/companies make their email provider choice and then influencing that choice is going to be my main focus for the immediate future.
First impressions:
- There's a lot happening on the page. Not sure where to look. Might be okay once I become a returning visitor and get used to it, but initially it is a bit disorienting.
- The two visible "above-the-fold" topics are "Belarus Protests" and "TikTok", neither which I'm interested in. I'm not sure you need to fill the whole screen with news about just two topics. Perhaps it might be more useful to show a diversity of topics and let me dive deeper into the ones I like.
- The headlines are a bit hard to parse. I'm not sure why. Maybe because there's so much, there isn't a clear visual hierarchy (most font-sizes are the same for example), and there isn't anything yet that tells me what headlines are the most important. Once you've got some upvotes and can rank by that, that might help solve it. But you haven't gotten that yet, so you might need a temporary solution.
Overall impression:
I like the fact you're experimenting with a new approach here. And while I'm not in love with the layout yet, I do like that you're experimenting here as well. It's something new which is refreshing.
Personally though, I don't feel like I need another news source. Especially for news that';s covered everywhere else already. I don't find these topics very compelling.
I'd be more interested in a news site that is specifically about the things I care about, and aren't covered elsewhere. Random example, but I'd be curious to see Hacker News posts that aren't popular enough to get on the front page, but still curated by the community (e.g. more than 10 votes).
In my experience you tend to get the most useful feedback from people who've been following your journey for a while and know the background of you and your business.
So while I think the idea of providing access to experts is interesting, I'm not sure how it will scale. To get real value of it, I'd want to spend time with experts on a periodic basis. Additionally, I'm not sure what keeps people from going around your service and contacting the expert directly.
hey man, sorry I just saw this. Some other people have mentioned contacting the makers - in some cases this is possible but I think others like Scott don't tend to be on twitter much.
Not sure if I get your first point though?
My main two issues with these kind of collaborative roadmap services are:
Customer don't generally know what they want. They often request a specific feature, but if you follow up and really get to understand the problem, there's likely a better solution than what they came up with. You can't blame them though. It's your job as the entrepreneur to translate their feedback to a useful product.
Most customers won't bother filling out a form to request a feature. They just tell you through support what isn't working or ask about something you currently don't have a solution for. Asking them to add it to a roadmap is customer-unfriendly. Plus, you're better to continue the conversation 1:1 anyway as that's the fastest way to understand their underlying needs.
I've seen some other startups tackle these problems, by integrating with support services like Intercom. The support team can then create "feature requests" or link support tickets to existing "feature requests". This lets the product team see all the relevant custoemr conversations in one place, and support can follow up once the feature is shipped (or solved in a different way).
This requires a vastly different approach, but I think that's more likely to fullfil its promise. Many people have tried creating these public roadmaps, but I have yet to see anyone succeed. In all those years think I've only participated in one as a user.
Your landing page mentions "loved by indie hackers" and I think that's exactly the type of person that likes this idea. They like building in the open, but aren't sure what to build. They hope with a public roadmap their problems will be solved. But I think it's unlikely. They are likely to have limited budget, so monetizing properly will be hard.
I suggest focusing your efforts on the most successful users you have. And really try to understand their needs. And disregard any feedback from customers with small budgets.
Thank you so much for you inputs Marc 🙏
You are right that customers sometimes don't know what they want. But it would be a good start to spark some new ideas, not necessarily to be exact the same with what customer wants.
I also agree the 1:1, real-time chat is the most efficient way. Actually we do have the comment area where project owner can chat with customer directly. It just provides a central place to manage all these discussions.
This micro saas product is only targeted for indie hackers and bootstrappers like us. I haven't yet created those integrations and ticket assignment process. It wouldn't fit in the indie hacker's mode. So I wouldn't bother to add those features into the current version, haha
We do have people signed up, but not yet converting one to the paid user. Yeah, monetizing would be hard. For me, just want to offer the most comfortable price for indie hackers with small budgets.
javascript image cropper or javascript image filters depending on what I'm looking to do.
I would look for example code. I prefer vanilla javascript over libraries as they usually come with a lot of features I don't need. I might still end up using a library though, if it's lightweight.
( Might be worth writing some blog posts for different JS frameworks including plain old JS, with simplified ways of doing what your library does. Then when somebody wants extra functionality they know where to find you. )
Yes, working in public does increase the chance someone will take your idea or get inspired by it. But generally I'd say that the originality of your idea is, or at least, should not be what makes or breaks your product.
I don't share everything I do publicly, but I do share a lot. I find that there's a lot of benefits (getting product feedback early on, expanding by network amongst makers, getting more useful advice, etc) outweigh potential disadvantages.