November 14, 2017

Show IH: Preparing for launch, critique our app/landing page. Programmable user to user chat.

Hey IH Family,

My name is Travis and I'm a through and through Indie Hacker. I work with one other person(my business partner) and we own a development company called Grillwork. We do contract work to keep the lights on, but in our down cycles or when the opportunity arises we build our own products! Our ultimate dream is to be able to afford our current life styles through our own products and steady MRR.

We're getting ready to launch our 2nd SaaS product as a team(the first was a huge failure last year). We learned a lot from that experience and could use some critiquing from like minded individuals. We've been hard at work on this project for about 2-3 weeks now off and on around client work and this is what we have so far.

Our toolset is mostly Elixir/Erlang/OTP and ReactJS these days, all though we do a bit of work still in Ruby on Rails.

The product is a programmable user to user chat platform. We want to give developers a way to offer communication and collaboration tools to their customers that give them a Slack/Discord like experience from within their own web application.

The idea came about as we had a client that needed user to user chat. We offered to build it at no cost to them, if we could turn it into a commercial application and they would become our first paying customer. They agreed and here we are!

We've got the app running in our clients application and we're now turning our focus to polishing the app itself with missing features we deem necessary to be a full featured MVP.

Here is a link to a local dev version of the landing page running. Please critique it!

Also the chat thread you see on the landing page is functional. We have not gotten to handling anonymous users so it's dummied up at the moment(One of those features).

In the future that chat will be private between the anonymous user and ourselves we just haven't gotten there yet(some time today probably!).

Please leave all the constructive criticism you want or feature ideas! If you think the app sucks let me know that too!

