The Tech In Tech Startups 2: The MVP

The Tech in Tech Startups: Part 2 - MVP Development

I often work with startups in the very early stages. Usually, either during the planning/development of the MVP, or right after - as they are preparing to take the platform to market. There are a few problems which almost always seem to crop up. This article tackles identifying these problems, and some potential ways to avoid or fix them.

(If you're considering hiring or finding a lead engineer, check out my last article too.)

1. Hiring Super Cheap Devs - and Not Planning Accordingly

Here's how the story almost always goes. An entrepreneur has a great idea for an app or service and figures they'll take the "lean" approach and "prove" the market. They quickly and cheaply build an MVP, prove product market fit and then raise funding or grow organically, with a lot more confidence than when they started.

Now, this is often a very wise approach... but it has to be done correctly, or you could wind up in one of the usual situations I encounter. That is, with a buggy program that the dev team suddenly struggles to fix and expand.

Commonly, assuming the developers themselves are basically competent, if they aren't led by a competent architect, a few common problems will arise. Namely, not only will the program likely have usage scale limits, but it will also start to have development scale issues as well. In other words, adding features will get harder and harder, finding and fixing bugs will become frustrating - and trying to get your cheap outsource development team to focus and clean them up (without causing more) becomes a game of annoying micromanagement and whack-a-mole.

Avoidance

The "easiest" way to avoid this issue is to partner with, or employ, a competent tech lead. This is obviously easier said than done, especially if you don't have capital and aren't ready or willing to seek a cofounder or investor.?

The alternative is to embrace this likelihood and plan accordingly. Build a business plan that involves building a very basic demo and expecting to raise the capital or revenue necessary to rebuild, before adding any new features or too heavily scaling out your marketing efforts.

Recovery

Recovering from this situation is hard. The obvious option is to raise funds and rebuild - via sales or investment. This can be extremely difficult if you have dissatisfied customers due to the bugs and have run out of funds to solve the issues. The problem is compounded if the other points in this article also apply.

If you can't yet raise funds and your capital is basically depleted, you're going to have to break out your leadership and negotiation skills.?

There's no world where you're going to magically fix your software, so you'll either need to roll up your sleeves and fix it yourself, or very carefully deploy whatever relationships, leverage and capital you have left.

Keep in mind that not all situations are the same, and this is just my general advice/approach to this situation.

Step 1. List the problems and causes - If you haven't pinpointed the problems, start by running a few live problem-solving meetings with your developers. Have them talk through the problem, try and recreate it live via screen share, and list out the possible reasons. Anything the developers can't identify the cause of needs to be marked for further investigation.

Step 2. Triage the issues - Anything that absolutely MUST be fixed IN THIS VERSION needs to be ordered by priority. Priority is based on impact to the utility value of the application to your customer. Anything "nice to have" or "annoying" or "needing to be improved" is no longer on this list at all. It goes to a backlog for the next version build.

Step 3. Evaluate repairs - If you haven't figured out the cause of some of your critical issues yet, you basically have to get your developers to dive in and research the cause... or you'll have to hire a specialized contractor to come in and identify the issue for them. Spend the time talking with your tech team to figure out how much effort fixing these super critical bugs (even with quick band aid patches) will take. At this point, unless the fixes are obvious and quick (in which case just negotiate a simple deal to have them taken care of), you may want to get a second opinion from freelancer or agency contractors.

Step 4. Decide: Scrap it or fix it - Once you have a clear idea of the effort and costs involved, you'll either need to decide to rebuild or repair. If after considering the estimates, and any second opinions you decided to seek, you find the repairs to be within a relatively reasonable tolerance, you should proceed with them. Offer equity, limited revenue share, sign a future engagement intent contract, offer deferred payments or hire another contractor if needed. However, if the repairs are a major time-consuming investment which will likely result in client or opportunity loss, it's better to bite the bullet and start from scratch.

2. Building with Non-Standard Tech

The next common issue I run into is a system built using super obscure frameworks or languages. Assuming Problem 1 doesn't fully apply, and the application isn't extremely buggy, this issue is still a very big red flag.?

Often, the founder doesn't know enough about development to be able to judge the recommendations and development patterns of the contractor(s)/"tech leads" they started working with. A reasonable timeline and price are established, and the system appears to be getting built as expected and seems to work.

When I build development teams, or start writing an app myself, I always opt for the most widely adopted and appropriate development frameworks, languages and technologies. These days, for web development for example, that usually means JavaScript (react and node usually.) This isn't because PHP, Go, Python, C#, JAVA, RoR, Elixir, Rust or any other popular language isn't a viable option to build the application with... it's because I need to be able to cheaply and quickly add and replace developers.?

You wouldn't be building this application if you didn't believe it was going to be adopted and grown. This will mean more features, long term maintenance, and scale optimization. This all equates to adding and replacing developers rapidly. If you've adopted a non-standard way of building, or are too early in adopting a new technology, you'll find it hard and expensive to find developers.

Avoidance

Short of hiring a lead or cofounder that already has this in mind, you'll want to take the time to evaluate the current top development methods and technologies, and make sure you can see plenty of job posts (being filled) for development work in the language(s)/framework(s) your developers are proposing.

Recovery

This is a hard one. In the short term, you'll want to ensure solid tech leadership is in place to manage this situation. Usually, your focus will be to implement bug fixes and very quick feature tweaks within the current system and implement any new major feature "back end" services as new microservices using standard technology. Over time, as you have to touch and refactor major aspects of the app, you'll abstract more and more of the key functionality into standard microservices. Building the next version with standard tech will be mostly just rewriting the parts you haven't transitioned to new services yet.

Every time you find yourself struggling to find more talent to scale up feature production, consider the payoff and viability of investing the extra effort to rebuild the related functionality as new services. Also constantly keep in mind, if you're still working on your initial MVP, you are probably suffering from the next problem...

3. Not Throwing Out the MVP Early Enough

As the story often goes, you've produced your MVP and gained some traction or investment... Now it's time to expand the functionality and dive into sales/business development mode.

This is also the time to evaluate the tech debt and underlying structure of your app. This moment, where you can start funneling funds into more developers to build more features, is the most critical time to ensure you bring in top notch tech leadership.

You need to determine if the program was designed to take the expected load, costs of infrastructure will scale reasonably with the increased features and usage. It’s also your last chance to assess if the system is built with the most popular and standard technologies that you can easily add/remove developers to work with.?

Often MVPs are full of technical debt and were not designed for scale of any kind (team, efficiency, load, features) and you're going to be trying to build a high-rise on top of a beach shack.?

It's extremely difficult for non-technical leaders to accept the need to rewrite or refactor before moving into high production mode, but without laying the right foundation, the system is fated to fail.

Avoidance

With a solid tech cofounder, the company management should be on the same page. A clear vision for expected/designed scale is in place, and the roadmap reflects the points where tech debt trumps production.

Essentially, avoiding this issue requires baking the decision to build purposefully in the first place - or a clear milestone at which a rewrite is to happen - into the business plan.

Recovery

This could wind up being fatal if not handled correctly. Continuing to build on quicksand is basically burning money. However, it's extremely hard to balance market/client/investor demands and KPIs with the need to spend money and time rebuilding things that are "already working."

Ideally, you're able to build new functionality as properly structured microservices and do the same for any part of the app that is going to be heavily touched. However, it's not always possible to chunk off functionality, and bringing in external services may add auth and communication layer complexities that will require refactoring many points of the app.

Ultimately you may need to put the current version into "maintenance mode" - only fixing bugs and making critical modifications. This allows you to put the majority of your dev efforts into a new version. This will likely slow down the release of new features (and potentially slow down growth) but, in the end, prevent winding up with a project that becomes too difficult to debug and keep stable - or worse yet, has a catastrophic failure that hurts a client.

4. Using an Open-Source Codebase as the MVP's Core

If you grabbed some program that provides 90% of your functionality off of GitHub - and smacked a few specific features on top and a web page that "repurposes" it... you don't have an MVP. You have a concept demo.

If your developers don't know and control the underlying core of your application, you have a ticking time bomb. You will reach a point where the repo you forked has a new feature you want to merge in - but can't because of your own modifications... and you'll have an incredibly difficult time getting developers to "quickly" make any change that affects the underlying core system.?

Avoidance

You simply cannot grab an off the shelf system and call it your own. It's fine for a concept demo, but as soon as you're funded or thinking about marketing it and adding features, scrap it and build yourself an in-house mvp that you control.

Recovery

If for some reason you did this, and you have clients using it... the best advice would be to put it in maintenance mode and start building a new version. Slow your growth and accept this cost and effort. Bring in a tech lead to make sure this is done right.

5. No DevOps

I often find tech founders have built their systems on tech-oriented platforms. They aren't directly running on AWS, they are running on Netlify, Heroku, Vercel or some other highly automated developer-focused hosting layer. I often find the opposite is true for startups that hire devs... they are often using custom EC2 servers or some kind of hodge-podge of docker and virtual machines.

Both approaches are totally fine for tech/concept demo development... however, I often find the topic of proper hosting architecture and underlying DevOps (CI/CD, Testing, Monitoring, Backups, Security) being basically ignored and seen as a burdensome tech debt task that doesn't have 'production' value (as in producing more features to show off to clients and investors.)

The product going to market (even as an MVP) should be hosted properly (normally as serverless functions and containers), with automated deployment hooked up to version control, some basic build and health testing/monitoring, a proper database cluster (and no hacky systems like firebase), solid auth structures, have multiple environments (development, staging and production), and have clear API and architecture documentation.

Without these things in place, developers will have a hard time testing and deploying system updates and it will be too easy to introduce imminent scaling issues and bugs.?

Avoidance

Bake these things into your plan. Ensure your tech lead is on top of this stuff from the beginning.

Recovery

I usually require 20% of sprints be assigned to Ops efforts (maintenance/security/monitoring/tech debt etc.) You'll need to bring in the specialized contractors/workers as needed and schedule time accordingly to make these changes.?

6. Leadership Issues

There's a whole lot more to being a tech founder, cofounder or exec than just worrying about the technical. Proper leadership is as, if not more, critical than the tech itself.?

Stay tuned for my next article "Leadership in Tech" for some of the key leadership failures, tips and lessons I've learned working as a leader in both major tech companies and various stages of startups.