Dan Gusz Profile picture
7 Dec, 101 tweets, 37 min read
In honor of being hunted on 🐱 @ProductHunt today by @felix12777, we wanted to highlight what we have learned on our #nocode journey.

It has been 104 days from product signup (@AdaloHQ) to Product Hunt, so here are 104 learnings:

πŸ‘‡
1) To start, we had to figure out as a non-technical team how to build a technical product to lower the cost of #career navigation
2) We started Lloyd before the pandemic was the reality it is today, but what has happened in the last year made us even more committed to building a lower cost, quality product. #Nocode was a fast way to keeping costs down to also benefit others
3) @nkgusz started us on @AdaloHQ. While Nikki has been the non-technical advocate for #tech innovations throughout her career, she hasn't built. However, @AdaloHQ changed that and allowed her to build, too #womenintech #femalefounder
4) Truly anyone with an internet connection can start to build #nocode tools
5) We believe that #nocode gives builders 4 core superpowers: [A] when starting, you can experiment / iterate fast, [B] databases won't be your enemy, [C] once you find your path, you are more cost effective than ever before, [D] as you scale, most tools scale with you
6) #nocode building also comes with a few core downsides: [A] you become very platform dependent, so pick tools carefully, [B] things like speed or design (to an extent) can be out of your control and you have to accept what you are given
7) Cost is one of the most important metrics to consider when delving into the #nocode space. This may be weird to say as a #nocode users, but I think that no code tools are extremely under priced
8) For $100 / month you can have a fully branded, fully functional #nocode application: Adalo for $50, Parabola for $15, Figma for free, website + Google Drive for ~$20, misc. for $15

(cc: good piece by @d__raptis on this topic)
9) Just think about that. A fully functioning application, built by you, for the cost of one dinner out. That's incredible. I truly do think that #nocode will have some impact on the #VentureCapital community because these companies take a lot less capital to get started
10) If the start-up costs for a software company used to be perhaps $50,000 - $200,000 and now for some companies that is $1,000 - $10,000, we definitely are entering a new age of company building!
11) This allows for more individuals from a broader set of backgrounds, education levels, income levels, and geographic distributions to build products that users love!

12) I find #buildinginpublic to be first and foremost about personal accountability
13) Re: @parabolahq, probably the best combination of intuitive + powerful for any #nocode tool
14) Re: @figmadesign, I love their product, use it a lot, and somehow I'm still on the freemium plan. I am starting to feel like I am abusing this relationship.
15) Re: @AdaloHQ, this tool has been that binary zero-to-one for us from a product standpoint

16) Re: @AdaloHQ, let's start with their team - we have found their team to be incredibly helpful, responsive, and devoted. Thanks!
17) Re: @AdaloHQ, when we first logged in on August 24th, we didn't have a full plan. We just knew we wanted to #build.

18) Re: @AdaloHQ, a fun little thing that we love are @LottieFiles. They bring the product to life - I highly recommend.
19) Re: @AdaloHQ, same goes for @unDraw_co: these images do a great job of humanizing the product - also highly recommend.

