2.6: Chapter 11 Building

IF YOU’RE NOT A SEASONED programmer and are building an idea in order to expand your skills, this may be the longest stage of your journey.

Don’t worry if it takes months before your work starts to pay off. Keep learning, keep researching, keep running into dead-ends and walls of bugs. You will break through them and get faster and faster at application development.

If you want, do it yourself. It may take two years to launch this way, but you’ll gain a priceless skillset. I can’t tell you how valuable it’s been for me to learn to program. I literally can’t price it. I don’t think it’s a stretch to say it’s priceless. The speed by which I’m able to launch and test new ideas, get access to new opportunities, and meet and gain the respect of other entrepreneurs is not quantifiable.

I can say that being able to do it all myself has saved me over a hundred thousand dollars of outsourced development cost in the last several years. I couldn’t afford to buy that kind of time, so I wouldn’t have launched as many products if I couldn’t simply build them myself.

Now I’m going to get a bit technical. It’s not important that you understand everything but it is important for you to be aware of the types of services and terms I’m using. I encourage you to read through it carefully even if you’re not going to develop your application yourself. You’ll manage the developers who do it for you better.

You will eventually need to have an opinion on everything in this section. Some chapters will take you more time than others, and you’ll find the best answers simply by getting out there and building. However, I’ll describe my thinking so you know what to expect and can develop your own informed opinions.

The goal is not to start just one software company. You should start several, so you’re going to choose a set of these services (a “stack”) that you can reuse across all of your future projects.

Since I’ve already used this term, I have a quick note on what it means to be “technical.” Here’s a checklist. If you answer yes to all of these, then congratulations! I, with no real authority to do so, hereby dub you “technical.”

• Do you regularly launch a terminal window to open programs, navigate folders, or check to see why your laptop’s fan keeps turning on?
• Do you know what a SQL join query is? Bonus point if you know the difference between an inner join and outer join?
• Can you clearly state the difference between an instance method and a class method?
• Can you describe why the model, view, and controller files are separated in modern web frameworks?

If those questions are completely foreign to you then you have some reading to do. It will take some time before you can build a web application yourself. You’re not technical now and it will take you months of active learning or a year of passive learning to become technical. But again, the journey will be well worth it. The value will be priceless for you too.

If you’ve read this far and have a pit in your stomach and want to skip this chapter, I understand. That’s okay. You don’t need to be technical in order to succeed as a parallel entrepreneur. This section doesn’t require you to be a computer software geek. Instead, I’ve written this to speak directly to you and catch you up on what you absolutely must know in order to outsource multiple development projects serially or in parallel.

Don’t give up yet. Keep reading!

It took me about five years to become technical, and I’m still probably somewhere between a novice and an intermediate programmer. The thing is, I love the technical stuff. It activates a part of my brain that really enjoys being challenged. So I eat it up. Maybe you will too, but don’t let that be a barrier. Another way to learn while still speeding up development is to outsource it to a friendly expert who doesn’t mind answering questions and can teach you how your application works as they build it.

The following questions are extremely important. You should have an educated opinion on these answers in order to build multiple products successfully. It will only help you as an entrepreneur to have a deeper understanding of this side of things.

Let’s jump right in.

Where will you host your web app?

Hosting today for companies at our scale comes in two flavors: virtual private servers (VPS) and hosting platforms or platforms-as-a-service (PaaS).

Some notable examples of VPS’s are Rackspace, Digital Ocean, and the EC2 product from Amazon Web Services (AWS). They’ll give you the ability to log into a server and install everything you need to run your application.

On the other hand, a PaaS will do all the server creation and code deployments for you. The most popular PaaS is Heroku, which is owned by Salesforce and itself runs on AWS EC2. AWS has its own PaaS as well, Elastic Beanstalk, which has many of the same features as Heroku but is less expensive.

Recommendation: Heroku. It’s free to start and scales at low cost. If you’re not technical then I don’t recommend using a technology that Heroku doesn’t support. Disregard the buzz about the latest, greatest thing. Use a tried and true software that’s already supported by Heroku.

Which language will it be written in?

Your options are many, but the three that you should choose from are Ruby, Python, and JavaScript. If you’re paying any attention to technology then those three names should sound familiar.

Python + Django

Python is about thirty years old. It began in academia and became popular because of its semantic and descriptive language. If you’ve seen code snippets in the past, you probably saw a bunch of parentheses, curly brackets, and semicolons. Python got rid of those and people rejoiced.

