In-House Development

0 people found this helpful

As you go about building your product, you will come to the decision to develop your product in-house or outsource it. While this article is more oriented toward software design – the same principle applies to other businesses and products as well.

There are many advantages and disadvantages to choosing to fully develop your software in house and you should carefully consider your resources, your aims, and what you’ll ultimately need from your software and from your developers.

In-House Advantages

Customization: When the entirety of the development happens within your own company, you have near absolute customization and control over the product you’re getting. Your developer team probably has a desk in the same physical area as you and their full-time assigned role is to work with you to produce the best product possible.

Communication: Due to the likely physical proximity of an in-house developer, things can be iterated much more quickly. You can bring up bugs, issues, and improvements in a matter of seconds and have an immediate and useful conversation.

Empathy & Understanding: Assuming you’ve got a good company culture going, your team is just that – your team. You are all working toward a common goal and everyone has vested interests beyond a paycheck.

In-House Disadvantages

The advantages of developing in house aren’t to be way overstated – there are some serious drawbacks to take into consideration when choosing how to develop your product

Expertise Limits: Simply put, the product you’re designing might very well be beyond the scope of your in-house development team or it might be in an area that they aren’t well versed in. Putting a project that is well beyond the expertise of your team can result in huge delays and greater expenditures.

Resource Limits: Being in a startup entails a lot of late nights, moments of panic, and a sense of being overworked 24/7.  If your product or products are particularly complicated, your developer team might be better suited focusing on a few projects while others are MVP produced by outside developers.

Getting Started

So you’ve got this magical idea to build a great piece of software and you want to do it in-house. Maybe you have some experience or maybe you have next to none.  Maybe you’ve developed software for another startup or maybe within an enterprise. 

Before doing anything you should plan on doing some reading.  You’re going to want to learn how today’s startups manage their work and make certain that it aligns with your product vision.  This will help to establish common language and ensure that you understand enough to keep your project(s) on track.

Agile Software Development is a set of principals that were created for the purpose of developing software.  However, these principals have permeated throughout all of startup culture from marketing to product development. The basis for all this is the Agile Manifesto. Keep in mind that there is no right answer or any wrong way to do something.  The idea is that you learn to follow the principles and refer to them when making decisions.

Agile Manifesto - A set of values for software development. See for more information.  There is also a more detailed set of 12 principles that you can find here:

While Agile Software Development always adheres to the principals of agile, it does not define any specific processes.  Here are a few popular methodologies that you may want to check out. Again, all are different and there is no silver bullet. You may decide to take pieces from each that may work best for your team. Here are a few you and your team should consider:

As you probably noticed, most of these methodologies support a highly collaborative, grass-roots management style that provides development teams with a lot of autonomy.  This will help to ensure your team remains motivated and self-reliant.

Automation and Continuous Improvement

Automation and Continuous Improvement are some of the most important concepts in software development. As your team gains experience, they should also be gaining efficiency, improving quality, and increasing  the speed at which they produce.  They should be constantly looking for new ways to get better and faster at getting features to production. Learning about the following concepts should give you a leg up.

If you did your homework you’ve probably noticed that TDD and CI/CD are used to automate and facilitate scientific method:

  • Developing theories
  • Figuring out how to test the theory
  • Building something to test
  • Learn, improve, and repeat

Of course, they ultimately ensure that you have the confidence to know that your product works and your features can be released as quickly as possible.

We’re taught in school that failure is bad.  This way of thinking promotes procrastination.  Rather than trying something quickly you may find yourself excessively planning and over analyzing.  This will result in longer, more expensive product cycles. It's always cheaper to fail fast and minimize your risk. It's all about failing as quickly and cheaply as possible.  TDD and CI/CD focus specifically on this goal.

Building a Team

You may have enough knowledge and experience to hire and manage a developer or team of developers yourself.  If not, you’ll need to find someone who can  build the first iteration of your product, figure out how to release it, and take the lead on all technical decisions. 

If you’re building an iPhone app you may only need to cover a single technology discipline.  If you need someone to cover many technologies such as apps, server side software, firmware, databases, and server infrastructure; you’ll want to look for someone who can wrangle all these things.  This may end up being your Chief Architect, CTO or a super sharp 10x developer.  However, in a startup this is not an administrator or manager, but someone who can switch from coach to player at any given time. 

