3
2 Comments

The Technical Founder’s Conundrum

Introduction

Don’t worry, this is not another misleading rant on how cool it is to start your own company and call yourself the CEO of {cool startup name} inc. That’s the article I would have loved reading several years ago. Unfortunately, such “entrepreneurial” literature is intended to serve the author more than the reader -- leaving us young hustlers and hackers with nothing more than visions, or rather, delusions of grandeur. Sad but true.

If you’re not yet ready to hear this, by all means continue reading the guru fluff and when you get frustrated that it doesn't work, feel free to come back and give this a read 😉 With that said, it’s important to note that I am no expert (far from it, actually). However, as I write this I am currently in the coding trenches of bootstrapping an enterprise level SaaS app. Yes, that would be Siterack.

Now, with the disclaimer out of the way, I wanted to take a few lines to discuss what I, along with my other fellow IndieHackers, have come to know as “The Technical Founder’s Conundrum”. Put simply, it’s a double-edged sword, a blessing and a curse. The idea is nothing new, but it was only recently that I began to notice the problem with myself.

A few days back, I was chatting with a friend who was explaining how he intended to validate his business idea WITHOUT creating any software. His plan was brilliant - using a simple landing page, social media, and some manual emails he would be able to test his entire idea and waste no time, money, or lines of code. However, as he was explaining his process, my mind quickly jumped to the database design, the best stack, and what UI libraries I’d use. Then it struck me. I had a problem.

Hammer and the Nail

If you’ve never heard the “hammer and the nail” saying, it goes something like this: “When you have a hammer to work with, everything looks like a nail”. For an engineer, the hammer is your ability to build software. So, naturally everything seems solvable with code. Even trivial issues like talking with our customers - we’ll opt to build a better chat bot (though there’s likely a product to be had there… just saying).

Of course, there is nothing wrong with problem solving, and being a builder at heart. The real issue lies is our approach. To demonstrate, let’s turn this into a mini case study. Imagine you are the leader of your business and you’ve been selling products to customers (not hard to imagine, I hope). Naturally, you want to know how the customers “feel” about those products. If you were to separately ask an engineer and a sales-person how they would tackle the problem of gaining customer feedback, you’d receive two very different approaches. The sales-person would suggest gathering a call list, dialing-up each customer, recording the conversation, and then maybe aggregating the conversations to look for similarities. The engineer, on the other hand… well they’d probably build something to “quicken” or “automate” the process. Maybe an email blast sends a link to all the customers that directs them to a survey or embedded form which then collects and aggregates the data. Which solution would you choose?

If you’re like me, you’d probably go for the second one because it’s scaleable and will save lot’s of time down the road. There is a catch however. What if I told you that your company is a small startup, you have three customers, and are still validating the product idea? Hopefully, you are now reconsidering the sales approach for a couple reasons - namely, time and money. With only three customers you would likely spend more time building the automated software than you would actually calling the customers individually. Furthermore, given you are still in the validation stage, writing extra lines of code for a product that has not yet proven itself worthy, is a waste of your engineer’s time and resources… Especially if that engineer is you.

*NOTE: The above case study is, in fact, a generalization of a personal experience with a former startup.

Founder and Lead Engineer

If you can code and have taken the leap to begin your own side project, then congratulations! You are both the founder and lead engineer. If you are fortunate enough to have a team, even better (though I am jealous). As the founder and lead engineer, you are responsible for both building the product and getting it into customers’ hands - selling. Money and time are both limited, so it is crucial to spend both resources on high-level, needle-moving items only.

This means solving problems cheaply and quickly. No time for fancy custom built UI’s, free bootstrap themes will work fine. No time for automated customer support software, a quick email form will do for now. Just get the product coded, shipped, and sold. That’s what matters. For my designers and frontend developers, there will be a chance to let your imagination and skills run rampant, but for now, design the interface with as few features and interactions as possible.

Aside from writing code, if you are testing the idea, build a simple WordPress site with some nice plugins. This will get you pretty far pretty fast. With the rest of your resources, go show it to potential customers, talk to them, and if you can, close a deal (i.e. take their money). If you can’t seem to find a willing customer, then no harm done and no code lost. Pivot and try again.

I wish I could say this is the process I follow. But truthfully, I’m trying to force myself into this habit as much as the beginner. So, no judgement from me if you’re struggling. I like so many of you, truly enjoy coding and building for the sake of coding and building alone. However, if you aim to have your coding skills serve more than just your creativity (like say your wallet), then perhaps try coding less and talking more. Get your idea to those who want to pay you for it as fast as possible, then wow them with a version 2.0.

Conclusion

I hope this short rant helps some of you who may find yourself in the coding trenching of your first startup / side project. If you would like to chat more or just need a second set of eyes, feel free to hit me up on twitter @LandonRodd

All the best builders!

  1. 2

    Agree totally. Always need to validate the business with real customers first.

    1. 2

      Absolutely. I think I just get to excited to build something and think "I'll worry about that later!" lol 😂.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 16 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments