Answers: <p>The one (starting a small 1-2 person company and growing as money comes in) has nothing to do with the other (using a DevOps philosophy).</p>
  
  <p>Even a 1-man business can be DevOps based. You can start implementing your Great Idea (tm) with a functioning fully containerized CI/CD pipeline, in fact there is no better time than at the beginning, when there is no cruft to take care of, yet, and <em>before</em> you hit a significant number of users. It's not going to take months of work; you can hack together a basic Jenkins/Docker pipeline in a few hours (if you know a lot already) or maybe days (but then the days will have been productively spent learning that stuff as you go).</p>
  
  <p>Starting out with the CD part in a greenfield project is <em>much</em> easier than adding CD to an existing application which used manual deploys before.</p>
  
  <p>You can start out with full test coverage at the start (there is no better time, for obvious reasons), including tools that verifies test coverage as part of the CI/CD.</p>
  
  <p>You can easily start out with some small security measures, like checking your test suite for superfluous open ports or whatever.</p>
  
  <p>You can, and should start out with cattle-not-pet right away (meaning IaC, IaaS, PaaS and all that good stuff, hosted on one of the pretty streamlined "big three" providers). Start small, scale a needed.</p>
  
  <p>When you add more personel, they will start out right in that fruitful athmosphere, and hopefully many of their cheaper errors will immediately be caught by the CI/CD.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-11-28T00:28:17.507Z
