This post is part 2 of a 4 part series “Developing Startups: Lessons Learned Over Two Decades”. If you’d like to read it from the start, you can jump to the first post here.

The first iteration of this is the initial process of designing, building, and launching your product. After launch you move to Measure, then Learn and end up at Build again as you enter your 2nd iteration and so on into infinity. The idea is that you are always taking your learnings and improving on the product as you go.

Managing the Work with Iterative Development

We’re not dogmatic about SCRUM, but we do think it’s a great tool. Besides the general benefit of instilling a procedural discipline to your development process, there are a few simple benefits that to us, sell the point:

Iterative Sprints

Iterative Sprints are incredibly helpful in that they force the development team into two week (normally) planning of deliverables. Features are broken up and prioritized in order to have a “usable” product at the end of every sprint. This way features can be used, learned from, and improved upon throughout development. Before SCRUM we would work on completing an entire module then have to go back and make changes after the fact as we noticed usability issues.

Epics, Stories and Tasks

The breaking up functionality into epics, stories and tasks not only guides the team into thinking through every element of the work that has to go into a feature but also allows for easier, more accurate estimating of these features. It feels like a lot of work up front but in the end it provides a much clearer path, and saves time.

Minimum Viable Product

“the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

The focus on prioritizing an MVP (Minimum Viable Product) is perfectly inline with the needs of the startup. As mentioned earlier, it’s impossible to do everything correctly on first attempt. Focusing on an MVP lets you learn from the product as you are developing it in order to increase the chances of having the best possible feature by the time you finish.

Other Benefits

In this section we’ve focused some of the main benefits of SCRUM that are, in our opinion, irrefutable benefits to the average startup. However, there are many other concepts/tools in the SCRUM framework that are of great benefit: Daily standups, Sprint reviews and retrospectives, Product and Sprint Backlogs, the concept of Product Owners, the definition of Done. If you’re not already using SCRUM we encourage looking into it. For more information.

A Healthy Code Base

Allowing Time for Refactoring

The pressure to push out a complete platform often results in code debt. This is completely normal. Speed is prioritized over proper system design and structuring. It is extremely important to allow for code refactoring. This is the process of restructuring existing computer code without changing its external behavior, in order to reduce complexity, improve readability, and improve source code maintainability and extensibility. It’s easy to dismiss this as abstract technical theory but its consequences are very real and could cost much time and money in the not-so-distant future when you’re trying to modify your platform. Just like a building, a platform is only as strong as its foundation.

This idea is also important during the lifetime of a platform. There is a concept called Software Entropy, which states that as a system is modified, its disorder, or entropy, tends to increase. With every change and modification, if active measures (code refactoring) are not taken to correct this issue, you’ll end up with what we affectionately refer to as Spaghetti Code.

I also want to quickly mention testing. It deserves an entire blog post but for now I’ll leave you with a few things you should dig a little deeper into. If you get anything from this post you should realize that a platform is constantly changing and evolving. Throughout the process of refactoring (as well as throughout the Build-Measure-Learn cycle) you should create test plans to help organize your testing. A Critical Test plan, for example, defines scope, approach, resources and schedule of test activities and can help you organize your regression testing.

Choosing the Right Technology

Development languages and frameworks are tricky. Everywhere you look you’ll find another article or blog post talking about what the next big thing is and what’s on its way out. You’re going to find fanatics and haters on all sides of this topic. The truth is that you’ll have to consider the Pros and Cons of your specifics. Many times it comes down to what the development team is most comfortable with. Beware trends and be aware of the trajectory of any language/framework you select. You want it to be a mature framework, feature rich, and have an active community. In regards to databases, you have to consider whether a relational or non-relational database makes most sense and based on that, select the best fit.

Open Source is our preference and makes sense for most startups. Although you should always be aware of the licensing details of your selected open source tools. Just because something is open source doesn’t mean you’re given the right to use it as you wish.

Version Control