20) Re: @AdaloHQ, one aspect we were most intentional about was our onboarding flow. Make it fast. Make it simple. Make it informative. Uhhh, that's a lot.
21) Re: @AdaloHQ / onboarding: this was a constant evolution for us. We probably have been through 5 wholly distinct onboarding workflows.
22) Re: @AdaloHQ / onboarding: we have tried videos, click through / hover-text education, and now allow users to schedule time with our team to speak with us directly for 1:1 onboarding (inspired by @Superhuman)
23) Throughout this process we have learned a lot. Here are 20 mistakes we made, to be used as guides so hopefully others don't make the same mistakes as us!
24) Mistake #1: we tried to always reinvent the wheel. If you are building with #nocode tools, you advantage is often speed, flexibility, and cost-effectiveness. Try to keep yourself fast by using other tools / products as strong inspiration.
25) Mistake #2: we didn't consider the user journey. Our initial onboarding workflows just landed the user in the product, without enough "wins" early for them to feel comfortable. Walk the user through their first "win" or use before letting them off on their own.
26) Mistake #3: we tried to recreate existing communication channels. Why were we building a native chat app when users just wanted to chat via email? @mondaydotcom nicely pushes all communication to email notices as well, vs. demanding in their app. Good inspiration.
27) Mistake #4: not delving into the power of #nocode APIs earlier. This was a game changer for us. @zapier webhooks are great, but *USUALLY* require some event to happen before executing. APIs with @parabolahq and other tools help truly automate our product.
28) Mistake #5: not "sitting over the shoulder" of users sooner. Try to do video screen shares with users as early as possible. Better yet, have users record a @loom of their experience in the sign-up process. You will learn a lot.
29) Mistake #6: overcomplicating our website. Previously we emphasized more information, which created complexity. We now emphasize clarity, simplicity, and direction to our product: withlloyd.com.
30) Mistake #7: as Confucius said, "β€œBetter a diamond with a flaw than a pebble without.” Make your #nocode tool a flawed diamond, not a perfect pebble.
31) Mistake #8: not coming up with design standards earlier. We had a lot of back and forth on font size, color, weight--wastes of time. We quickly figured out a good set of general standards, colors, etc., which allows us to move faster.
32) Mistake #9: not adding examples, examples, examples. Every career is unique, but examples of what other experiences help people start at 1 instead of 0
33) Mistake #10: not starting sooner. I think this can always be a mistake in hindsight, but because the barrier to entry are so low for #nocode tools, it is worth it to get started early. For instance, just start with your login flow. Start small, but start now!
34) Mistake #11: taking WAY too long to get to our Hero feature (most important feature). For us, that is the human co-pilot along with the technology. This should have been our first discussion, and should have been the North Star we followed in our initial build
35) Mistake #12: not working with contractors, even for a few hours, to learn best practices. We will probably do this starting in the new year to take our app to the next level. Even a budget of $500 can go far.
36) Mistake #13: iterating our messaging TOO MUCH. We have had a tendency to use a lot of one-liners to describe the business, and then move on to a new one next week. STOP THAT. Bounce a few ideas off of folks, pick one, AND USE IT.
37) Mistake #14: considering scalability too much. If you don't have even 1 person using and liking your product, scalability MEANS NOTHING. It is hard, but we had to retrain ourselves to really focus on the here and now, and push of scalability discussions for later. Not easy.
38) Mistake #15: getting too caught up in what others are doing. Did you see what that other company raised? Wow, look at their user growth! STOP IT. You need to shut it out and focus on what you're building. Market awareness is good, but FOCUS on you!
39) Mistake #16: appreciate the small wins more often. When you get your first paying customer, celebrate (a little bit)! When you get to $1,000 MRR, open that bottle of champagne. The journey is irreplaceable - enjoy the ride.
40) Mistake #17: not engaging on Twitter earlier and more genuinely. Many people have written how, and frankly we're not that great at Twitter. All we know is be genuine.
41) Mistake #18: over indexing on work from home and other trends in 2020. Yes, we all need to be cognizant, diligent, and active! But despite the uncertainty, there were key things we just needed to build / execute. Not always easy.
42) Mistake #19: worrying about raising money too early. Yes, being well capitalized is important. But only if raising money is right FOR YOUR business. The venture model may evolve with #nocode (due to lower capital needs), so be open to lots of paths.
43) Mistake #20: not having enough fun at times. Building should be fun. Sometimes hard to manage with a small team wearing many hats, but a mix of serious and fun is key. Don't forget the fun, especially at such an early stage.
44) These mistakes, in some part, could have been alleviated if we had had a stronger database strategy from the get-go. Where is the source of truth, how does all of the data connect, etc.
45) And if we are going to be honest, we probably broke the #1 rule of #nocode: we don't, and haven't ever, used @airtable. Gasp!
46) For us, the @AdaloHQ database was homebase #1.
47) Using the built-in @adalohq database is a two-sided coin (as I imagine for other build+database tools): the plus side is speed speed speed.
48) But seriously, that is the biggest consideration. If you watch a <10 min. Youtube video (e.g. ), you will be properly prepared to getting started.
49) In my mind, this may be one of the biggest leaps that #nocode has enabled. By not needing to really worry about database structuring to get started, you can focus on building. Otherwise, there is a lot of mySQL to learn just to get your company started. Ugh.
50) But when signing up for tools like @adalohq (or similar tools like @bubble or @glideapps), you can genuinely have a working product for others to use in under 60 minutes.
51) Do you not believe me? I just tried this out again and it is true. Go to one of the links below and give it a try and then come back and share how long it took you πŸ‘‡
app.adalo.com/signup
bubble.io
glideapps.com
52) OK back to regularly scheduled programming. It turns out the downside to the built-in database is also speed speed speed. Speed of processing can definitely be noticable, though I'm sure we take our fair share of blame there with some design considerations.
53) Not having the most "blazing fast" database to start really shouldn't be any concern for *nearly all* #nocode applications to start. Just have this in mind as you move forward, and make sure to properly ask your users if speed is any issue.
54) Similar to database structuring, we found (and probably like many others) that design is hard! Duh!
55) After lots of scrolling through #designtwitter, @dribbble, and @canva, here is a look into our crude design process.
56) To make products feel "alive", we use either @unDraw_co (❀️) or @LottieFiles (❀️ ❀️). Both do a phenomenal job of making the product feel more professionally done, even if you have few design skills (like us)!
57) I'll actually just say it again to emphasize to you: @LottieFiles is a gamechanger. Go show @Le3Sharon, @reallynattu, and the team some love.
58) Our design process: we stay within our skill sets and keep it simple: helps to find 2-5 product feature inspirations from others, align on the "target" for what we are going for, and then understand that we need to work within the constructs of the tools we are using.
59) For any images that we are making, we use the freemium version of @figmadesign. We use this sparingly and the freemium version is plenty (and very generous) for us.
60) For .gifs, we found this great simple tool using @figmaticapp (within Figma) called "TinyImage Compressor". Highly recommend.
61) For videos, we probably are a bit old school here. We used a created to build our entrance, and just use iMovie to clip together images, recordings, etc. This is probably one area where we have a lot of room for improvement.
62) Honestly, design isn't our core skillset but does matter as a D2C company, so we're grateful for tools that make it easier. We choose to try to be in the middle of the pack for design (aka not a detraction) and win in other areas. A tradeoff we made.
63) Switching gears a bit, so what happens if you need to code in your #nocode tool?!?!?
64) Based on our product specs, this has only really come up in two areas: [A] editing some already created HTML using tools like @Designmodo, or [B] slight tweaks to JSON for some API calls.
65) In both cases, our first step was to recognize that we probably can do more harm than good by writing code ourselves. In the case of HTML, keeping the HTML we creating for further custom edits to obey full brand standards wasn't worth it for us.
66) My encouragement is to not be intimidated by getting into the weeds with any code (if you are an actual developer), but just remember you likely can do more harm than good to tread carefully!
67) There is a third area where we have used a bit of code, but honestly, to not much success. And that is with @squarespace. I'd say it is a love/hate relationship.
68) Our origin using @squarespace as our marketing website was because, well, it was easy and I've heard their ads on a lot of podcasts. I guess marketing does work!
69) My honest recommendation would probably be to use other tools for your marketing website that are: [A] more data interoperable (SquareSpace has limited connectivity for billing data, for instance), and [B] better off-the-shelf templates.
70) I've spent a decent chunk of time trying to mess around with their CSS and honestly it probably just isn't worth your time. I haven't used it, but people seem to rave about carrd.co. I'd try that tool or others before starting on SquareSpace (despite the ads!)
71) OK moving on from design, let's talk about πŸ’°. We originally started as a free product, so didn't have anything here. When we started our paid product, here were the steps that we took.
72) πŸ’° We started simple and opened an account at Chase (could have done SVB as well). We then setup @stripe, which literally takes about two minutes.
73) πŸ’° Embarrassingly, we actually have two payment systems. One via SquareSpace / Stripe and one via Adalo / Stripe. Both go to the same Stripe account, but this is a bit of tech debt we have accumulated already 😒
74) πŸ’° @stripe is as good as all of the hype. Couldn't be easier for such a complex task. We experimented with tools like @MemberstackApp but didn't need it for our use. Honestly though, I'd recommend that product for a lot of other use-cases.
75) πŸ’° @Stripe is probably the finance equivalent of the built-in database advantages from before. It used to be a significant barrier to entry - now it is a simple step and you're on your way!
76) When it comes to tradeoffs, perhaps the biggest tradeoff with #nocode tools is your platform dependence. Let me explain with an example...
77) In October @adalohq experienced outages (nicely documented here: adalo.com/posts/scaling-…) in which many of our updates were rolled back, slowness ensued, etc. etc. etc.
78) We probably lost 6 hours of work and had to put a pause on new development for about 3 days. This was out of our control, not in our plan, and pushed back a couple timelines. AND THERE WAS NOTHING WE COULD DO.
79) I give @david_adkin and team a lot of credit for how they handled the situation. Class act, honest, transparent. It is a good example of why picking your platforms carefully is so important in #nocode. You get platform dependent very quickly.
80) Could we have done anything differently here? Probably not. Recently a few of our data connector tools went down and that put our whole operation to a standstill for about 12 hours. I recommend that you build this understanding and flexibility into your product.
81) Something else we have tried to build into the product is more obvious: automation. To start, we were pretty bad at this. A lot of manual processes to compare lists, change formats, etc. in Google Sheets and then allow a process to continue from there.
82) I think this is a pretty common use-case for #nocode tools. For instance, any type of booking app or social app will need to do some reconciliation of lists, and send reminders or follow-ups to a portion of the list (e.g. hasn't paid yet)
83) Our instinct when starting (as with many other people), is "well, it is just one manual process this week." One manual process turns into 10 though, and mistakes get made, you get busy, and the product experience gets diminished.
84) @parabolahq was our solve for this. The in-app logic functions to do anything from a VLookup workflow to finding the difference between two sets of data, performing logic / calculations, etc.
85) This has been a really important step for us to automate pretty much all of our manual, one-off steps. I can even see how this type of automation would have been helpful in my past companies.
86) There may be other tools similar to Parabola that do a similar job. We found this tool and just stuck with it. As with, if we are going to be honest, most of the tools we have selected :)
87) With all of these positives we should also talk about a few of the key downsides and other tradeoffs of #nocode. To start, who is #nocode NOT for?
88) #nocode is probably not for apps in highly regulated industries like healthcare or finance where there may be very stringent data security regulations. Be thoughtful if you work in those industries
89) Data security is a tricky part of #nocode tools. Most of the mainstream tools seem very secure, but if you are dealing with sensitive information like Social Security numbers or sensitive healthcare information, moving data between apps may be an issue
90) #nocode may also not be for someone with very specific design requirements. In that case, you may want to have a custom frontend and connect to some backend #nocode tools.
91) #nocode is also not for someone who doesn't want to get their hands dirty. If that is you, you can outsource your #nocode building to experts (e.g. @minimumssstudio) for probably less than <$10,000. It still can be a lower-cost way to get something built.
92) And now for a few failures. What are some things we tried and just couldn't get to work? It isn't a short list:
93) We couldn't get Email Parser from @zapier to work. We tried a bunch and just couldn't get it to work, though we wish we had. Looks incredibly useful for our business.
94) We also failed with @webflow. Webflow seems to be everywhere, and their templates look AWESOME. We probably should have spent more time with it to learn, so this is our fault. Perhaps one day we will dive into @webflow in earnest.
95) This one is ongoing, but we have struggled with marketing and branding. Like I said earlier, we needed to commit to our messaging Waze for your career) earlier!
96) In terms of breadth, we have only tried and used a relatively small number of #nocode tools. I almost wish there was some sort of #nocode speed dating where you can get a feel for a bunch of tools before planting your flag on the one you want to use.
97) When we now think about moving forward, we have learned a lot about how to plan for the future. First, a huge priority for us is increasing user engagement. Narrowing our scope of features and creating more value for users in that smaller universe.
98) #nocode tools allow you to build a lot, which sometimes can actually be distracting! We are now limiting what we build in an effort to spend more time with end users, educate users on the product, and make smaller, more strategic iterations to the product
99) We have learned (a bit the hard way) that just having more to the product doesn't mean the product is better. As we end 2020 and head into 2021 streamlining the product and emphasizing power users is our focus.
100) Focusing on a much smaller list of super high impact features, and reserving more time to spend with customers, understand needs, and grow with our users. #nocode allows you to iterate quickly, but don't turn that into a system of running around in circles. Be smart!
101) And finally some thank yous. 1) thank you to all of the builders who have built these amazing tools. 2) thank you to the #nocode community for being so inspiring and inclusive.
102) Folks like @rileyrichter / @laceykesler / @mattvaru / @colinwinhall / @thisiskp_ are very active and have been helpful to us in finding resources - thank you!
103) 3) thank you to @felix12777 for hunting Lloyd. 4) thank you to @HainingMax for building and inspiring the community (@100daysnocode). So to everyone: be confident and keep building!
104) So to everyone, keep confident, and keep building! And if you made it this far and have 30 seconds more today, hop over to producthunt.com and give Lloyd some feedback!

β€’ β€’ β€’

Missing some Tweet in this thread? You can try to force a refresh
γ€€

Keep Current with Dan Gusz

Dan Gusz Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @Dan_Gusz

7 Dec
We think a lot internally about what it means to be a mission-driven company. Here are a few lessons we have learned, and who we have learned from the most πŸ‘‡
2/

"Your current product is just one execution against the mission" is a phenomenal quote by @leifthunder.
3/

Let that quote sink in for a second.
Read 13 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!