3 ms·

I spend a good 3 months on getting an initial version out of my latest side project called Postways [1] and launched it just before xmas last year. Since then I

by pan69 9y ago

I spend a good 3 months on getting an initial version out of my latest side project called Postways [1] and launched it just before xmas last year. Since then I have been focusing on on-boarding users and just improving the service overall. Marketing it and connecting with an audience and potential customers is the real challenge. I did everything myself. I have a number of great features in the works but for now I purposely want to keep the scope very focused around a core set of functionality so I don't mentally overload myself. At some point I hope to afford to engage with a visual designer because I really think that having a great visual brand can make a real difference in whether or not potential customers landing on your home decide the signup or not. [1] https://www.postways.com https://www.postways.com

igammarays 9y ago
Looks very interesting, but I had a lot of trouble trying to understand your value proposition. How many active users do you have so far?
- pan69 9y ago
  That's a good question and so far it has been the most challenging thing to communicate this well, or, in a concise way. So, any feedback is welcome. When an application sends transactional messages, software teams often integrate with some transactional email service (SendGrid, Mailgun, etc). However, these services primarily solve an infrastructure problem, i.e. the problem of not having to setup and look after your own SMTP server. These services typically don't solve a content problem. Many applications these days send both email and SMS (and if there is mobile app, also mobile push). Somehow we're totally OK with using any of the MailChimps of this world for promotional messages (email templates) but when it comes to our transactional messaging we're fine to just stick message text in our source code. When a team grows, product people will want to have easy access to the message text, not just for marketing/promotional email, because they will want to tweak it constantly. In a way you can think of Postways as a message management system. Onboarding users has been slow. One of the main problems I have run into is that when software guys look at this they say something like "Uh, I can build this is a weekend" (typical developer under-estimation) and business owners find it to technical and refer judgement to their lead dev. From the users I do have it actually took a while for them to "get it", I had to spend quite a bit of time helping them to onboard but once they were in, the feedback was mostly along the lines of; of course, this makes total sense.. One last thing, I'm not competing with any of the existing transactional services. To use Postways you need to BYO your own infrastructure. Reasons, It wasn't a problem I wanted to solve and I figured most people already use some service for their transactional messaging, making it easier to onboard them. E.g. Postways fully supports SMTP integration, so if you're already using Mandrill, or what ever, you can just keep using that.

by pan69 9y ago

igammarays 9y ago

Looks very interesting, but I had a lot of trouble trying to understand your value proposition. How many active users do you have so far?

pan69 9y ago
That's a good question and so far it has been the most challenging thing to communicate this well, or, in a concise way. So, any feedback is welcome. When an application sends transactional messages, software teams often integrate with some transactional email service (SendGrid, Mailgun, etc). However, these services primarily solve an infrastructure problem, i.e. the problem of not having to setup and look after your own SMTP server. These services typically don't solve a content problem. Many applications these days send both email and SMS (and if there is mobile app, also mobile push). Somehow we're totally OK with using any of the MailChimps of this world for promotional messages (email templates) but when it comes to our transactional messaging we're fine to just stick message text in our source code. When a team grows, product people will want to have easy access to the message text, not just for marketing/promotional email, because they will want to tweak it constantly. In a way you can think of Postways as a message management system. Onboarding users has been slow. One of the main problems I have run into is that when software guys look at this they say something like "Uh, I can build this is a weekend" (typical developer under-estimation) and business owners find it to technical and refer judgement to their lead dev. From the users I do have it actually took a while for them to "get it", I had to spend quite a bit of time helping them to onboard but once they were in, the feedback was mostly along the lines of; of course, this makes total sense.. One last thing, I'm not competing with any of the existing transactional services. To use Postways you need to BYO your own infrastructure. Reasons, It wasn't a problem I wanted to solve and I figured most people already use some service for their transactional messaging, making it easier to onboard them. E.g. Postways fully supports SMTP integration, so if you're already using Mandrill, or what ever, you can just keep using that.