When you own an online startup, all you own besides leased infrastructure and your goodwill (hopefully) is your source code. It’s important that you maintain it carefully. How do you do that? Use a source code repository. GitHub, Bitbucket, LaunchPad, SourceForge, GitLab, take your pick. The important thing is that you are able to maintain your code on the cloud, easily share and collaborate between multiple team members, review code, identify and fix conflicts, and track the state of your code at any point in time.

Documentation

Documentation is another important and often overlooked part of software development. It helps keep track of the latest state of the code, allows for easier maintenance and knowledge transfer. Additionally, documentation is often required by investors as part of their due diligence.

Documentation doesn’t have to be as difficult as you might imagine. There are many tools that help create quick documentation from source comments. Besides this type of in-code documentation though, you should document process flows. This goes a long way to shorten the learning curve for new dev team members.

Preparing for Scalability

A platform is not either scalable or non-scalable. There are many components of a system that can create a bottleneck and cause a system to not scale properly under different circumstances.

Complex queries, data classification algorithm processing times, data refinement processing times, etc There’s a lot to be considered but here are a few precautions that should be taken in order to deal with certain bottle necks:

Database clustering
Load balancing web servers
Caching content
Rapid Server provisioning (more about this below)
Autoscaling

When appropriate, consider the possibility of using existing infrastructures vs the need for building an infrastructure. For example, serving videos from you server vs using youtube. This would of course depend on the service you’re providing and whether the infrastructure in question is providing part of the core value or a secondary value.

Cloud Based Development

Just 10 years ago preparing for infrastructure growth or rapid scaling was a time consuming and expensive undertaking. New servers, routers, load balancers, etc, would have to be procured in anticipation of growth or traffic spikes. Today with services like AWS, that’s not the case. The same server procurement can be done in hours, and if planned for correctly, in minutes.

Due to incremental billing models cloud computing services like AWS allow you to put spin servers up and down at peak hours, or during spikes while billing you for only the minutes used.

Besides the incredible scalability benefit and flexibility, cloud computing allows for faster and less expensive disaster recovery and increased security.

Security and Threat Modeling

What do Under Armour, FedEx, Uber, Pizza Hut, Deloitte and Equifax have in common? They were all victims of security breaches since the beginning of 2017. Security lapses can be a great liability and, specially for a startup, can lead to an unrecoverable reputation issue.

Threat Modeling is a process designed to define security objectives, identify relevant threats, and develop plans to help mitigate the risks. This post does a great job of walking through the steps of Threat Risk Modelling.

Taken from the referenced post, to give you an idea of the sorts of security issues you should be thinking about, these are some starting points to defining security objectives:

Identity: Does the application protect user identity from abuse? Are there adequate controls in place to ensure evidence of identity (as required for many banking applications?)
Financial: Assess the level of risk the organization is prepared to absorb in remediation, as a potential financial loss. For example, forum software may have a lower estimated financial risk than an Internet banking application.
Reputation: Quantify or estimate of the loss of reputation derived from the application being misused or successfully attacked.
Privacy and Regulatory: To what extent will the application have to protect user data? Forum software by its nature is public, but a tax preparation application is subject to tax regulations and privacy legislation requirements in most countries.
Availability Guarantees: Is the application required to be available per a Service Level Agreement (SLA) or similar guarantee? Is it a nationally protected infrastructure? To what level will the application have to be available? High availability techniques are significantly more expensive, so applying the correct controls up front will save a great deal of time, resources, and money.

And as with everything, this is not just a pre-launch concern. You have to make sure to keep up with the ever changing landscape. For example, if your startup has an international user base does it comply with GDPR (which becomes enforceable on May 25, 2018)?

Dealing with Human Resource Constraints

When building, its important to make a realistic assessment of the sustainability of certain tasks based on Human Resources constraints.

Customer support platforms, manual curation, data classification, and blog post creation are a few example of the sort of thing that require constant upkeep. Some of these things can be handled with technology: Chatbots to help take some of the load off of support, crowd-sourcing for certain types of curation, ML (Machine Learning) for data classification. But some things still need humans (for the time being).

It’s arguably better not to have a feature than to have one that can’t be maintained and risks the erosion of user trust.

< Part 1: Intro

Part 3: Measure >

blog

contact