Growth October 19, 2020

Developer marketing advice for a software engineer (ex-Google/Twitter)

Tiago Bandeira @tiago

Hi all,

My background is in software (ex-Google/Twitter). I'm struggling to market my MVP. It's not my strong suit. Any advice is really appreciated.

I made a developer tool called Create Full Stack (CFS). It initializes a full stack for developers including:

  • AWS deployment
  • CI/CD
  • Web, native mobile, and server (Hasura or Apollo) TypeScript boilerplate
  • Code linting/formatting
  • Authentication with Auth0

http://create-full-stack.com/

I was lucky, and a developer advocate from Hasura (a GraphQL/Postgres backend as a service) found my project on GitHub, reached out, and had them tweet about it. The tweet got some traction (65 likes and 30 retweets) but I'm still struggling to find users.

I've tried posting it on HN and PH but I'm not getting much attention or I botched these launches.

I plan on posting to HN again. Titles are tricky there with very limited character count. Thinking:
"Show HN: TypeScript Apollo Hasura React RN full stack boilerplate w/ AWS deploys"

I'm reaching out to developer influencers and companies like Expo which I use in CFS with no success so far.

What else is recommended? Considering SEO and guest writing for blogs. Any advice here is super appreciated!

  1. 2

    Hi Tiago,

    I’m not in your target market, but I found it difficult to understand what it is and what it does from the landing page.

    From what I can understand, it kind of does what Meteor.js did except you’re not bound to a specific database, UI framework, etc.? When I saw you that you mentioned Apollo, I was immediately reminded of Meteor.js, and it never got much easier than that for web development.

    Please take my advice as just 1 opinion and not an expert:

    I would guess that most brand new startups would not use this and most enterprises would not use this (at least they won’t be your first users). I would guess that your target audience are startups that have received some traction but have not reached a maturity stage (that seems like the window where you can implement this without slowing down to learn something new or where it requires a massive change in 100’s of applications / services)?

    You may agree or disagree with the above, but I think it’s super important to narrow down your first customers to a very specific segment because it can be exhausting to chase multiple groups because how you find them is very different from segment to segment.

    Who do you think this is most suited for?

    1. 2

      My landing page assumes the reader has some knowledge of the underlying tools since they're required for the developer to know. I could cast a wider net if I didn't mention them and only the problems I was trying to solve but I felt like developers would appreciate the technical details. I feel like it's necessary at least for the first customers. As docs improve this can change.

      I agree an established enterprise will have its own toolchain and it's infeasible to switch over.

      I'd like for this tool to be useful for people just starting out and it would scale with them. Do you feel the complexity of the toolchain prevents that? Ex. Hasura vs Firebase or AWS/Pulumi vs Next.js?

      1. 1

        Only for me personally, I would build in whatever is the quickest in the very early stage because I simply don’t know if anything more than that will ultimately be a waste of time (think like 90% of startups / apps, etc fail). For me, I would use node.js on the backend, html + css on the front end, and use PM2 + Cloud 9 on a VM to serve. I will diverge from that depending on the case, but I would never pick up something Create Full Stack simply because of the upfront investment required.

        The are only 2 places I would consider it:

        1. If things started to work out, I would definitely re-evaluate my setup and that’s the point where I would be open to something like CFS.

        2. If I became that it was super quick to proto-type in, it would become my approach like the above. It used to be Meteor.js, but I moved away after it seemed like the company that made was stepping away from it.

        For me personally, it really comes down to an investment of time. I’m only willing to invest in trying something new when it seems like the long-term payoff will be worth it, or my current approach is currently unattenable.

        BTW, I thought another possible segment that might be interested would be the smaller development shops. This definitely seems like the type of things they probably build anyways to be more efficient with client jobs (at least the ones not intentionally trying to milk clients for as much money as possible).

        Also BTW, I never used Firebase because I just don’t like the idea that I could wake up tomorrow with a $100k bill for some stupid mistake I made. IMHO, the cost of my infrastructure should never be more than the equivalent cost of VM’s.

        1. 2

          Gotcha.

          You have a set of tools you know and love and it's fastest to move with those. If they become unmanageable, you'd look at alternatives. Likely replacing only the pieces that aren't working out?

          Dev shops make sense. That's a great insight.

          1. 1

            I wouldn’t say only replace pieces that aren’t working. I would consider a wholesale different approach, but I would have to be sold on these points:

            1. it’s going to reduce the time it takes to prototype something by 30-50%, and
            2. whatever it is, it’s going to be around for a while and other people are getting behind. I’m not a band wagon person, but using Meteor.js as an example, it takes time to change to something, and you don’t want to hear that 6 months later, “sorry guys, we’ve had a great ride, but we’re discontinuing this.”
  2. 2

    I kind of wonder if it’s too niche.

    I’m a software engineer and only know what 3/4 of that stack is. No idea what hasura or Apollo is.

    An example of someone nailing it in this space is Gabe from divjoy.com.

    “The React code base generator”.

    1. 2

      Too niche in the sense that few people are starting projects from scratch or they already have a strong sense of the tools they want to use?

      Thanks for sharing! I hadn't seen divjoy. I like their web design a lot. An encouraging sign that at least some people are willing to spend $100 on this.

      Their dropdowns are nice. It gives you a preview of what selection is available. In mine, you have to go through the CLI. I could include dropdowns on the website and display a yarn command with the right flags.

      I had originally included Firestore/Firebase Auth but found it really simple to set up so thought it didn't provide as much value. Mine is more production-ready with AWS and CI/CD support (both quite complicated to set up on your own). Mine is also broader since it includes native mobile boilerplate. I'm concerned, however, that hobbyists may want to start out on Heroku/Netlify/Next.js. Their pricing models are better than pure AWS for starter projects.

      1. 1

        Too niche in the sense that the tools/frameworks chosen may not be mainstream enough in the configuration to attract enough people. But I’m not sure. GraphQL space has definitely exploded in popularity.

        The AWS and CI/CD support is definitely pretty cool though. I know setting that stuff up can be a pain. I agree though that a lot of folks might want more control of where they deploy the stack.

        I think it really comes down to how can you find the audience for your product?

        Where do people interested in that stack hang out?

        I’m still figuring this out on my end as well.

        @Gabe from divjoy might have some interesting insight to give though!

        1. 2

          It's certainly an opinionated selection of tools. Everything seems to be growing in popularity (GraphQL as you mentioned, TypeScript, Hasura, infrastructure-as-code). I'm pushing these because I truly believe that this stack is the best but I can see how that can alienate people vs a larger selection of tools people may already know.

          Yeah, I don't know where to find them. That's why I'm posting here. I'm considering writing tutorials to teach people these tools to make it all more accessible.

  3. 1

    I’m familiar with all the tools in your tech stack but would suggest you focus on a tiny niche—a particular customer segment—then work your way up as several commenters have suggested.

    I’d say go for a simpler title in your Show HN. Something like "Show HN: Full stack starter pack for your next Hackathon".

    If you think about it, a hackathon is a great way to try out an opinionated starter pack because it is a low risk situation for experimenting with unfamiliar tech. If you nail the common use cases (authn/authz, API, analytics), you’ll gain repeat users and rave reviews on Twitter.

    1. 1

      I like the idea of targeting a customer segment. Hackathons are good because of the constant repeated use.

      You'd use these tools for a Hackathon? I may prefer something like vanilla JS instead of TS and Firebase instead of Apollo/Hasura since you're not building something to be production-ready and can cut corners.

      1. 1

        Yes, if you strike the right balance between familiar tools and ease of hackability because sahat’s uses a familiar stack while being batteries included.

        1. 1

          Gotcha. Thanks for sharing.

  4. 1

    Don't mean to sound mean, but you seem to assume your product is perfect and you just need more users. It's rarely the case that a young product is perfect. So let me ask you this: how many users did you interview thus far? Did they really need it?

    1. 1

      Of course, it's not perfect. There's a lot that can be done. I really believe in these tool choices though. I wrote about why a year ago:
      https://medium.com/@tiagsters/one-full-stack-to-rule-them-all-5ca39ded16c1

      I think these may have a more production/professional audience than something like Divjoy. Ex. GraphQL, TypeScript, AWS etc. are more complicated than REST, JavaScript, Netlify but scale much better.

      I did about 15 customer interviews with friends trying out the product. They said they would use it but none were starting new projects. All are around senior-level engineers at various SF tech companies.

      1. 1

        I did about 15 customer interviews with friends trying out the product.

        You need to read The Mom Test

        1. 1

          Purchased. Thanks!

  5. 1

    Hi Tiago,

    I'm not in target audience, but here's some quick feedback:

    1. Ask users for feedback on the platforms and communities where your target audience already spends time on, i.e. IH, StackOverflow etc. My assumption is that you are a representative of your own target audience too, so where do you spend time to connect with other developers? Ask questions, ask feedback, don't promote yourself from the start.

    2. Work on your pitch and sales copy. From neither HN title nor the landing page, it's not clear at all what is it exactly that you do... Here's a good resource to guide you https://www.julian.com/guide/growth/landing-pages

    3. Product Hunt doesn't just take the actual posting, you need to create a marketing campaign around it. Matt from Taskable has a good checklist to help prepare for the launch: https://www.notion.so/Checklist-for-Launching-on-Product-Hunt-c282188c52474d0d9d8c0ffb7e26de64

    4. Consider some very targeted ads like Carbon Ads, targeting specific development skills.

    Our team has also built Growth Channel AI where we automate marketing planning, so if you need more data-driven tactics or a complete market analysis, strategy and plan - head over to our site :)

    Hope these help & Good luck!

  6. 1

    Hi Tiago! I can give you some feedback from the perspective of someone who saw your PH/HN launches and looked through your offering, but decided it wasn't for me.

    For me personally, the stack you presented seemed a bit too opinionated / like there was some unnecessary cruft that I wouldn't want to pull into a clean React app to start with. For instance, something like React Native? If I'm building a proof-of-concept web app, I personally wouldn't pull in any RN boilerplate until much later.

    Plus, I've been partial to just writing plain styled-components recently so including something like Material-UI was unnecessary for me.

    Coupled with that, I'd echo some of the other comments that I just wasn't familiar enough with some of the components you'd included in the stack (Hasura, Palumi).

    That being said, something like this is very useful if the stack you present fits with what someone wants and I think you should keep pursuing it! As mentioned, divjoy.com does a decent job of this as far as offering generic fall-back options if you don't agree with their default choices.

    1. 1

      You don't need to pull in RN. There's some selection in the CLI.

      The choices are:

      Backend?

      • Apollo Server Express
      • Hasura

      Auth method?

      • Auth0
      • None

      Cloud platform?

      • AWS
      • None

      React website?

      • Yes
      • No

      React Native mobile app?

      • Yes
      • No

      GitHub Actions CI/CD?

      • Yes
      • No

      Divjoy does a really good job of showing this on the landing page. My tool requires you to run the CLI which is more friction.

      Noted on Material-UI. I could create a plain version.

      Pulumi is only included with the Cloud platform AWS selection since it manages that (it's very similar to Terraform).

      It's a balance between offering a lot of options and striving for an opinionated approach where I can really hone in on making one stack phenomenal. I'd prefer to go for depth but I can see the value in breadth.

Recommended Posts