Non-technical founder asks, how good is our code?

As a bootstrapping technical founder, I would offer this advice.

A. Make sure you are using one of the more popular languages, but that's it. There's a million people who will tell you why their language is better and why yours sucks. In the end, it doesn't matter if A. It works, B. It can scale (and all major languages can) C. You can find people to help you grow (niche languages are harder to find qualified people, and you will spend more on training). D. You have a product people want.

B. Any technical person should never be happy with their code for an entire application. There's always a balance you have to strike between making it perfect and getting the product out the door. In the end, getting the product/change request/bug fix out the door will always win (and should in the early stages). This obviously leads to shortcuts being taken that if you are lucky enough to survive can be re-written when needed. We are in our 5th year. We only use maybe 10% of our code from year 1, 20% from year 2, 50% year 3, 70% year 4. Bottom line, your code will always be changing (aka thrown away) as your product develops.

C. MVP's should be easy to get out to test the market. You can be bug-free, scale, be fast, and feature rich without having good code. IMO spending tons of time up front prepping for scenarios that might happen 3 years down the line is a waste of time.

Just my 2 cents, and I know it doesn't apply to every project out there, but has worked for me and would be the advice I offer to any other technical founder.

Don't ask this question until you have validated your assumptions!

"...I have no idea how good our backend code is pre-MVP".

Pre-MVP? The 1st version is the MVP. If you have backend code, then that <em>is</em> your MVP! That said, it doesn't matter how good your code is because your MVP isn't a test of code but a test of customer demand. And the code will either be DOA (if no demand) or change rapidly with growth/customer discovery, so code v1 doesn't matter.

Who cares....

Does the mvp work and provide you with clear data points for you to make decisions with?
Can you turn around new features fast once said data reveals something?
Will it scale if you throw hardware at it?

Facebook was some pretty awful php code for quite some time, it worked well enough and they were able to ship new features fast listing to their users.

Get the product right and focus on growing customers, after you have that figured out then you can focus on making sure your tech stack is headed in the right direction and you can hire the right people to turn your great product in to great tech.

It's probably completely atrocious. I'd even go so far as to say that the "smarter" your technical co-founder seems, the worse the code is.

Really great points in the blog post, +1.

I would say the most important thing is to pick a language/framework that will allow you to easily scale and maintain it. If you choose a really niche framework that nobody knows good luck maintaining it. If you build it quick and dirty good luck scaling it. On the other hand if you are not sure what you are building and are looking to pivot and are willing to throw away a codebase once you have proven the model then who cares what it looks like so long as its not buggy... you do not want to overshadow the feature set by releasing an unusable version.

As a Technical Co-Founder I strive for beautiful code, we implement test automation frameworks and test-driven development. This is because we want to re-use the codebase for additional projects and we have market research validating what we are looking to build.

Glad to provide some insight into languages/frameworks used if anyone is interested.

I actually had a non-technical founder ask me to review his startup's MVP code once. He had hired someone overseas for $7/hour to build it.

It was written in PHP, but completely functional php (not object oriented at all). It totally worked, and the code was even nicely formatted (i.e. commented, spaced nicely), but I assure you the lines of code were very excessive, and it would have been complicated to scale, even though it was written in a popular language. You would be hard-pressed to find a modern PHP developer who would be willing to work within the framework set forth by this code (if there even was any kind of "framework" defined -- I can't recall offhand).

So, I do caution you to consider that even though it might work, you might have "bad" code, in that it would be difficult to work with in the future. That app would have needed to be rewritten from scratch IMO, in order to get any "modern" developer on board.