It became popular among data scientists and today, for example, the code written to analyze electron collisions at the Large Hadron Collider in Lucerne, Switzerland, is written in Python. Most of the machine learning community still uses Python, and blockchain developers have also embraced it. It has a large community of engineers who write and release free, open-source packages of code, called libraries, which give Python a suite of out-of-the-box tools to use in your programs.

One of those libraries is Django and it has become the de facto way to build modern websites using Python. If you’re going to develop your app in Python, you’re going to use the Django library to do it.

Ruby + Rails

Ruby is a more recent language, developed in Japan as an alternative to Python about 20 years ago. It’s also very easy to read; many would argue more so than Python.

Ruby began as a very niche, almost underground movement to fix some of the things that bothered programmers about Python. Then everything changed when a Danish developer named David Heinemeier Hansson began to write a Ruby library (they’re called gems in Ruby) for web development. He named the gem Rails and the project became known as Ruby on Rails.

Ruby on Rails is the most popular web programming language with millions of websites built on it. Its most recent release, Rails 5, went live in spring 2017 to much fanfare in the Ruby community. It’s a major milestone for the project and speaks to the quality, security, and longevity of this technology.

If you dive into Ruby, you will find that there is a gem for everything. Not to be outdone, even the super nerdy data and statistics libraries from Python have been rewritten in Ruby. It’s a very safe choice.

JavaScript (Node.js) + Angular or React

JavaScript right now is like the Wild Wild West. Only a few years ago it was a purely front-end, client-side (e.g. it only runs in your browser) language. Today there’s much excitement around JavaScript itself emerging as an option to run back-end logic, database queries, and of course the cool front-end tricks it’s known for.

The difference between JavaScript and Ruby and Python is that: JavaScript runs in browsers and Ruby and Python run on servers.

Have you ever noticed that sometimes you click on a button on a website and the page will reload, and other times you’ll briefly see a spinning icon and then content will magically appear without the reload? That asynchronous loading is JavaScript in action. It’s logic that runs in your browser so your server doesn’t need to do the HTML page rendering and cause the reload.

To make this more clear, here are some real examples of both techniques on sites you’ve probably visited:

Pages reload:

• New York Times
• Wikipedia

Pages load asynchronously:

• Facebook
• Gmail

Unlike Ruby and Python, the JavaScript world is in a controlled chaos state and is moving very, very fast. The most popular website development package (that’s a library or gem in JavaScript) is called Node.js. Node is really just a backend package, so on top of Node you’ll need any number of front-end packages. The two most popular are Angular (released by Google) and React (released by Facebook).

There are thousands of posts published online about each of these JavaScript technologies. The important thing for you to know is that they exist. I won’t go into the pros and cons of each here because that ultimately boils down to a personal choice about the behavior of your web app and your desire to use the latest tech.

Recommendation: Unless you’re already technical, use Ruby on Rails and don’t attempt JavaScript yet. You can add a slick JavaScript front-end later. Rails will give you everything you need and your code will be efficient and easy to understand. Plus, if you outsource, you will have many inexpensive Ruby development options.

What kind of database will you use?

Fortunately, we’re back down to two choices, and I’m just going to cut to the chase here and tell you to use Postgres. You still need to know what the other option is, though.

SQL -Postgres

Postgres is a transactional database, which means it uses tables and rows just like an Excel spreadsheet. It’s the most popular kind of database, commonly known as SQL (Structured Query Language). There are competitors to Postgres in the SQL landscape, including MySQL which is now maintained by Oracle, but in recent years Postgres has emerged as the most reliable and fastest of the SQL technologies.

NoSQL -MongoDB

The alternative to SQL is a document-based approach, commonly called NoSQL. The leader in this space is MongoDB. Rather than having rows on tables, you can think of each row being a document with arbitrarily structured data. The documents can still relate to each other but if you want to add a new kind of data, you can just add it. That’s the main benefit—no declaring new columns and having to migrate your tables. The new columns can simply just appear.

Recommendation: Use Postgres SQL. It’s a much older, safer, and more popular technology. The migration process may seem complex at first but if you think through your application structure well in advance, you won’t need to change your tables too much. Your migrations will usually be adding new fields, which is easy to do. Document-based storage simply isn’t necessary in 99% of cases.

Where will you store your code?

Heads up! This is critical.

You need to use a code repository and you must be the owner of the repository account. If you work with third-party developers, then you need to invite them to your repository, not the other way around. You must be the owner of the repository.

Even if you develop everything yourself, using a code repository is good hygiene. You don’t want all of your undeployed source code stored locally on your laptop. If it gets lost or stolen then you might lose weeks or months of work. Code repositories are remote and work in conjunction with a versioning system like Git. They’ll track your code changes (called “pushes”) and help you collaborate with others you will want to bring onto your project in the future.