When you’re hiring this person, look for someone who has done something similar before.  Ask them to tell their story.  Find out their greatest failures, challenges and have them explain how they overcame them.  This person should be very communicative, tenacious, approachable, and give you enough information to demonstrate problem solving skills.  Ultimately, they need to convince you they can deliver and agree to be accountable.

If you are hiring additional developers, you’ll want those who are more interested in developing software rather than big picture types.  This does not mean your developers are specialized or can’t think about the big picture.  Ideally, every engineer you hire, particularly early on, should eagerly jump in wherever they are needed.  Anyone that is too specialized or says “I don’t do that” is not someone you want around when you’re starting out. More specialized developers are usually a better fit for larger organizations that can afford that level of specialization.

You may be tempted to think that hiring many people as fast as possible is a good thing, no matter how much money you have. It's not.  A good rule of thumb for myself is that I should only hire additional engineers if  the ones I already have are working relatively efficiently, I need another skill set, or I’m building a new team.  Otherwise, communication and throughput can breakdown. The team should help you decide when the time is right.  They should also have as much say in each hiring decision as anyone else.

At some point you’ll find yourself with someone who turns out not to be a good fit for your team. If they are definitely not working out you’ll want to replace them quickly.  You’ll regret it if you wait too long to do so. Giving a new developer a small project to complete right out of the gate can help identify issues early on.

Development Operations

Your developer(s) should be eager to step into the world of IT operations. This means they eagerly work with or as the IT/Infrastructure department, i.e. the guys that run the production environment and ensure that the things you’ve built are always available to your customers. In the beginning, your developers may also be your IT operations department.  The following article is a good place to start.

Planning and Prioritization

As any developer knows, there are an infinite number of requests for features, but only a finite amount of work that can get done.  This means it's extremely important to work on the right thing at the right time.  Here are a few guidelines:

  1. If you don’t need it now, then don’t do it. You don’t want the expense of doing anything you don’t have to do.  Channel your inner accountant and pay that bill at the last possible minute.  This does not mean that you ignore these features entirely.  Instead, be mindful of them.  You may find there are little things you can do now that will make future features easier to implement.
  2. Work on the most valuable features first. Ideally, each feature should have a return on investment. This is a combination of the cost to build it and the value it could bring within a payback period.  Many people will say things like “it doesn’t have ROI” or “I can’t define ROI for this.”  If this is the case then the project has a negative value and should be ignored or at the very least, with a high level of skepticism.
  3. Let the team automate and gain efficiency. Generally up to 20% of a development team’s effort should be put toward this.  Repeated manual processes, such as code deployment, should be automated when the team decides it is practical to do so.  

Load Testing

Load testing tells you how much traffic your server side software can handle.  Until you have more than a few friends using your product you don’t really care.  However, you should at least know how much volume it will take to bring your software to a screeching halt before you go looking for more users.  There are tons of tools out there.  Many are free.  You may be able to automate this using your CI/CD system.


I briefly mentioned compliance earlier.  Certain industries such as payments, banking, insurance, and accounting must comply with certain industry standards or certification requirements.  Most of the time this is merely following a defined process that demonstrates an auditable development process. For example, each feature delivered might require an audit trail from idea to release.  This may also require a separation of responsibilities between software developers and those who may be running the production environment.  It's never ideal and always adds additional overhead of some sort, but if you limit the scope of your compliance requirements and develop a lightweight process, it can be manageable.  Some examples of industry-specific compliance include:

If you can avoid compliance requirements all together, you definitely should.  They can be a major drag on the efficiency of a small team, creating a significant amount of extra work.  If you plan ahead, the drain can be manageable. If you do it in a haphazard manor you can end up losing all your partners and customers or find yourself with an insurmountable pile of work to make it right.  This is a dense and scary topic so I’ll leave it at that for now.

Putting it all into action

The following is the story of a complex enterprise platform startup with lots of moving parts including a web front ends, an API, and complex workflows. This startup began with little to no money and was bootstrapped for the first couple years of its life. 

Once upon a time there was a CEO with a great idea.  He started pitching it to friends.  A few of them thought this was the greatest idea ever.  There were calls every Sunday because everyone had day jobs.  For a few months they brainstormed on it.  Everyone had opinions regarding how to build it, what databases to use, and why.  Conversations became very academic and theoretical. There was nothing getting built. 