Answers: Add IaC to this and this one man company might create more value than 5 people without DevOps approach
Answers: Ta Mu
Answers: CC BY-SA 3.0
Answers: 2017-11-28T04:04:40.553Z
Answers: I'd also suggest considering PaaS over IaaS, if possible - simpler, lower initial costs and ability to scale rapidly with very little changes (if any).
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-11-27T23:52:40.907Z
Answers: 2017-11-28T11:58:25.820Z
Answers: 2017-11-28T11:58:25.820Z
Answers: AnoE
Answers: <p>I have found developing a new venture can actually be made EASIER by adopting the DevOps philosophy and practices.  After all, a small (1-2) person company does not have the resources (or luxury) to hire a developer, QA, operations and even customer service.</p>
  
  <p>So almost by necessity the early players will have to cover multiple roles, development and operations (features and releases) can be mapped directly to a "DevOps" styled business.</p>
  
  <p>That what I did with my previous micro-agency, we eventually became 2 full time (I mostly developer, my partner primarily ops backgrounds, but we started cross pollenating to hybrid ourselves :) and 3-4 regular contractors that would be called in as needed. Eventually we started also ongoing managing (operating) some projects for clients in addition to adding features.</p>
  
  <p>Though we did not use the term "DevOps" (I don't think I knew it existed at the time), we were focused on improving feature to deployment timeframe, and making the client experience as painless as possible.</p>
  
  <p>Also, a DevOps model may make it easier for people to take time off, since their role can be covered by somebody else!</p>
  
  <p>I am just now starting a venture (providing DevOps services) to small business.  </p>
  
  <p>So in a nutshell, not only do I think it is <em>possible</em>, but I believe it is the <strong>BEST</strong> way to start!</p>
  
  <p>Good Luck!</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-08-09T17:58:31.710Z
Answers: 2018-08-09T18:05:01.593Z
Answers: 2018-08-09T18:05:01.593Z
Answers: Rusty Eddy
Answers: <p>I think it's a feasible idea. You can set up as a service provider to companies that need services of DevOps but don't want to employ a staff for such services either because they can't afford to keep the person on a salary or because they're not into a business that permanently needs someone on hand. Such companies can engage your services or even put you on some form of retainers.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-06T11:38:02.713Z
Answers: 2017-12-06T11:38:02.713Z
Answers: MARVEL
Answers: <p>Yes because you can use advanced automation to create value and establish reusable foundations of your future bigger company. Depends, of course on how often you are going to update your digital products. But you will value the possibility to as much manual work as necessary on repetitive exercises.</p>
  
Answers: CC BY-SA 4.0
Answers: 2017-11-28T00:31:48.160Z
Answers: 2018-08-15T13:02:39.647Z
Answers: 2018-08-15T13:02:39.647Z
Answers: Ta Mu
Answers: <p><strong>Don't forget:</strong> <em>the money comes from your implemented great idea (tm) - not from the best CI/CD pipeline or best DevOps practices</em>.</p>
  <p>If your idea is a nothing burger, the best CI/CD pipeline does not save you. Probably you lose time in setting it up, administrating it, and monitoring it while other people have already built your idea. Or you lose time to develop a PoC or a MVP to test it. Because you are still building a CI/CD pipeline. So my recommendation: first grow, then make DevOps so you get any benefits and deliver faster and better stuff to your customers. Otherwise, it just satisfies your technical interests. Nothing else! Don't be an ignorant nerd!</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-11-05T23:04:52.597Z
Answers: 2022-11-05T23:04:52.597Z
Answers: user3352632
Answers: <p>DevOps has three parts: <em>Tooling/automation, Organizational, and Cultural.</em></p>
  
  <p>You're basing your organizational structure and process' on your business' maturity.  Which is smart.  My experience in a startup and with a fortune 1000 company has afforded me the experience to denote that starting with DevOps is better for company growth.  It's efficient and fits nicely with agile.</p>
  
  <h2>Tooling</h2>
  
  <p>Being your maturity is really young, you should buy your DevOps process as saas products to reduce time to market.  Instead of Jenkins use circleCI or similar product.  Instead of VM's and docker, use Heroku.  Try and incorporate the toolset but do it in a manner that works for the size of your business.  If deploying code manually takes 4 hours a week and automating it in 1 hour saves that.  Do it.  </p>
  
  <h2>Organizational</h2>
  
  <p>Also from an organizational standpoint, you will naturally start with all developers as the responsible party for operations/features even product development.  Take a look at <a href="http://web.devopstopologies.com/" rel="noreferrer">http://web.devopstopologies.com/</a>  for organizational structures.  Our startup started with type 2, and as we mature will move toward type 7.  </p>
  
  <h2>Cultural</h2>
  
  <p>DevOps is simply teamwork.  Work together and everything gets easier.   It usually is a problem because leadership doesn't keep this in mind so as you start out, ensure that everyone is apart of the business.  This is also reflected in agile. </p>
  
  <p>So in short, yes pursue DevOps but do so at the level that meets your business maturity. </p>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-03T12:57:31.327Z
Answers: Thanks for the link to DevOps Topologies; good stuff there.
Answers: Stuart Ainsworth
Answers: CC BY-SA 3.0
Answers: 2017-11-30T19:03:43.747Z
Answers: 2017-11-30T20:52:42.510Z
Answers: 2017-11-30T20:52:42.510Z
Answers: Jeff Garrett
Body: <p>Suppose I am en entrepreneur with little seed money for my Great Idea (TM) and I start a company initially planning to implement my Great Idea (TM) on my own and hire additional help on a basis dictated by the rate of company growth.</p>
  
  <p>Frequently, answers on this site center around the idea that <a href="https://devops.stackexchange.com/a/160/2845">DevOps is not a role,</a> but a new way of doing things with a <a href="https://devops.stackexchange.com/a/801/2845">new philosophy of operation that allows a team of roles to actually do DevOps.</a> This prevents burnout and people <a href="https://devops.stackexchange.com/questions/2510/how-to-help-devops-engineers-feel-less-like-a-lone-wolf.">from feeling like a lone wolf</a></p>
  
  <p>As a fledgling and budding company, then, should I even bother to pursue DevOps as a philosophy, or is this only appropriate for a more mature operation capable of having a development team of sufficient size?</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-11-27T23:21:31.617Z
Comments: This is opinion based, so no real answer can be given - which is why I'm adding a comment. I believe that "Yes, you should bother". If you look at the building blocks of DevOps Philosophy and "Way of doing things", the ideas are sound and proven to work and give a competitive edge. If you start a startup company you should definitely not ignore these principles and try to incorporate them into how you are doing business. DevOps is NOT just for "bigger" players. In fact, most "bigger" players completely fail to adopt such a radically different culture, while you can build it from the foundation
Comments: Evgeny Zislis
Comments: CC BY-SA 3.0
Comments: 2017-11-27T23:35:54.323Z
Comments: @Evgeny - So how does the entrepreneur do that with a 1 man team based on the other answers I linked?
Comments: James Shewey
Comments: CC BY-SA 3.0
Comments: 2017-11-28T03:59:36.593Z
Comments: FWIW, having some DevOps expertise helps a great deal (I'm actually doing it myself). If not - a co-founder or even a hired hand with such expertise is highly recommended - it'll help keeping the costs down, which is crucial if/while bootstrapping.
Comments: Dan Cornilescu
Tags: <culture><business>
Title: Can I found a small company on DevOps?
UserDisplayName: James Shewey
ThreadText: # Can I found a small company on DevOps?
  
  (Asked by: username_0 on 2017-11-27)
  
  Suppose I am en entrepreneur with little seed money for my Great Idea (TM) and I start a company initially planning to implement my Great Idea (TM) on my own and hire additional help on a basis dictated by the rate of company growth.
  
  Frequently, answers on this site center around the idea that [DevOps is not a role,](https://devops.stackexchange.com/a/160/2845) but a new way of doing things with a [new philosophy of operation that allows a team of roles to actually do DevOps.](https://devops.stackexchange.com/a/801/2845) This prevents burnout and people [from feeling like a lone wolf](https://devops.stackexchange.com/questions/2510/how-to-help-devops-engineers-feel-less-like-a-lone-wolf.)
  
  As a fledgling and budding company, then, should I even bother to pursue DevOps as a philosophy, or is this only appropriate for a more mature operation capable of having a development team of sufficient size?
  
  **Tags:** culture, business
  
  > **Comments:**
  > **username_1**: This is opinion based, so no real answer can be given - which is why I'm adding a comment. I believe that "Yes, you should bother". If you look at the building blocks of DevOps Philosophy and "Way of doing things", the ideas are sound and proven to work and give a competitive edge. If you start a startup company you should definitely not ignore these principles and try to incorporate them into how you are doing business. DevOps is NOT just for "bigger" players. In fact, most "bigger" players completely fail to adopt such a radically different culture, while you can build it from the foundation  
  > **username_0**: @username_1 - So how does the entrepreneur do that with a 1 man team based on the other answers I linked?  
  > **username_2**: FWIW, having some DevOps expertise helps a great deal (I'm actually doing it myself). If not - a co-founder or even a hired hand with such expertise is highly recommended - it'll help keeping the costs down, which is crucial if/while bootstrapping.  
  
  ---
  
  ## 6 answers
  
  ### Answer by username_8 on 2017-11-30. Score: 10 | Accepted answer
  
  DevOps has three parts: *Tooling/automation, Organizational, and Cultural.*
  
  You're basing your organizational structure and process' on your business' maturity. Which is smart. My experience in a startup and with a fortune 1000 company has afforded me the experience to denote that starting with DevOps is better for company growth. It's efficient and fits nicely with agile.
  
  ## Tooling
  
  Being your maturity is really young, you should buy your DevOps process as saas products to reduce time to market. Instead of Jenkins use circleCI or similar product. Instead of VM's and docker, use Heroku. Try and incorporate the toolset but do it in a manner that works for the size of your business. If deploying code manually takes 4 hours a week and automating it in 1 hour saves that. Do it.
  
  ## Organizational
  
  Also from an organizational standpoint, you will naturally start with all developers as the responsible party for operations/features even product development. Take a look at <http://web.devopstopologies.com/> for organizational structures. Our startup started with type 2, and as we mature will move toward type 7.
  
  ## Cultural
  
  DevOps is simply teamwork. Work together and everything gets easier. It usually is a problem because leadership doesn't keep this in mind so as you start out, ensure that everyone is apart of the business. This is also reflected in agile.
  
  So in short, yes pursue DevOps but do so at the level that meets your business maturity.
  
  > **Comments:**
  > **username_9**: Thanks for the link to DevOps Topologies; good stuff there.  
  
  ---
  
  ### Answer by username_3 on 2017-11-27. Score: 5
  
  The one (starting a small 1-2 person company and growing as money comes in) has nothing to do with the other (using a DevOps philosophy).
  
  Even a 1-man business can be DevOps based. You can start implementing your Great Idea (tm) with a functioning fully containerized CI/CD pipeline, in fact there is no better time than at the beginning, when there is no cruft to take care of, yet, and *before* you hit a significant number of users. It's not going to take months of work; you can hack together a basic Jenkins/Docker pipeline in a few hours (if you know a lot already) or maybe days (but then the days will have been productively spent learning that stuff as you go).
  
  Starting out with the CD part in a greenfield project is *much* easier than adding CD to an existing application which used manual deploys before.
  
  You can start out with full test coverage at the start (there is no better time, for obvious reasons), including tools that verifies test coverage as part of the CI/CD.
  
  You can easily start out with some small security measures, like checking your test suite for superfluous open ports or whatever.
  
  You can, and should start out with cattle-not-pet right away (meaning IaC, IaaS, PaaS and all that good stuff, hosted on one of the pretty streamlined "big three" providers). Start small, scale a needed.
  
  When you add more personel, they will start out right in that fruitful athmosphere, and hopefully many of their cheaper errors will immediately be caught by the CI/CD.
  
  > **Comments:**
  > **username_4**: Add IaC to this and this one man company might create more value than 5 people without DevOps approach  
  > **username_2**: I'd also suggest considering PaaS over IaaS, if possible - simpler, lower initial costs and ability to scale rapidly with very little changes (if any).  
  
  ---
  
  ### Answer by username_5 on 2018-08-09. Score: 1
  
  I have found developing a new venture can actually be made EASIER by adopting the DevOps philosophy and practices. After all, a small (1-2) person company does not have the resources (or luxury) to hire a developer, QA, operations and even customer service.
  
  So almost by necessity the early players will have to cover multiple roles, development and operations (features and releases) can be mapped directly to a "DevOps" styled business.
  
  That what I did with my previous micro-agency, we eventually became 2 full time (I mostly developer, my partner primarily ops backgrounds, but we started cross pollenating to hybrid ourselves :) and 3-4 regular contractors that would be called in as needed. Eventually we started also ongoing managing (operating) some projects for clients in addition to adding features.
  
  Though we did not use the term "DevOps" (I don't think I knew it existed at the time), we were focused on improving feature to deployment timeframe, and making the client experience as painless as possible.
  
  Also, a DevOps model may make it easier for people to take time off, since their role can be covered by somebody else!
  
  I am just now starting a venture (providing DevOps services) to small business.
  
  So in a nutshell, not only do I think it is *possible*, but I believe it is the **BEST** way to start!
  
  Good Luck!
  
  
  ---
  
  ### Answer by username_6 on 2017-12-06. Score: 1
  
  I think it's a feasible idea. You can set up as a service provider to companies that need services of DevOps but don't want to employ a staff for such services either because they can't afford to keep the person on a salary or because they're not into a business that permanently needs someone on hand. Such companies can engage your services or even put you on some form of retainers.
  
  
  ---
  
  ### Answer by username_4 on 2017-11-28. Score: 0
  
  Yes because you can use advanced automation to create value and establish reusable foundations of your future bigger company. Depends, of course on how often you are going to update your digital products. But you will value the possibility to as much manual work as necessary on repetitive exercises.
  
  
  ---
  
  ### Answer by username_7 on 2022-11-05. Score: 0
  
  **Don't forget:** *the money comes from your implemented great idea (tm) - not from the best CI/CD pipeline or best DevOps practices*.
  
  If your idea is a nothing burger, the best CI/CD pipeline does not save you. Probably you lose time in setting it up, administrating it, and monitoring it while other people have already built your idea. Or you lose time to develop a PoC or a MVP to test it. Because you are still building a CI/CD pipeline. So my recommendation: first grow, then make DevOps so you get any benefits and deliver faster and better stuff to your customers. Otherwise, it just satisfies your technical interests. Nothing else! Don't be an ignorant nerd!
  
  
  ---
  
  