Because it’s inexpensive, easy to use, and just the right thing to do, I’ll simply say that a code repository is a must-have.

Recommendation: Use GitHub. There are alternatives like BitBucket, and Heroku has a built-in code-repository, but GitHub has a beautiful, intuitive design and issue-tracking features that are worth exploring.

Which design framework will you use?

A design framework is a file in cascading stylesheet (CSS) format that you include in your website markup to streamline the look and feel of your website.

If none of that made sense, I’ll explain briefly how a web page works. First, you have HTML, which is the structure of your page and looks like <div>content</div> or <h1>content</h1>. Those brackets (which you don’t see when the page loads) surrounding the content (which you do see) forms the foundation of your web page design. A CSS file tells your web browser how those <div> and <h1> structures should look when the page loads.

Bootstrap is a wonderful CSS file released by Twitter in 2011 and web design has never been the same. For solopreneurs it makes your website look decent without doing any extra designing yourself. The design frameworks give you styling for:

• Navigation bars
• Forms
• Buttons
• Alerts
• Modals (JavaScript popups)
• Banners
• And more…

Most importantly, it makes your website responsive to the device viewing it. Have you noticed that some websites look good on your smartphone, with text and buttons that scale with your screen, while others look like a version of a desktop website and require you to zoom in to navigate?

That automated resizing to the screen size is called “responsiveness.” Without a framework it would be an insane amount of work to do, and most of us aren’t knowledgeable of CSS beyond the basics. Bootstrap takes care of all the heavy lifting for you and it’s free.

The two most popular options are Bootstrap and Foundation, with new entrants like Tailwind and others coming up all the time.

Twitter Bootstrap

These days you can’t visit a new company’s homepage without seeing some of the tell-tale signs of Bootstrap. This is good and bad. Bootstrap is stable and well-documented with a huge community of other developers asking and answering questions about Bootstrap on sites like Stack Overflow. No matter what problem you run into, someone else has also encountered it and posted the answer online. It’s amazing how much support there is online for major open-source technologies like this.

The downside is it’s very difficult to make your site not look like it’s on Bootstrap. You can buy templates that use Bootstrap on the backend and include modifications to the core Bootstrap defaults so your site won’t feel like everyone else’s site, but it’s just about impossible to completely eradicate the Bootstrap vibe from your site.

Zurb Foundation

Foundation, because it’s less popular, doesn’t suffer from the all-too-familiar design rut that Bootstrap has thrust websites into. However, this also means less community support and fewer design themes to choose from.

Zurb is a design agency, and like Bootstrap their Foundation project began as an internal tool which they later open-sourced and continue to update frequently. It is easier to customize than Bootstrap, so Foundation sites are not as easy to identify visually.

Technically, Foundation and Bootstrap are very similar. They both launched in 2011 and have a 12-column grid system along with the standard set of UI elements.

Tailwind

Tailwind is a distinct alternative to Bootstrap and Foundation. Rather than forcing a set of prescribed defaults, Tailwind gives a comprehensive set of utilities that you can combine to customize your UI elements. The result is more class syntax in your views, giving it a more unique feel to your site and an easier way to change it without digging into the CSS source code.

Recommendation: Use Bootstrap. Go with the majority because it will ultimately save you time and give you more options for template purchases. If you’re really motivated to give your site a unique look, then use Tailwind.

Should you use a test suite?

All of the major web development frameworks include what’s called a testing suite that developers can run to make sure there aren’t any glaring bugs before they deploy their code into production.

Testing suites have a unique syntax and present another learning curve to slow down your development. However, they are very effective in eliminating downtime and user complaints from obvious bugs.

The real benefit of writing tests and requiring they pass before deployments comes when you have a team of developers and a complex application. It’s difficult, if not impossible, for a single developer to keep all the linkages across application functions running in their head. They may delete or rename a function, figuring it wasn’t used anywhere, and accidentally cause the app to crash or stop working. Really good developers make these mistakes all the time.

So test suites were developed to mimic actual application behavior and ensure that the app behaves as predicted in the test.

You can test things like:

• Making sure a page loads with a certain amount of text or a particular form.
• Ensuring that when the form submits, the data is saved and a user is redirected.
• Validating that when a form is not fully completed it won’t save and will alert the user.

Test suites are extremely thorough. Developers can test anything: any button, page load, or backend process. They’re especially useful to cover the cases where a user’s action is not what you intended them to do. You need to make sure your application can handle an unusual action appropriately. This is where most bugs are introduced and the tests do a great job of catching them.

