Use these simple low cost no-code tools to create a working first version of your product idea

What is it:

Print my return label

What did I learn:

1. Product Strategy: Lean Side Projects - What advantage can this stack give you? Great starter stack to launch a new idea. When you're creating something new, it's our natural tendency to wait to launch and over-develop. Years ago, common wisdom was validate your idea not by actually creating the solution but faking it. Common advice was to set up a landing page with a button to buy that product or service. But not actually allow the user to purchase, instead put up a response that the product wasn't ready and to leave your email for when it will be ready.

Gone are those days.

Today no-code is a game-changer. The value of no-code is speed to market. You can now create a professional looking product or service, with low learning curve tools that actually create a working solution in a very minimal time.

This stack is perfect to design an actual experience to get real validation not just for demand of your product but test out if your solution is actually feasible.

My recommendation is that instead of creating a prototype or some lower fidelity mock up, just create it. Just ship it. Using The Lean Side Project will help you create something and the closer you get to the real thing, the greater validation signal you will receive if people really want your product or would pay for it.

2. No-code tool feature: Typeform - Typeform was the go to form builder. Now it is become so expensive there are other form builders to consider. I would say that if you can use Typeform's free plan or lower cost tier plan it would still be my recommendation because it is proven technology, and is less risk. Typeform sits at the bedrock of so many of my applications that it is something that is really solid I rely on. But if you are just starting out and testing an idea, why would you incur the cost when there is so many good form builders available?

Here are a few that I would scope out:
1. Niro
2. @aidaform
3. Surveysparrow
4. Tally.so
5. Paperform

Here is some selection criteria I would use when using these:
1. Free plan or minimal cost
2. Do you need logic jumps? (this means presenting different questions based on how the user answers)
3. Do you need to score the answers to create some type of personalized answer?
4. Need an easy way to integrate with Stripe or payment? Gumroad is usually the easiest way but if you want to ask some questions and then within that form receive payment, Stripe can be used for that.

There are a lot of other use cases for these, but these are some fundamentals and main ones I see many Makers use forms to help them.

3. Product Strategy: Launching your first product does not need to be all automated. One of the first products I made I was more interested in automating and building the product then validating it. It's no wonder it failed.

I think that if you can pick up lower learning curve tools to set up a simple product that you should do it. But don't get locked in to having everything 100% automated. In this stack by David you can see that the front end of the product is automated and set up to take information. All those tools used are lower learning curve tools, where it's something that you can reasonably pick up quickly and then turn around to get real users to provide feedback.

Carrd, typeform, airtable and zapier all fit that criteria. Based on the output of the product, it appears that David then has one non-automated step in actually mailing out the product. I don't know if you can automate this or not, but the principle still stands, don't go fixing everything unless there is a problem with something. Because if you spend all your time trying to get everything right, you'll never ship your product and you won't actually know where you need to spend your time on to provide value to your users.

For example as a Product Manager, we evaluate the impact of all new enhancements and all bugs that crop up. We never complete all our bugs. Because we have to evaluate the impact. And because resources are finite, we have to evaluate how much is this bug really hurting us. You'll never be able to make that judgement if you haven't shipping your product and gotten feedback on how your users are actually using it. Once you know how they use and where the gaps are you will then know how to priortize what to automate.

Another example that is pretty famous is how Stripe strated. When they first started, they didn't even automate the credit card charge. They actually had someone on the backend manually run the credit card for the charge! Can you believe that.

Don't conflate this with doing things that don't scale. This principle I have learned here is validate>>>>building>>>>automating. In that order.