Learning to fail — a startup diary

This is a story from Zenc Labs, a new tech startup in Sydney, Australia.

Backstory

It’s been nine months since I left Google. I had a comfortable life, a fancy salary, excellent working hours, a friendly and supportive team, a technically challenging job and access to unlimited free food. I was hoping to soon get promoted to “Staff Software Engineer”. Everything was going great. And yet, I resigned.

I wanted to have my own startup since long before I joined Google. It was a childhood dream. In 2015, after three years at Google, I realised I would never leave such a great company unless I kicked myself out. I told my manager “heads-up, I’m leaving in two years”. We laughed at the irony of a two-year notice, but it made it feel real. It was happening. In two years, I’d have to pay for my own food.

I spent the following two years trying to learn as much as I could about the experience I was about to go through. Startups are notorious for failing, and I wanted to learn all the tips and tricks I could. I watched YCombinator lectures. I learned about all the ways cofounders can split up. I started networking with startup founders. I researched the nitty-gritty aspects of incorporating a company in Australia and the legalities around hiring (and firing) employees. I made friends with a few accountants and lawyers. I learned the basics of UX design and digital marketing.

March 2017 came, and I left grudgingly. After a couple of months off, I started running user research—online and in person—and exploring prototype ideas. At this stage, I wasn’t yet sure what my startup was going to build. I was primarily interested in developer tools, because it seemed like the best way to have a positive impact on the world. Many ideas nowadays are executed through software, which is written by developers, so if you help developers be more productive and happier, you get to make a meaningful mark on the world’s progress (or decline). Plus, developers routinely lose hours or days dealing with broken tools and processes, so there should be some easy wins. At least, that was my reasoning.

A first attempt

I considered about 20 ideas, going from “revolutionary IDEs” (what if your code editor actually understood what you were trying to do, instead of being a merely augmented text editor?) to “mobile app makers” (think SquareSpace for mobile apps). I built a minimalistic prototype for each idea to evaluate whether as a developer, I would even consider using such a thing. It took a few weeks. So far, so good.

Early August, I had an epiphany. I was going to build “Modular”, a developer-focused platform that would completely revolutionise how code was written. Instead of working on large projects stored in folders with hundreds of files, developers would work on minimalistic “modules” that can be easily run and tested in isolation with “actions”. A large codebase would become a meaningful assembly of separate modules, which themselves are made of smaller, isolated modules. Asking a freelancer to build a new screen for your app would no longer require giving them access to your entire codebase. Developers would be able to contribute to the ecosystem by providing their own actions. You could generate a working app in a few seconds because someone had written a “boilerplate” action for your framework/language. You could run and deploy it in a few more clicks because they had also written a “run” action.

After three months, I had a functional prototype including a full-fledged command-line and visual interface. I was excited. Except for one thing: I had “forgotten” to talk to prospective customers for three months. I had a cool product, and no business plan whatsoever. More importantly, even as a free tool, it was too complex to make the life of a developer easier. I had failed before I got the product out, monumentally.

And yet, despite the (apparent) failure of project Modular, I had learned quite a few things. I had built up new technical skills (Node, React, TypeScript, WebSocket, Docker and ANTLR). I had discovered that my mood was a completely unreliable measure of whether something was worth doing. When you work on an ambitious idea by yourself, you may find yourself swinging dangerously between excitement and despair. Apparently, that’s normal. You just have to keep working through it, and remember that it will be the same tomorrow, and the day after. If you don’t want an emotional rollercoaster, don’t make your entire income depend on whether potential customers like you or not.

A second attempt

A month ago, I caught up with another developer (let’s call him Eric), who leads a mobile app development agency. He wasn’t interested in Modular. There was one pain point in his job as a developer that he complained about: deploying servers on Amazon Web Services. He had no time to deal with the complexity of AWS and therefore delegated the work to a part-time DevOps contractor. If only there was a simple, visual tool to deploy a codebase to AWS instead of complicated command-line tools! He was willing to pay \$25/month for it.

I had finally found a customer with a real problem! I decided to put a break on Modular, and build a solution for AWS deployments. I knew nothing about AWS. I had signed up once, gotten confused with their terrible acronyms, and immediately switched to friendlier cloud solutions. I installed the AWS SDK, read up on their documentation and got going. Kudos to the AWS team: the SDK is actually pretty good! Within three weeks, I sent a working prototype of the “Deploy” tool to Eric. He gave me some useful feedback (the interface needed to be simplified further) which I took on board. I sent him the updated prototype. It felt amazing—I was about to sign my first customer! I decided it was a good time to incorporate, so I could confirm his commitment and take his money. My startup “Zenc Labs” was officially born!

After a week, I wasn’t getting much feedback from Eric. As it turns out, he was extremely busy, and deploying servers wasn’t something he had to do regularly. So I spent the next few days setting up a landing page (here), making a logo, and publicising it around my social circle. Yesterday, I posted on the Sydney Startups group and on HackerNews. In total, I got two email sign-ups. Both of them were friends. A few developers gave me valuable feedback, but none of them needed that specific solution.

Deploy isn’t a failure yet. I have several catch-ups with potential users lined up. There are a number of ways that Deploy can pivot (currently, it’s a desktop app, but I could make it a web app or a command-line tool). But I’m definitely not calling this a success. Elon Musk said: “Entrepreneurship is like eating glass and walking on hot coals at the same time”. I think that’s a bit harsh, but I’m starting to realise what he means. Mentally, it’s a challenge.

Yet again, although things aren’t looking bright, I’ve learned a few more things on the way. Technically, I finally got to understand the AWS ecosystem. It’s amazing, but completely over-engineered for most of us. I also learned Vue.js, Electron and Webpack. I built up my design skills designing a landing page and drawing logos for Deploy and Zenc Labs, getting helpful feedback from UX designer friends. Each of these skills will make me faster at what I do, and in the worst case, they will make me more employable. Maybe I could even work as a UX designer some day! More importantly, I’ve learned that finding a customer with a specific problem who’s happy to buy your solution isn’t necessarily a strong enough signal. You need proper market research, as boring as it sounds.

What the future looks like

Before I got into the whole startup adventure, the plan was simple. I would have a solid business plan. My cofounder would jump on board as soon as I suggested it. The startup would be profitable in September (two months ago).

Obviously, this is not happening just yet. I could be disappointed, but so far I’m glad I’m going through the experience. It’s fun to look at someone who’s obviously focusing on the wrong thing and say “look, they haven’t even followed the golden rule of talking to customers!”. It’s less fun to find yourself in that same position when “you knew better”.

What I find the hardest is sticking to an idea. I’m incredibly tempted to stop working on Deploy and instead start working on another cool idea. Probably a mobile app maker. Or a code visualisation tool. Probably both. And yet, I know that’s not a wise thing to do. I’m staring into the abyss now, but I’ll just be staring into another abyss in a few weeks/months if I switch to another project so early. When in the dark, you need to wait to get used to the darkness before you can see the way forward.

Thanks for reading!

I hope this helps some prospective startup founders get an idea of what it could be like. Obviously, every startup founder has a radically different experience. I’m extremely lucky to be a technical founder, so at least I’m not losing tens of thousands of dollars on software development learning these lessons.

Email me at f@zenc.io. Write a comment. Share your own startup experiences. If you’re a developer or someone involved in building software, I’d love to hear from you. Tell me about your frustrating development experiences. If there’s a tool you wish existed, I’d be honoured to help make it happen.

More about Deploy

If you’d like to check out Deploy, check it out at http://zenc.io/deploy or watch the video below. Email me for a link to the prototype.

youtube:https://www.youtube.com/embed/Zo6F0yTdqzc