9 Product and Technology Sins of a Founder Who Learnt to Code — CityFALCON Blog

Ruzbeh Bacha
13 min readJun 19, 2020

--

Follow the advice below and avoid frustrations

In celebration of our 6th anniversary and as a sort of complement to my article 15 Lessons from 15,000 Hours of FinTech Entrepreneurship , I want to publish some of my biggest mistakes so other entrepreneurs may avoid them.

Editor’s Note: 3 * 2 = 6 and 3 ** 2 = 9, so the title is still connected to our 6th birthday. That’s why it is important to learn coding!

First and foremost, before the list, if you want to be a techpreneur, you must learn to code. Maybe that is obvious, maybe it is not. Learning to code allowed me to build the first version and, on a daily basis, allows me to understand why developers do what they do. Over a period of time, I’ve really enjoyed coding and getting my hands dirty with APIs, etc. A machine learning course has allowed me to interact even more confidently not only with our data scientists but also CTOs of clients and partners.

I made mistakes and more experienced people taught me why they were mistakes. Many founders can develop superiority complexes, but knowing your own mistakes keeps you relatable to your employees and clear-headed.

Now let’s get to the list.

1. MVP is a B*tch

You need money to build the business, but every investor wants to see a Minimum Viable Product (MVP). Without one, yours is just an idea — or a dream, from the investor point-of-view. Dreams are great, they’ll say, but they are not investment-worthy.

So you try to build an MVP as fast as possible. It is minimum, after all.

You throw things together; you’re learning as you go, and every day feels like you accomplished so much. Then you realise you wrote one line of code and created two new bugs. You take shortcuts, and, since you only need it to work for a few users at the MVP stage, you skip scalability. They’re computers, they can do things fast. How bad can it become going from 50 to 5,000 users?

For me, I did not know all the best practices, like testing, documenting, and preparing for scalability. The objective was to have a basic product to raise funds, not build the enterprise edition. I wrote the backend using the Ruby on Rails framework but the frontend in straight JavaScript and jQuery. That seems reasonable at first, and at the time, frontend frameworks were not as popular. But not using a framework on the frontend likely cost us one year of refactoring and rethinking, because the scalability and flexibility were non-existent and that translated to a user experience of long load times. The inefficiency also meant high cloud hosting and processing costs. Not to mention explaining (and rediscovering) my own code to developers, because my documentation was minimal, and fintech concepts can be quite complex for non-finance-savvy coders.

You probably need 3–6 months to get to the MVP from scratch, and several more months to gain any traction. At the same time, you need to raise funds, but investors just want to see traction and revenue. To generate the almighty revenue and traction, many new founders will try to transition from an MVP straight to enterprise quality. But then the sales pitches will fall flat because it won’t be enterprise quality but still only minimally viable.

When you build your MVP, at least plan for scalability and efficiency. No one can future proof from the start, because you don’t know if it will even work. But always keep the future tech challenges in mind and mitigate them as best you can from the start.

After raising funds and hiring developers, you may want to refactor the code and reevaluate the architecture before focusing on more features, users, and revenue. This upfront investment of time could prevent several major issues down the road. You did build a viable product, after all, not a final optimum product.

One way to avoid the MVP stage and the requisite product building from the start is by raising millions entirely for an idea, a practice very common in Silicon Valley. Of course, it’s a privilege only for a few — serial entrepreneurs with a strong record, friends with a VC or major angel investor, or a senior industry professional with a lot of contacts. For the rest of us, kind of MVP will be necessary before seeing any investor dollars or interest at all.

2. Logging in With Every Tom, Dick and Harry — I mean Facebook, Twitter, Linkedin, Google, and now Apple

You might be in the inclusive spirit. Maybe a user emailed you asking when they can log in via Facebook. So you look at the docs, and, awesome, it’s just a few lines of code. But you’ve opened Pandora’s Box. Once the “few lines of code” expands to many and you finally get the authentication process working with your systems, you need to integrate it across all of your delivery channels. If you have a single app on iOS, maybe it is not so bad. But when you have a website, Android and iOS apps, and voice systems like Alexa and Google home, you need to add the sign in functionality for all of them.

Then, you may be forced to add others, such as Apple log in for iPhone users (see Clause 4.8 of their T&Cs ) if you want to continue providing your services through their platform.

Now that you have 6 different pieces of code, one for each delivery channel, you’re all set. Until one of the APIs changes and you need to fix your code across all channels. Google and Apple are not worried about their changes breaking your tiny app — but you’ll be in hot water if it does.

At times, even users will get confused about how they signed up — was it through Facebook or Twitter? If it is confusing for the user, imagine what it is like to build all of those sign in methods and then manage all of them — and the customer’s confusion when their account doesn’t reflect the last change they made because they had signed in with a different method.

