I want to share with you all my reflections, lessons learned, and experiences as a nontechnical founder building software for those of you in a similar boat to learn from.

After ~2 years and several early startup programs, I learned about how to get a business off the ground. But, after that early stage, I found myself yet again like a skydiver without a parachute. I was continuing on my startup without any structure, program, or the right advisors. Hence, I made some mistakes and I now have some important lessons learned…see below.

Readiness

In these early programs, all I kept hearing was “don’t code until…” and then some variation of describing “readiness” to code. Usually, people would talk about doing a proof of concept, a no-code prototype, gaining users, gaining early revenue/traction, proving out key value metrics, etc. And, we did all of that!

After that, I figured the next step was coding a custom platform. We knew the tools our current prototype was built on weren’t scalable, sellable, or nearly user friendly enough. That was legitimate feedback (to increase “UX” and user-friendliness) but it was just a matter of how. After this early positive traction, we were ready for the next step, and because I kept hearing “don’t code until…” I thought the next step was to code.

What I Wish I Knew

What I wish I knew at this time that the best next step (for a nontechnical founder) was again, another (but better, more advanced) no-code tool. Up until this point, our prototypes were on Google Sheets, which was truly impressive and hilarious how much we built, designed, and sold in that format. I wish we “kept listening” to the advice “not to code” but I only briefly looked into no-code tools and thought it’d be a better long term investment to start coding versus using another “prototyping” tool. Boy was I wrong.

The issue with coding is that it’s a long, expensive process, that didn’t end up allowing us to quickly learn/test/iterate, nor did it result in a strong quality product. Coding a quality product truly does take time and strong talent to do well. Our product wasn’t technically complex, so we didn’t need an expert engineer, but we did need a strong pre-code UX process, and this was another major mistake we made. Had we done the proper UX process, our journey of coding may not have been as difficult and may have indeed been the right long term investment to make, so take this entire lesson learned with that grain of salt.

That being said, when I think about the time it took is to learn from our mistakes, to build (code) and then learn (reflect) on how that was going and to get user’s feedback, it truly took way too long. Quite frankly, I don’t think I’ve learned much more than I knew when our clients were on our prototype. It’s so easy to get wrapped up in how long coding takes and to simply wait it out or keep looking towards the next step, or the next week or month as what will “get you there,” but in pursuing this goal of a custom platform, I lost the concept of how important it was to build and test quickly. Let me share our brief timeline so you can see what happened when I became too much in the weeds, continuing to hold on to a process that wasn’t working, before I finally “let go,” scrapped our product/process, and started over.

Timeline

• Spring 2018: Sketch/Invision Prototype Built
• Fall 2018: Google Sheets Prototypes Built
• Spring 2019: Tested Google Sheets products & started charging for it
• June-August: Started coding with undergraduate interns — never do that.
• September-December: Finally leveraged an expert engineer and got a custom platform up and running
• December: Moved clients onto the new custom platform
• December-February: Tried to leverage an outsourced engineer — this was a complete fail. Be careful about choosing this option. If you feel it could be right for you, test it quickly (1-month maximum) and assess whether it is a promising, productive, sustainable plan.
• February: Finally got the right advisor to “wake me up” and make me realize how awful our UX was.
• March: Started redesigning our platform and realized that it’ll take another 3–6 months to fully rebuild/recode it all properly.
• April: The plan now is to start rebuilding with more advanced no-code tools (webflow, etc.). This will likely only take ~4 weeks. We will finally build something effective and user friendly for our clients, and we will do it comprehensively and quickly. We’ll be able to finally build something we could sell widely, both b2c and b2b2c. Something we trust enough to unlock and unblock our ability to focus on growth. Keep in mind, we still haven’t yet achieved this goal, but I’m only now ready to try and pursue this avenue.

Overall, we wasted 11 months — and a good chunk of our budget, too. That is an INSANELY long time. Reflecting back makes me regretful and really upset. I cannot afford that time. Here’s why I think deep down this may have happened:

• Entrepreneurs can often self-sabotage
• Sometimes we just don’t know what we’re doing and we know we’ll learn from our experiences either way, but we take way too long to feel ready to learn that lesson.
• Sometimes we’re just eager to realize our final vision and take what feels faster but is truly an ineffective route to get there.
• Sometimes we apply the advice we’ve heard more narrowly, rather than in a broadly applicable way.
• There were only perhaps 3 times someone mentioned to me the idea about “no-code” tools and I wish I took them more seriously and/or they shook me and I had the proper advisors to watch what we were doing and help us get out of that mess.
• I was eager to code because I felt it would get us to the “finish” line, to jump to a process that could actually produce my ultimate vision. But it became more complex, more timely, and produced worse outcomes.

Lessons Learned

Through all of this, here are the major lessons learned:

• Coding proved to suck me into the weeds, in a way that made me constantly want to keep pushing to the next thing (next hire, next week, next month) to fix it all. I underestimated the time coding an effective, next version of our MVP would actually take.
• Coding is never a fast process. And often, it’s not as effective to build what you want.
• If your product is not technically complex, stay on tools that will give you speed and user-friendly products.
• Never underestimate or under-learn about how to properly utilize UX processes and best practices.
• Make sure that after your proof of concept, you hire the right talent. As a bootstrapped startup, we simply leveraged anyone who wanted to help, but you need to double down on speed and the proper skills and talent once you decide that your business has legs and is worth continuing. In the early days, any help is often better than none, but as you continue, be more conscious with exactly what skills and expertise you need to take you forward.
• I realized that the best possible thing we should’ve done was to avoid code as long as humanly possible — as everyone had told me. I wish I looked into, realized the strength in and had greater trust in these no-code prototyping tools.

You may be asking, “so what are these no-code prototyping tools?” Instead of listing some examples, I’d rather encourage you to find what would work for your product/service by explaining the concept and purpose of what I’m saying, and have you figure out the best, quickest, low-cost way to continue advancing your product, without coding.