Update: I have taken the demo down for now thanks all for your thoughts and sharing.



  1. 1

    Hey Travis!

    I love the idea of the idea of spinning a client’s need from a one-off contract to a SaaS opportunity -- and having that client become your first paying customer.

    I’ve seen a need for a user-to-user chat solution previously and the demo looks like a great start.

    Just tossing out my initial thoughts here, from reading the comments on this thread and then checking out landing page earlier today. Website/webapp-owner-to-user chat is fairly commonplace, and while your solution is solving a different end-user-to-end-users-users problem, I think quickly overcoming that confusion will be important.

    The use-case stories you used in your response to duncanawoods were great, maybe leveraging one of those stories concisely/visually in the landing page? Projecting the visitor into the shoes of your (current) perfect customer.

    “You’re Bob, the owner of a marketplace where people come to sell their Big Widget Service. You have a seller Jane who’s gained a lot of traction selling Big Widgets on your app, but feels like she’s missing a lot of lost opportunity from the uptick in abandoned checkouts displayed on your dashboard. She’d love a way to communicate to her prospective customers quickly to recover that value. Help Jane make the sale, let her chat with prospective customers, give her [ChatWidget Name]” (This is terrible copy, but just quick thought)

    And if you can manage it for launch, social proof from your first paying customer would be amazing.

    On another note, your product has “Some coding abilities required” I wonder if, in the spirit of doing things that don’t scale, offering a concierge service to help your first customers (if they need it) get up and going, would be worthwhile? It enable you to get really close to your customers’ environments and get first hand experience on integrating with businesses, giving you your own feedback loop to help make sure adding your solution is as frictionless as possible.

    1. 1

      Great ideas, we've already discussed working with our first few clients to integrate if need be, mostly so we can learn from it too. See the pain points and write better docs or make things easier in that area.

  2. 1

    OK, I get it. I'm working on a project at the moment where this type of tool could come in useful.

    We use a subdomain model in our MVP application, so each client has it's own subdomain (like confluence for example) - How would pricing work in this instance?

    Is there a way I can see the application in all of its glory? I can see a chat window at the top - is that the extent of the application right now?

    We are currently hosting in Wordpress until we can confirm demand. Would this integrate well with WP?

    1. 1

      Currently we do not have the admin side built yet, everything is pieced together manually while we finish building out the platform. We expect to launch to the public by Jan 1. We're at the point now where we have a working beta version, but everything is a manual process at this time and there is no documentation.

      This will work with any website that supports javascript and websockets. The most basic of implementations is literally just a few lines of javascript in your <script></script> tags.

      The chat app itself is a very small(about 300k) ReactJS app.

      Our pricing will be very simple $50/mo will give you unlimited chat instances and unlimited users per application. As long as its the same application the subdomains won't matter(multi-tenant). A key will only work on 1 app at a time. An account can have multiple keys for multiple apps. But each key costs $50/mo. Free while in dev mode which gives you 10 concurrent connections to the chat for dev purposes.

      The demo chat thread is all I have up at the moment, but if you send me your email I can reach out to you once we have more to show. Would love to get you in to beta test.

  3. 1

    i love your design. you have a good eye and i would love to learn how you got all these SVG icons for your cards as i would love to use something like that in future.

    friendly critiques


    1. on the pricing table i think you need to lead with the FREE pricing

    first off just have the traditional three pane pricing table. free, 50/mo, enterprise. or some other random thing. the sole price there looks very lonely. also your "Userchat is FREE until you're ready to go live. " is in very small text compared to the table and a skimmer would miss it compared to the 50/mo price (which does look like a good deal but you need to make clear if you need a credit card for trial (sounds like no, so why not put that up there)

    1. i would put the use cases above the features.

    Start with Why.

    Start with Why.




    Here's how I, a prospective customer, should be thinking:

    "blah blah blah oh wow this is for Two Sided Marketplaces! and it increases transaction volume x%! Take my money!"

    "oh damn I have a collaboration app but the user chat is such a pain to code and host and this increases engagement and retention 5000%!!"


    1. the product demo right up top above the fold is nice but every user is Travis Mathis and you can edit other people's comments. this is clearly not how your clients would use it so why not set it up something more realistic? you can do it :)

    ideas: randomly generate user name ("blue flamingo", "angry coconut") for each unauthenticated client session


    good luck and congrats on almost shipping!

    1. 1

      Ya the demo atm is very much not setup to be a true demo. Currently our client that needed this product doesn't have a use case for anonymous users.. so we hadn't built that functionality in yet(we wanted to get to the point of meeting all their feature requests so we could get it into production and start seeing some traffic, and getting the $50/mo to pay for the servers)...

      So right now you're logged in as me(which is why you can edit all of those messages), and the only other user configured to chat in the instance is my business partner and other developer Dan. If you scroll up you'll see you can't edit Dan's message. It will surely not be this way when we put this on the internets :)

      I was just putting it there as a placeholder atm. There is still a TON of work to be done over the next 2 months before launch to get this to where we would call it an MVP we would release. I wanted to get this in front of people and start generating feedback asap.

      We're already working on de-anonymization features like intercom does etc "ie blue flamingo" "please enter your email to receive notifications", etc. We started work on this last night and will be in place for MVP launch.

      Thanks for all the helpful tips! We'll surely take it all in and put it to good use. Appreciate the design compliments, especially since I don't consider myself a designer even a little bit. I'm quite adept at the codes, but I kind of just blindly bang my way through design stuff, lol! Great stuff much appreciated.

      I get my SVG's from the $9.99/mo subscription for their library of SVG's is an absolutely KILLER deal and if you do any kind of development regularly at all is worth its weight in gold for a programmer that has 0 art skills. I also use Adobe Color to help me make color schemes that look great.

      1. 2

        When using icons from, please make sure to use icons of the same art style as Flaticon makes it really easy to search for icons of the same styles.

        The first 3 icons are all of completely different styles and it makes me want to leave the page instantly as it looks unprofessional.

        1. 1

          thanks appreciate the feedback, sometimes though I find it hard to find one that I feel fits the "topic" in specific styles.

  4. 1

    Hey Travis,

    Congrats on the platform and product. It's really looking good! I know the messaging side of things is incredibly hard to land. Keep iterating, you'll get it! As an engineer, I think I understand what you're getting at - so I'll hold any messaging criticism for others who seem to be better versed at it. I have a couple architectural and design questions for you.

    Since this is a SaaS, I assume people will embed a client into their app that will connect to services hosted by you. What privacy guarantees do you offer as part of that process? I assume any connections are protected over standard protocols. However, once your services begin handling requests, how visible are those requests to your services?

    Is this service a true realtime feed, or is data persisted into your servers for historical views. If so, have you gotten to the point where you're putting protections in place to ensure these conversations remain private? Is there any isolation/partitioning strategy for consumers who might want a bit more "protection".

    Congrats again on the product. We're actually looking to embed chat features into one of our products, but we have extremely heightened security requirements. Is this something we could look into?

    1. 1

      Hey Preston, thanks for the questions.

      I assume any connections are protected over standard protocols. However, once your services begin handling requests, how visible are those requests to your services?

      How far to go with internal security is something we've been debating. At the moment, the websocket is secured over TLS, but once the data gets on our servers it is plaintext. While we envision rolling out a highly secure version, it hasn't yet been a top priority of the MVP. I'd love your thoughts on what you would need to feel comfortable using a service such as ours. The more secure the better in our minds.

      Is this service a true realtime feed, or is data persisted into your servers for historical views.

      We keep active threads and messages in memory. We also have logs stored with LogDNA. The messages are persisted long term in RDS with at rest encryption.

      If so, have you gotten to the point where you're putting protections in place to ensure these conversations remain private? Is there any isolation/partitioning strategy for consumers who might want a bit more "protection".

      We segment each account into separate database tables. We were also considering allowing our customers to specify their own RDS credentials.

      Congrats again on the product. We're actually looking to embed chat features into one of our products, but we have extremely heightened security requirements. Is this something we could look into?

      We'd love to work with you and would absolutely be willing to code to your requirements within reason. Doing so could only enhance our product!

  5. 1

    Congrats on sharing what you've built!

    I'm having a difficult time understanding what exactly you've built from the landing page. I typically scroll through quickly on a page, take a look at what information is there, and then go back and read through it. After doing this twice, I still can't quite understand the customer this would apply to.

    One thing that caught my eye is the call-out "Embed chat instances anywhere". This leads me to the question -- why isn't it embedded on your homepage? This way I can at least try out what you've built.

    I'm interested to hear more about the product, and once again, way to go on getting it out here and sharing!

    1. 1

      What browser are you using? It should be right at the top of the page in the header next to the sign up. "Have Questions? Ask Away!" A browser that supports sockets is required. have tested on IE11, Chrome, Safari.. Just tested on Firefox and found a connection issue (; _;)

      Update: The firefox issue is due to the ngrok/tunnel URL and the cert.. use chrome, safari, ie/edge for now.

      Update 2: This has now been resolved and appears to be working in firefox latest and tested on chrome mobile.. Sorry for the issues, still working out the kinks!

      1. 1

        Firefox 😀

        I’m on mobile now but will give it a try as soon as I get to my laptop.

        1. 1

          I have not done any actual mobile testing or optimizations yet, but firefox seems to care more about the certs and such not matching :) I believe the issue here is that the tunnel is not secure but the websocket is and the certs don't match this is actually a browser setting and you can probably click on the lock on the page and approve permissions is my guess if you wanna go through all that.. Or just check it out when you have access to chrome/etc :)


          1. 1

            Finally getting around to checking it out! It's working no problem on Firefox for me now, maybe you fixed something up =)

            So is this setup so visitors of your site can chat to each other? Or so visitors of your site can chat to the site owners?

            1. 1

              Yes, I did fix it :) Thanks!

              Right now it's setup so that you're logged in as me(travis) and can chat with my partner dan.. The current functionality requires a auth'd user to work so.

              It's not really setup as a proper demo.. In a few days we'll have an update that handles anonymous users. But as of now it currently does not as our current client didn't have a use case for them.

              We did start it last night however and is the next feature that will be completed.

              1. 1

                That's fantastic! Looking forward to checking it out.

  6. 1

    programmable user to user chat platform

    Made me think it was programmable by the users chatting and although intrigued, I couldn't understand what that would mean! "Embeddable chat plug-in" would make more sense to me.

    I'm finding it a little difficult to imagine when embedded chat inside an application would actually be better than a dedicated channel outside of the application. I think that might be my failing. What do you see as the common use case?

    1. 1

      Well the major difference is, it's not an Embeddable chat plug-in.

      It's a programmable chat interface. Some coding abilities required. The other major advantage to this platform is it's not designed with site owner > site users in mind. But site user > site user.

      So where most chat apps today are focused on letting the site owner speak with their customers or users, this allows you to build in app the ability to let your users speak with each other.

      The use case we have had so far was in a two sided marketplace where people who fly airplanes search for simulator time. The site owner wanted the ability for buyers of simulator time to chat and negotiate with the sellers of simulator time while being able to share files and information about the particular simulator with the buyer.

      Another use case for this type of application for instance is in apps like Upwork. They have communication between people looking to freelance and people looking to hire freelancers.

      Our platform gives you the ability to build these types of private user to user or group chat situations.

      This is why outside channels wouldn't work better. These types of chat rooms are specific to the window they live in and are private between users, with the ability to change the rules of the chat dynamically based on actions taken by your users.

      This is a tool built for developers but we hope that once we finish the weeks of documentation we have coming up will be simple enough in basic use cases for even non-developers(some cut & paste JS).

      1. 1

        Well the major difference is, it's not an Embeddable chat plug-in. It's a programmable chat interface

        That still confuses me. How is programmable an important distinction compared to say e.g. adding Drift or Stripe to your site? Your site says "Embed chat instances anywhere." so... I remain puzzled.

        two sided marketplace

        Ah yes, makes sense. Comparing to Slack threw me off a bit. The "Two Sided marketplace"picture at the bottom of the landing page made me think your intention was to be a two-sided marketplace rather than an intended use-case.

        1. 1

          Stripe is actually a GREAT example of a programmable payments platform. There is a basic use case integration, but for the most part is built for developers to build any kind of payments setup they need right? If you're a non-developer you probably go w/ say simple amazon or paypal payments or just the basic stripe widget integration.

          Same goes for this app. In its most basic of use case it is a "Chat Plug-in" but its real purpose is to give you the tools you need to build a fully functional chat app for your given use case, like Upwork or our client I mentioned before. If you wanted you could build your own slack/whatsapp clone w/ it. Really we hope people get creative w/ it! We plan to use it ourselves for other products we have in the pipeline.

          We're giving you the framework to build chat powered features/apps.. We focus on handling all the things that makes chat go(real time updates, socket servers, notifications, queueing, etc).

          You also get the added benefits of ongoing development where as if someone were to build their own chat system would probably stop forward development once the basic feature was in place.

          We wanted people to have the tools to build any kind of in app chat they want. Just like Stripe gives you the tools to build any kind of billing and subscription setup you want. Simple at its core, but programmatically flexible to build a robust chat system the way you need it.

          Ya the use cases section is still a bit rough.. we haven't added any content below the header images.. I'm a terrible marketing writer and hit a bit of writers block!

          Thanks for all the questions, this is already helping A LOT!

          1. 1

            Do you have an idea what the total addressable market is?

            I strikes me that two-sided market places are really hard and rare. Collaborative tools are also at the harder end of software development. The desire for either of those to outsource chat might also be low given the sophistication those businesses require.

            1. 1

              If we also include communities and other use cases we have yet to think of(i'm sure there are more) that would want to possibly offer communication between members I'd say it's large enough to do what we need it to do. I'm not looking to build a Unicorn.

              I'm perfectly happy with a "lifestyle" business. 300 - 500 Customers would pay for both my partner and I to live comfortable lives while growing our business. When I look at those numbers, it really seems like it's within reach.

              So right now we're focused on that goal and if that takes 1 product or 5 products so be it. Death by a thousand papercuts.

              On that note, the other value in this product is it's a toolkit. We fully intend to use it to build other things in different markets we intend to monetize.

              We also have another product we were working on that is going to need collaboration/chat so it was also a product of our future needs. Instead of just building chat for our client and again for ourselves, we decided to build a product we could in turn use and possibly get some further gain from as we go forward.

              We're not looking to be the next big thing so addressable market is large enough for our goals to be met(maybe?)

              If not, like i said, it's something we'll use for ourselves and our clients many times over and if it doesn't work out will probably just be yet another opensource offering we have!

              1. 1

                300 - 500 Customers

                My concern is that it could be tough to even get to that because its not a simple sale - its a critical part of an app's data, authentication, user experience and architecture so even with a perfect implementation its not an easy purchase.

                I am in your collaborative app segment but I wouldn't consider a third-party chat solution because real-time communication is already a core competency and architecture of the app. Integrating a third-party chat solution has significant drawbacks compared to developing it ourselves.

                I hope you keep us updated on the sales process - love to know how you get on!

                So right now we're focused on that goal and if that takes 1 product or 5 products so be it. Death by a thousand papercuts.

                I understand your reasoning but a heads-up from someone prone to doing the same thing... it also sounds a bit like a rationalisation to avoid validating the market before building out the product!

                A two person team does not have much powder to spare so if you can go broad before going deep by competitively validating each of the 5 ideas at once and only then launching the most promising then you would be in a better place than launching 5 products in sequence.

                1. 1

                  The validation came from someone being willing to pay us up front and become a customer and we ourselves needing the product for something else we were working on already.

                  There's really no more validation needed than that for me. Like you said we only have so much powder. My time is best pleasing my clients, and building things.

                  We needed a thing, we had a client willing and ready to become our first customer of said thing with a contract signed before it was done being built. I've been doing this for a decade and I can't ever recount having that opportunity. There is no better validation than someone giving me money. We've seen in this same thread already 2 more people who potentially have a need.

                  We're not shooting in the dark, most of the time your idea isn't original anyway and you can use someone else's validation to build an alternative.

                  For instance if I decided I wanted to build help desk software. Do I really need validation? The same can be said for almost any idea. Very few are original, you just need to execute. Even this idea isn't original, it's just that the viable alternatives are really really really expensive.

                  Modern web development is less about original ideas and more about finding already validated ideas that need to be rebuilt on modern technology or just done a better way. Intercom is a great example of this.

                  Most of our products we have planned have come from our needs or dislikes of other alternatives we're already using.

                  I think sometimes people get to bogged down with the things that aren't going to make them doers. If I spend to much time hemming and hawing over what i'm going to build, I'll never get anything done.

                  As a 1 or 2 man team I need to focus on what works for me. If you're failing fast it shouldn't matter and I always learn something when I build these things.

                  If I was going to dump a lot of money into these ideas other than sweat equity I might take a different approach, but I am a firm believer of the $100 startup. This stuff is fun to me so losing some time to a failed idea isn't the end of the world nor am I going to go hungry if my idea fails. I think that's an important distinction to make. My business will keep right on keepin' on.

                  Those who can, do. Those who can't, have meetings.

          2. 1

            Yep, that is my point, Stripe doesn't describe itself as "programmable". Its not conventional language so requires us to interpret what the term is referring to.

            Stripe messaging tended to be "For developers" or "Tools and API".

            Any of "User to user chat Toolkit/Framework/Platform" would communicate what I need to know. They all imply the programmability a developer needs.

            1. 1

              Ah yes, makes sense. Thanks! This is where both my partner and I really struggle. Choice of words. Looking at Stripes landing page has given me a lot of ideas.. Think I'm ready for revision round 47 :P

              1. 1

                One tip is to use wayback machine and see how it evolved over time. The messaging when you are a market leader tends to be a lot different from when you are truly unknown and trying to explain something new.

                1. 1

                  Really great suggestions.. thanks again.