Sign in integrations always invite more sign in integrations

Unless you need data beyond authentication (like images from Facebook or user info from Google), be exclusive: use only a username or email and exclude the various other log-in methods. When you are cashflow positive and can afford a developer solely for authentication, then you can think about adding multiple authentication methods.

3. The Temptation to Unnecessarily Recode Features

Just as multiple authentication methods are “just a few lines of code”, you’ll hear developers saying “the code is too complex. Let me rebuild it and it will be way more efficient”. Press the panic button!

Developers have the drive to make their code efficient and clean, and as more features are added, the code becomes complex. But coding is only one part, and in complex systems, like the human body and the climate, small changes in one place in the code can have drastic knock-on effects later or elsewhere.

Moreover, proper product management is not just coding. Once the code is ready, the Quality Assurance (QA) team must test it. This process invariably results in time-consuming back-and-forth (see Sin 6 below). Then it must be stabilised. If anything important changes, messaging and design may have to be tweaked. Unforeseen effects pop up, and suddenly customer complaints roll in.

Do not fix something that is not broken. We’ve done this and paid a heavy price in time to launch, stability, and quality.

4. Not Understanding How to Manage and Motivate Developers

In tech, developers literally make (and break) your product. The kinds of people attracted to software development are a special breed, and you must understand how they operate. You may have 20 years in the industry and managed 100s of non-tech people, but all that knowledge and experience may not help to work with developers.

Not understanding their motivations and how they operate is a big mistake. It leads to misunderstandings, delays, and headaches. In the hiring process you’ll meet a lot of devs that want high pay, high autonomy, and flextime. Most will not want daily reviews, hard deadlines, and overtime. Take these considerations seriously.

More now than ever, remote work is a real possibility for developers, and the whole world is hiring. The best will work where they are treated best. And you do not want a poor quality product churned out by unhappy employees, especially when you need that last-minute fix before presenting to investors. Happy developers will make an overtime exception for you; unhappy ones might just vanish.

You can read my entire article on working with developers .

5. Not Automating Testing from the Start

Like security, code testing is often viewed as optional and as a waste of time. But as the team and product grow, complexity will force testing. You can’t integrate a component into a complex system without any testing, lest you are ready to face the customer fallout when production seizes up and starts spitting out error codes to users.

We have always done unit testing — that is, testing each individual component in itself — before attaching it to the full system. However, we only started holistic automated integration testing from 2019. A major reason was a lack of resources to retest the entire system for every update. As long as the updated portion worked, we assumed the entire system would work.

Automating your testing, particularly for integration, makes it much easier to test and retest every portion of the site for every integration. Since it is usually unknown what will change across the entire system due to the new module, integration testing must cover the entire site. Non-automated, this is very tedious and QAs spend significant time on mundane tasks. But once automated, they’re freed.

This leads to continuous integration, wherein new code is added constantly, rather than in large updates. If your testing is not automated, you wait until many small changes are ready then release them all together, so you test the entire system once. But once product-wide, mundane testing is automated, continuous integration can be adopted without wasting QA resources on repetitive testing.

6. Underestimating Time-To-Release: Coding (1x), QA (2–3x), Stabilisation(2–3x)

When dealing with tech, especially if you’ve come from outside the tech world, coding seems front and centre. You want to create a tech product, you code it and there you go, right? Sure, if you don’t need it to work.

You’ll spend 1 week on development time. Then QAs test everything (that cannot be automated), tickets are written, and the code returns to the devs for bug fixes. Then the QAs get the modified code and the process starts over, generally taking 2–3x the original development time. Once you’re ready to push the new code to production, in case of big data and complex features, you have to spend 2–3x the original development time to ensure stability and quality performance.

Added up, you went from 1 week release time (original estimate for new techpreneurs) to 5–7 weeks. Being unprepared for this kind of ballooning of timeframes will see you overpromise to clients and push your team too hard when the deadline is missed.

This is assuming you had proper documentation for the code in the first place and the developers already understand what UX, UI, and product management need.

Building a quality tech product requires more time than most people imagine.

7. Overlooking the Productivity Difference Between Good and Bad Coders

There is a lot of pressure in the early stages to bleed as little cash as possible. This leads to hiring junior developers for projects that should not be entrusted to junior developers. It is great to hire junior devs later on to assist with smaller tasks, but the core of your business is your technology — a good, experienced developer is necessary. Otherwise, you will spend significant time reworking old code for scalability, stability, and efficiency. Paying extra for a good developer with sufficient experience will be worthwhile down the road.

