Why You Should Build Yourself It can be easy to think that you’ll just pay someone else on Upwork, Fiverr, or to build you an amazing SaaS that will blow the competition Reason #1: The Cost
Let’s say MVP takes 100 hrs to build That’s $3500 that you have to make for the break even cost That’s not even including maintenance and building more features. Which you’ll 100% need These costs can add up to a lot of $$$ Reason #2: Speed
On a regular day, wak up, burth teech and make coffee. Then log in to check customer emails. There is always a fix to be done or something technical to investigate. For most of these, I’m able to finish it in just minutes. Dont have to contact my developer (even worse if they are in a different time zone) Quick fixes can shock customers It have given so many happy users and some great reviews If you compound it, I make 1-5 changes a day. That’s 365 to 1,825 a year. That’s a fast pace Imagine trying to message your developer 1,825 times a year Building In Public, Going, Open Source and Stealth Mode Building in Public (bannerbear)
The practice of openly sharing the process, progress and challenges of creating a product, business or project with the public, often through social media, blogs or other online platforms It can be a great marketing technique. It’s better when you’re small and worse when you grow But is going to depend on your audience Going Open Source (plausible)
Sharing the source code so that anyone can view, use, modify and distribute the work You’ll need a really compelling reason to do so It becomes much harder to monetize an open-source product Stealth Mode
This is here you “hide” or don’t tell anyone about your product until you launch so no competitors can steal your features You wont know if anyone actually wants your product until you release it What Tech Stack Should You Choose? For hosting, pick an established provider to ensure they will stay in business But other than that it doesnt matter. Work with what you know Your customer doesnt care whether you are using the latest framework. They only want the product to solve their core pain point or issue. Why stick with what you know?
It will slow you down trying to learn a new framework. Slowing down your process from getting value into the customer’s hands It will also decrease your motivation Building Addicting Products with the Habit Loop You should be embarrased by what you release but it should be functional You dont want a buggy product Dont worry too much about the UX or the “perfect” product design You should only be solving what you’ve determined to be the core problem What are the steps?
Identify the core features Determine the essential features that your product must have to provide value to your users These should be the most critical and fundamental features that address your target audience’s primary needs Trying to solve the core problem. Users should be able to sign up, solve their problem and that’s it. You dont need anything else Design is secondary here as long as it’s usable Focus on excellence but only on one thing Consider the programming languages, frameworks, libraries and tools that will best suit your product’s needs Plan how you will store, organize and manage the data that your product will collect and use. Define the database structure and the data model to be used How can you launch as fast as possible to test your core assumption of the product? Does this feature really need to be included? People tend to think of this as an excuse for being half-assed. But you should be embarrassed about what you release. If you’re not you released too early. It’s balancing act between the two Effective Product Onboarding It’s how you guide and handhold your new user from the beginning state (nothing is set up) to the end state (everything is set up) and they are happily using the product When the user can get the “aha” moment or understand what is working Ways to do this?
Provide learning guides and knowledge databases Setting Up Recurring Subscriptions 
Building Your Product