In order to get things started, one of the guys took it upon himself to design and build the first iteration of the system. He quit his day job and received a small pittance from the CEO’s retirement account in exchange for knocking off items on a backlog of feature requests.  It was decided early on that the person doing the work has the ultimate say in how it is done.  This helped them come up with the saying… “The tie goes to the runner.”  It also stopped them from stalling and making every decision by committee.  They understood that it was more important to get something working than to over-analyze each decision.

After completing a series of potentially deliverable features to production, the first iteration of the system had made it to a server in someone’s basement.  It was clunky but it worked. They were demonstrating a working system to potential partners and investors at conferences.  They even had a few friends using it.  By boot-strapping the initial development they were able to create a lot of value without giving up a huge stake in the company to investors.

Upon proving they could deliver a working product they received some additional investment from friends and family giving them some runway to accelerate development. At this point another guy offered to jump in and work for pennies.  This time the goal was to set up processes and automation so they could bring on another engineer or two.  They recognized that any efficiency gains they could achieve then were very valuable.

First, they set up a basic continuous integration and testing (CI/CD) system.  They selected Jenkins because it was free and commonly used.  It would monitor code repositories for changes, run basic automated tests and deploy the code to production automatically.  This removed human error associated with moving files and code around manually. It also allowed them to push out features very quickly.  After the first year they had pushed out well over a hundred builds to production.

Second, they standardized their development environment using virtual machines that looked very much like their production environment.  This was important because if they didn’t match, they might not have identified issues until their product made it out into the wild. 

Third, they selected a tool called Puppet to allow them to automatically build development virtual machines from scratch.  This meant that they could get a new developer up and running within hours and ensure that existing developers were not blocked when something went haywire with their development environment.  It also meant that some of these part-time guys could be productive without a ton of setup time.

They soon had four developers working either full or part-time and they could also be super productive. They adopted the Scrum development methodology and began customizing it to suit their needs.  Development cycles (sprints) were weekly which forced everyone to get the hang of Agile principles by forcing work into the smallest deliverable chunks possible, ensuring quick course corrections.  All of their work was collaborative and transparent to everyone thanks to their use of Trello, a free, lightweight, online task management tool. Because their team was geographically distributed throughout the country, communication was streamlined using HipChat messaging software for day-to-day communications and Google Hangouts for meetings.  Weekly cycles consisted of planning and working followed by a demo/retrospective.  Everyone understood that “done” meant that code was complete, tested, demo'd to stakeholders and ready for production.

They had decided early on that it would be best to use third party software whenever possible for the sake of expediency.  Use of third party software gave them the option of reducing cost by turning off services in the event they ran out of money and needed to go into a hibernation mode.

They quickly realized that they needed to actively monitor for errors in production so they could ensure overall system reliability and uptime. They had also been mindful of it early on and understood that this would eventually be needed so they developed the system so it could be easily added.  They decided on a service called Paper Trail for logging and used it to push emergency alerts to operations feeds in Hip Chat and Pager Duty.  Another service called New Relic was used to monitor server resources and uptime.

Over the next year, they continued to test ideas, build more features, and learn.  They also managed to get additional strategic investment from an enterprise and business partner which allowed them to take that developer virtual machine and move from a product hosted in the garage, to one hosted in Amazon’s cloud. They gradually split their single monolithic piece of software into micro-services in preparation for growth.  They were still learning, but major pivots were becoming very infrequent. They also found themselves in a position where their software development processes were more efficient than most of the market, making each additional developer they hired a very good value.  In addition, their automated processes set them up nicely in preparation to comply with PCI-DSS and they received a level 1 PCI-DSS certification, ensuring partners and customers would take them seriously. 

That little startup is called Modo Payments, and now has nearly 20 people, on track for millions of dollars in revenues this year, and managing billions of dollars of payments in the next few years.  

The Windup

Running a software development team in a startup is tremendously challenging.  In the beginning you’ll find yourself feeling like you are trying to squeeze blood out of a rock.  Things can and will go wrong, guaranteed.  The important thing is to stick with it, get creative, and embrace the challenges as they come. Remember to give yourself credit for every small accomplishment.  Each is a stepping stone toward your goal.

Was this information helpful?

0 people found this helpful

Members & Partners That Can Help