This requires both qualities: experience ability. Some junior devs are awesome coders, they just overlook future issues that experienced coders do not. Conversely, 10 years of experience does not necessarily translate to good coding ability. You’ll need to ensure both qualities are present. Having learnt from this, we now spend a lot more time during the hiring process to make sure we get the right candidate on board. Then, during the probation period, we evaluate their work thoroughly and any red flags are dealt with immediately.

With the amount of additional work required in debugging, recoding, QAing, and redesigning due to bad code, the difference in productivity between a good and a bad or inexperienced developer could be a 1000x.

8. The Temptation to Build All ‘Experiences’ In-House

Every company wants to provide a quality experience for its users. When you embark on the journey to building that experience, you may have the backend already built. Maybe you even have a couple of clients who use your API. It should be very easy to serve that data to a consumer frontend, right?

Serving the data, sure, that’s easy. Actually building the frontend? That’s a different story. Frontend is cumbersome. First there’s graphics — you’ll need a designer to make those graphics. APIs are just endpoints, all text and code. Oh, and the graphics will need to scale to display correctly on different screen resolutions and browsers. And who doesn’t want a mobile app? That comes with its own host of issues, like forced login types (see 2 above), multiple operating systems, and varying hardware.

My recommendation: You will have to build a lot of the frontend but if you can buy premade components from third parties that will let you cover most scenarios (OS, hardware, screen size, etc.), buy the premade components. Your product is differentiated by backend code and frontend design, not frontend foundational code. If you can buy it, skip the headaches of QA testing 15 different browsers, tablets, and phones. You do not have to build everything in-house; there may be a solution for purchase at a reasonable price. Or even open source, if you’re lucky. But do not get sucked into believing open source is always worth the savings, because sometimes the premium version will solve your need exactly without any additional dev time.

9. Not Understanding Role Differences in a Tech Context

Another misconception of those without a tech background is that all tech roles are more or less the same. Sure, developers are backend/frontend, user interface is different from infrastructure. At the very beginning, this may even be true. When it is just you (and maybe a couple others), the roles all blend together. But as the company grows, differentiation and specialisation are necessary and confusing them can be a costly mistake in time and quality.

The first case in point: design. There are designers for user interface (UI) and there are designers for user experience (UX). UI is heavy on creativity, making everything sleek and enjoyable to look at. UX is more about structure: how do users flow through the system? What happens if an error occurs here, does the user come to Screen A or Screen B? Does this design make sense in the context of where the user just came from or does it just create confusion?

Not knowing the difference between UX and UI can lead to visually-appealing products that frustrate and confuse users. You don’t just sell the look, you sell the experience. Make sure it is worth the money to customers, or they will go elsewhere.

I also mistook software developers and DevOps personnel leading to more work pressure on our developers. Technology systems, especially those as complex as our own, are not solely code (as mentioned in Sin 6). Big Data also pushes the limit of what systems can do, so stability and accessibility become top priority. Of course, in today’s world, 100% uptime is taken for granted, and failing to meet this is immediately noticeable. We already have 1.5 DevOps and may need to hire one more to be able to add more AI services.

Your devs, both backend and frontend, are focused on the code and the algorithm. You need DevOps to ensure the computing power is there to run that code, and it needs to be stable enough to keep customers happy. Don’t mix up DevOps and software development.

9a. Sins of Another

We received some insightful caveats from Jelle van Mourik, a reader on Facebook. We’ll just lay them out here in this one heading (we’ve paraphrased a bit and of course added our own flavour):

  • Do not force coders to code what they do not code. In other words, don’t try to make a backend programmer work on frontend UI code and vice versa. As USD and RMB are both currencies that you don’t use interchangeably, it may all be lines of code but approaches, structures, and experience differ between various aspects of it. Considerable mistakes, delays, and headaches await anyone who tries to get a coder to code what s/he does not code
  • Design before you code — there is nothing like getting the entire codebase to work and realising the new design is incompatible or requires significant overhaul of the code
  • Go to user testing ASAP, because the users are the ones you cannot control and they’ll break things or reject them, and that’s bad for business
  • Address negative feedback in the app so the discontented users express that discontent to you, not to the wider public on the iOS and Android app stores
  • Keep a single stable branch for deployment, not multiple “releasable” branches which will diverge, then confuse everyone and have missing critical pieces that take you a week to integrate to your released branch
  • Keep an explicit backlog of technical things to do, and plan sprints using it. These things have a tendency to slip the mind. In fact, if you can afford it, you may even want to hire one person to manage this

And that’s the 9 Sins (plus readers’ sins). Do you have any similar experiences you’d like to share with us? Any other pitfalls you’d like to warn fellow entrepreneurs about? Please comment below.

Originally published at https://www.cityfalcon.com on June 19, 2020.

--

--