There’s even a movement among developers to write the tests before writing the code. It’s called test-driven development and has a legion of followers. I commend them for doing it, because I personally hate writing tests. However, I’ve forced myself to do it; and, while on the verge of deploying and thinking I might as well run the tests and make sure nothing had broken, I’ve caught many bugs.

So tests are effective, but they may not be necessary in the early days of your product launch. Here’s a quick chart to summarize the pros and cons of requiring tests.

Recommendation: Write tests for the core functionality of the app. You don’t need 100% test coverage. Settle for 50% or less, so long as the tools that your users will use every time they log in are well covered.

How will you collect payments?

Collecting money, of course, is a critical feature in your application. There are two popular options today, and you should be prepared to make a choice between them.

Don’t be persuaded by small differences in fees. Unfortunately, credit card processing is expensive at scale. I wish the fees were flat, but they’re not. Whether you’re charging $5 or $5,000, you should expect to pay 3% for payment processing. When you hit that $10,000 per month revenue goal, you’ll be spending about $300 off the top on merchant fees.

Stripe

Stripe is the younger of the two options and is favored by most entrepreneurs I know. Started by two brilliant young developers from Ireland, Stripe was designed with software engineers in mind.

If you’re not a developer then there’s no reason for you to know about Stripe, but you’ve probably used Stripe without knowing it. From huge ride-sharing applications like Lyft to tiny startups, Stripe has a customer list in the hundreds of thousands.

The main benefit to using Stripe is its ease of integration. They continue to be extremely thoughtful about the developer experience. Setting up your business account is fast and automated, and they have a testing environment that exactly mimics production, which is another huge attraction.

Stripe facilitates ACH transfers alongside credit cards, and allows payments with Apple Pay. Another great feature automates the transfer of payments between buyers and sellers in marketplace applications. It’s a huge time saver if you’re building a marketplace.

Braintree

Braintree is older than Stripe and was purchased by PayPal in 2013. It too began as a developer-friendly payment processor but was soon eclipsed by Stripe on a number of fronts. After the PayPal acquisition, it has caught up in some key areas like drop-in payment forms. Overall it has benefited from its proximity to PayPal.

If you want an easy integration with PayPal and Venmo, Braintree is the obvious choice. There are other idiosyncrasies around proration of upgrades and downgrades of subscriptions and the logging of webhooks, but none of those differences make an obvious winner.

Recommendation: Use Stripe. It has superior documentation and an active community of online entrepreneurs like you who share stories, tips, and techniques. I respect Stripe for not selling to a larger payment company and continuing to focus on making collecting payments a trivial part of the web development stack.

How will you send emails?

A final consideration is which service you’ll use to send transactional emails.

Amazon SES

I signed up for Amazon’s Simple Email Service (SES) when it first launched in 2011. The emails were blazing fast and incredibly inexpensive at $0.10 per 1,000 emails sent. No other competitors get anywhere close to that price.

Sendgrid

Sendgrid came onto the scene in 2009 and I remember the fanfare around this company at the annual South By Southwest conference in Austin. They followed a similar path as Stripe, building a critical infrastructure piece of web architecture and making it a breeze for developers to work with. The nerds loved them. Sendgrid became a public company in November 2017.

Mailgun

Mailgun is now owned by Rackspace, a large hosting provider that competes with Amazon Web Services on multiple fronts. Due to its simple user interface and emphasis on making developer-friendly tooling, Mailgun is more similar to Sendgrid than it is to SES.

Recommendation: Use Mailgun. I currently run all of my products with Mailgun. With all of these services, the differences really are in the minutiae. Look at all three, discuss with your developer if you hire one, and make an educated choice. The reason I suggest Mailgun is its position in the Rackspace ecosystem and free Heroku integration.

Conclusion: Choose your stack wisely

I went through this technology stack section in perhaps overwhelming detail for one specific reason: if you’re going to run multiple internet businesses simultaneously, they need to use the same stack, so choose it wisely.

Having multiple businesses humming at once is enough complexity. Having them all using different technologies is a fool’s errand. Don’t do it. You should only have to gain familiarity with one service in each of the categories above. Once you’re familiar with its eccentricities and pitfalls, you’ll be able to more rapidly spin up other businesses that leverage the same stack.

This is the secret to the technical side of becoming a parallel entrepreneur. Each company may look different, but when you peel back the wrapping it’s the same technology. I use Heroku, Stripe, Mailgun, Postgres, Ruby on Rails, and Bootstrap for all of my businesses.

I don’t deviate because that would slow me down.