The 3 steps to being a “lean’ startup

3d3498d9-22cf-4502-b446-a1da6402ba5a.jpg

Why the need to be lean?

In the early stages of developing a startup, running capital is generally scarce, and its pivotal that you as a founder, and your co-founder, start the process of conception, development and fund-raising in the leanest possible way.

Without the ability to pay your salaries, and most likely bootstrapping your startup until you gain some momentum, choosing the right paths will ensure that you are able to sustain your startup in reaching the critical MVP goal, and positioning yourself to presenting your product to potential investors, without having to cease development.

Having an idea is not enough to get you through to your next major milestone, you need to take a step back and determine the critical factors that will ultimately conserve your startup’s energy and momentum. These decision include deciding on the compositions of your startup team, what technology stack you choose with, and how to focus on the critical features that will be part of your immediate roadmap. These three factors will decide whether you are there at the end, and set to transition to the next stage.

1. Choosing a lean founders composition

The first thing you need to do in a startup, after the idea conception, is compose the team that will execute your idea. Ideally as a founder, you would have the technical knowledge to develop your own idea. If you aren’t a coder, you better be able to provide enough design or business contribution to make up for it.

Being an iOS developer means you are already 30-40% of your way through composing the development team. Next, you will need to look for a second or even third co-founder, whom also are coders. Depending on the technology slack you go with (in the next point) one should be a server-side developer at the least, and one front-end developer.

Having a composition of two/three developers as co-founders, or 1 business and 2 developer co-founders means you’ve already formed your development team. One of the three would thereby become CEO, and eventually take on an active business and investor engagement role.

There is a strong case that a designer should be one of the co-founders, but my opinion is that generally a developer with a moderate Sketch skill set could create the initial design that would form part of the MVP, enough to convince potential investors of the idea, which would subsequently lead to capital that could bring in a designer as part of the second phase.

Starting lean means you have a small team that all contribute equally and complementary, is wholly technical.

2. Choosing a lean technology stack

After composing your startup team, the next lean decision you will need to make is choosing the technology stack. The importance of this is that you need to find a technology stack that complements the skills of your small team, whilst also being robust enough that it will allow for future scaling, and minimizing technical debt.

Ideally, if in step 1 you and your co-founders are all iOS swift developers, you would opt to have a Swift-backend , using technologies like Vapor or Kitura . Leveraging the same technology on your backend as on the iOS client means you can utilize the same team on both ends, adding greater knowledge transfer and knowledge redundancy.

Having a Swift back-end and front-end means you divide feature development according to features, not technology stack. One developer will own the entire registration process, one developer the entire activity feed feature. This is vertical delegation rather than horizontal.

If you don’t happen to have this composition, you will then need to decide between choosing a back-end that one of your developers is most comfortable with, such as Node.js, although I would advise this as the last resort. The better option in my opinion would be to have a nearly automated backend, using a platform like Firebase , meaning your team just focuses on the front-end.

Remember, if you de-couple your code well enough, when you get to MVP, you can simply throw out Firebase and replace it with a better and more scalable backend when you grow your team. The biggest mistake you can make is to pigeon-hole yourself into choosing a back-end that is so highly-coupled, that you are stuck with that, or spending a lot of time trying to learn and fix backend issues instead of focusing on the front-end, the most visible aspect that you will demo on Sandhill road.

3. Choosing a lean MVP roadmap

Finally, your roadmap. You have your team, and have chosen your technology stack, you need to now plan your level of attack. You need to get to MVP, choose on the important features to demo first, but continue to develop the rest of your features down the backlog.

The imperative word is MVP, minimum viable product. You need to prioritize the features you want to demo up front, your unique selling points, matching your pitch deck. If you are creating a messaging app with bots, create the bots, don’t worry about secondary features, like sharing on Facebook.

A good idea is to develop a high-fidelity prototype, say on Sketch and validate with people you know, friends, strangers, as you develop component-by-component. This will serve as a somewhat makeshift customer validation exercise as you develop component-by-component. This is an exercise you will continue to validate and re-validate, and something you should get used to.

Use third-party libraries where you can, and then develop your own later on. There’s no point to re-invent the wheel , unless the wheel is your unique proposition, in which case you should.

In your first week roadmap workshop, develop the roadmap to MVP, the features you will have, and even if you come up with ideas that aren’t important for MVP, have them in the backlog for the future. Make sure you baseline your ideas where you think you will be ready to showcase it, and remember this is a work-in-progress, not something that needs to be perfect.

And lastly, while you are developing your app, create a simple sign-up page, fastlane provide a great on-boarding Heroku script so you can generate some buzz, get some people to sign up before your app is ready to take in users. This will set you up to have some users to try out your app in TestFlight early on, and as added evidence of interest when you approach the VCs.