Engagements

  1. Take our quiz to see if we are a good fit!
  2. We'll arrange a scoping call to go over your exact challenges.
  3. If we can help, we'll prepare a comprehensive Statement of Work (SOW) detailing the entire project.
  4. Once the Non-disclosure agreement (NDA), Master Services Agreement (MSA) and SOW are executed, we'll send an invoice for the first sprint.
  5. Work will commence shortly thereafter.

We work with companies anywhere in the world.

While most of our customers are based in the United States, we've worked with companies in the United Kingdom, Germany, Australia, Hong Kong, India, Argentina, etc. Our team is distributed across the US and Eastern Europe.

We charge a fraction of what it costs to do it in-house and deliver it in half the time or faster. Check out our calculator just to see how much it can cost to build your own cloud infrastructure. Make sure you review some of the risks of doing it yourself.

 We practice “agile” development. We charge a flat fee per sprint but allow for scope changes (which are billed separately) at customer request. A typical engagement consists of 6-8 sprints ranging in 1-2 weeks in duration.

We can start as soon as you sign our Statement of Work. Typically we see this process take 2-3 weeks from the first introductory call to the start of our engagement

Here's our checklist we'll need to complete before we can start.

 

  • Execute Statement of Work
  • Execute Master Services Agreement & Mutual NDA
  • Receive Payment for the First Sprint

 

We can kick off the initial introductory call immediately, so please make sure that you schedule it today

After talking with you and assessing if we're a proper fit, we'll put together a detailed “Statements of Work” in less than one business day which lays out our entire plan for the project.

We can add easily additional sprints to a Scope of Work. We just need to agree on what goes into a Sprint which will determine the number of Sprints required.

We believe in total transparency.

For this reason, you can expect no hidden fees from us.

IMPORTANT: Depending on the features you want to be implemented, certain third-party software subscriptions may be required (SaaS).

We do not include these costs in our contract because they are negotiated between your company and the vendor. Sometimes you may qualify for “startup” pricing.

Examples include:

  • AWS
  • Datadog
  • NewRelic
  • Sumologic
  • Splunk
  • Codefresh
  • Teleport
  • Kubecost
  • Mailgun
  • PagerDuty
  • Pingdom

Our typical engagement model begins with a complete platform rollout. This includes roughly 6-8 sprints, each one 1-2 weeks in duration. During this time we set up all AWS Accounts with IAM federation, Cloud Trail audit logs, a comprehensive release engineering process, total observability with our Site Reliability Engineering (SRE) sprint, Remote Access Management (Teleport and KeyCloak), GitOps Operations by Pull Request.

The first engagement takes roughly 3-4 months to complete. These engagements have extremely well-defined project plans. Ask us and we can show you what that looks like. 

Customers most often decide to keep us on after the initial engagement for follow up work.

We'll sign a few contracts before we get started:

  1. Mutual NDA that describes how we'll govern sensitive information
  2. Master Services Agreement that describes the terms for all engagements we'll do down the road
  3. Statement of Work that describes at length exactly what you'll receive.

Our standard payment terms are Net 15.

Payment for each Sprint is due before work commences.

Absolutely not. You can cancel anytime.

It really depends on when a contract begins and who on our team is on the bench. Generally, we like to put (2) engineers on a project so we have cross-training and continuity in the event a member needs to take time off. Our team is geographically distributed across the continental US as well as Eastern Europe. Throughout the course of a project,  we may move team members between projects depending on their subject matter expertise.

Our experience ensures you reach your goals in record time. Time is money. Salaries are by far the biggest cost for most startups. Think about how much you would pay to do this in-house and combine that with how long it will take you. During that time, your teams will be blocked or at the very least slowed down. Plus, you don't even have a predictable outcome. You can easily quantify this as your opportunity cost.

Our solution will pay for itself. You get a predictable solution delivered in record time for a fair price. Your engineers will be unblocked sooner and you'll be able to move faster.

Make sure you include all costs associated with your project.

  • What is the cost of recruiting your team?
  • What is your team’s fully-loaded cost? 
  • How long will it take to build and train the team?
  • Will they stick around long enough to see the project through?
  • What happens when everyone goes on holiday or takes a vacation?
  • Will you have enough work for them when the project is over?

Our total project costs predictable. You'll know upfront what to expect and there are no surprises.

The short answer is “no”. As a DevOps Accelerator, one of the missions is to empower our customers to take over everything once we’re done. However, we don't expect this to happen overnight, so we'll stick around as long as you need our help.

We provide entirely optional ongoing support.

By in large, most of our customers take over the day to day management of their infrastructure.

We're here though to help out anywhere you need it.

We do not provide 24×7 “on-call” (aka PagerDuty) support.

  1. Slack. You will have direct access to the team via a shared Slack channel between our respective teams.

  2. Zoom. We'll have weekly scheduled cadence calls via Zoom to review the current progress, blockers and give product demos in your environment. These calls can be recorded and shared with your team.

  3. Google Drive. We also recommend creating a shared Team Drive folder via Google Docs for the sharing of relevant design docs, agendas or other materials.

  4. Trello. We manage the project via a Trello Team created specifically for each engagement. We invite your team and our team to this team and create (1) board per sprint. This allows us to standardize our process while providing transparency along the way.

  5. Office Hours. Most engagements include a “Documentation & Training” sprint, we arrange a weekly “Office Hours” via Zoom (recorded) to answer any questions your team may have as they begin to kick the tires.

We’ve designed our own flavor of the “agile” development process which enables us to better parallelize work to achieve aggressive timelines.

The traditional agile sprint methodology doesn't work for the velocity move. This is a situation that’s somewhat unique to a consultancy like ours, which implements repeatable solutions. Our team members are coming on and off of projects, or get blocked on tasks they are working on for other customers. When this happens, using our methodology they can easily pick up slack in other areas. In certain situations, we may tap members with specific specializations to work on a Sprint.

We define sprints in terms of effort (man-hours) of either 1 or 2 weeks (40 – 80 hours). Sprints do not necessarily correspond to a calendar week, but they do have a calendar due date. In a given week, one sprint is the priority which is the one with the nearest delivery date.

As part of our process, when we write a Statement of Work, we decide upfront the deliverables for a given sprint. When a sprint grows beyond what we think we can achieve in a fixed amount of time, we split it off into a new Sprint.

Every sprint is thematic; that is, it speaks to some greater, overarching goal or milestone with a clear set of deliverables. At any given time, we may have multiple people working on different parts of a project across multiple different sprints. However, since we sometimes have extra resources on hand, we can frontload work. This is especially valuable on sprints which may require more research or involve more interrupts.

We log detailed time entries against our time accounting software (Harvest) which has a project allocated for each Sprint that corresponds to a Kanban board. This ensures that we have proper time accounting and everything lines up business-wise.

We'll deliver the end-to-end solution you've seen in all of our demos. It will be preconfigured for your environments under your AWS accounts. We'll create new GitHub repos that will contain all the infrastructure code you need.

When we're done, we'll show you the ropes and how to operate it. In the long run, you'll be responsible for operating it but we'll stick around for as long as you need our help.

We offer all of our customers’ ongoing support for as long as they need it. Choose what's right for you.

  • We provide free weekly support via our “Office Hours” webinars every Wednesday at 11:30 am PST. These calls last one hour and we'll answer as many of your questions as we can.
  • We also provide optional support retainers which include a fixed block of hours that go towards maintenance and support. You'll have direct access to our team via a shared Slack channel in addition to the ability to schedule one-on-one calls via Zoom.

Our sprints are billed at a weekly rate. Basically we take our industry-standard hourly rate and multiply that times the number of man-hours in a week (40). If we exceed the allotted hours in a Sprint, we will bill and invoice for the overages. This will allow the Client to realize a final product that meets or exceeds its expectations, and prevents the Client from being held financially responsible for software that does not help it reach its objectives.

We can add easily additional sprints to a Scope of Work. We just need to agree on what goes into a Sprint which will determine the number of Sprints required.

We generally prefer to work on (2) week sprints because we acknowledge that most things take more than one week to accomplish. A sprint is a unit of time expressed in hours and does not necessarily correspond to a calendar week.

We reserve (1) week sprints for smaller projects that are very well understood.

Upon execution of the agreement, we set up a project for each sprint in our Harvest Time Management System. This allows us to parallelize work while attributing it to a specific deliverable. Sprints represent a number of man-hours, but multiple individuals might be involved in the time & effort. Upon commencement of a Sprint, we send an invoice for the stated amount. That's a bank of hours from which we draw against to deliver the integration of our solution. If there's an overage above 10% of the estimate T&E, we'll prepare a detailed/itemized invoice against that sprint and bill for the excess hours. This is all handled automatically by our bookkeeper.

When you hire Cloud Posse, you're buying an outcome that few others can provide. What a company is really buying from Cloud Posse is an end-to-end solution that includes time for implementation and integration. This is a solution that has cost our customers millions of dollars to implement and we are selling for a tiny fraction of the cost to implement it in-house.

We are not a traditional “DevOps as a Service” company that only does the grunt work; we provide thought leadership combined with expert execution and implementation. We have chosen to use an “Open Source” licensing model to simplify the software distribution because we provide 10x the value in our implementation. 

During the course of our engagement, our customers have direct access to our team with tremendous experience in cloud architecture & implementation. Companies hire us to implement in a span of only 3-4 months would take even the most senior experienced team DevOps engineers years to develop, which makes our offering insanely affordable by comparison.  By partnering with Cloud Posse, you're sparing all the hard “lessons learned” to achieve a greater outcome in a shorter amount of time with less risk.

You will find the industry-standard rate for experienced independent contractors/freelancers is around $150-250/hr. Note, when you hire freelancers they don't bring to the table the unparalleled library of code and experience that you get when you partner with Cloud Posse. We put our best foot forward on GitHub so you see exactly what you’re getting. Plus, freelancers and employees cannot offer business continuity, which leaves your company with no one to turn to when/if they leave or go on vacation. While a company might shave off a little bit on the hourly rate by going with an independent contractor, it's several orders of magnitude more expensive to implement a custom solution that is remotely comparable to what we offer; that solution will have greater uncertainty and result in greater risk for your business. 

 

All services are rendered on a remote basis. On a case by case basis, we can arrange occasional on-site meetings and handoffs.

Time & Materials (T&M) projects align our goals with yours. Our company will work with you until your needs are met irrespective of the actual deliverables, providing the greatest likelihood of a successful outcome—everyone's end goal. This will allow you to realize a final product that meets or exceeds your expectations and prevents you from being held financially responsible for software that does not help you reach your objectives. It rewards the company for working harder to satisfy those needs or saves you money if the needs are met with less effort. More importantly, it gives you the maximum agility to decide what you need as the project progresses and to pivot at any time. Is there some new feature you just thought of and want right away? We'll get right on that. Something you thought you were going to need but now realize can wait until next year? We're happy to skip that and move on to what you care about most, even if that is different from what it was last week.

Fixed-fee (or Fixed-bid) projects are based on the outdated “waterfall” model where you define everything you are going to need to finish the project before work on the deliverables even starts. On top of locking you into a rigid set of deliverables before you are even sure that is what you want, they require significant extra time and effort (as much as 50% of the total project time) to define “acceptance criteria”, which is a mutually agreed set of tests that, when passed, define the project as finished. In addition, fixed-price bids transfer completion risk to the company, so a company is wise to double the estimated T&M and add 20% (the extra 20% is for all the time spent negotiating the acceptance criteria.) 🙂 Fixed-price bids incentivize the company to ignore your actual needs and focus on delivering the bare minimum to satisfy the acceptance criteria. Was there something important to you that you forgot to capture in the acceptance criteria? Sorry, that is “out of scope”; we will get to it on the next project. This is how the big consulting companies got so big. They know your “waterfall” project will fail, leading to a follow-on waterfall project to fix it, except that, too, will fail for the same reasons, leading to a never-ending stream of work for the consultants. They fatten their profits by charging for all the extra work which fixed-bid contracts require, and keep you on the hook by taking advantage of the “sunk cost fallacy.”

Time and Materials Not To Exceed (T&M NTE) has a couple of ways of working. At its worst, it has all the problems of a Fixed-fee project but it takes away any incentive for the company to give you a good rate. It caps the company’s profits but not their losses. No company can agree to this model and stay in business.

There is a second form of T&M NTE, that larger companies with more complex governance, budget, and financial control systems might prefer. It’s mostly the same, except with built-in circuit breakers ensuring that budget and finance departments will retain oversight so that if a project balloons in scope, appropriate people will be called in to review and triage features before the project becomes an unexpected drain on resources. It is important for all concerned to understand that there is no commitment to “finishing” a T&M NTE project because such a project does not have a defined, agreed-upon endpoint. Still, the company is incentivized to meet expectations with the given budget and to help identify cost savings where appropriate, in the hope of securing additional work on the ongoing project. Larger companies with more bureaucratic management and more sophisticated budgetary and financial controls may prefer this, while smaller, more nimble companies know that a standard T&M contract is tacitly a Not To Exceed in that it can be canceled at any time, for exceeding the budget or any other reason.

We prefer T&M projects because it eliminates the need for either side to argue about ambiguities in the project definitions. Nobody needs to be convinced that the deliverables are acceptable or unacceptable. Instead, we deliver to the best of our ability what we understood our customers wanted. If the customer wants something else, whether it is because their needs changed in the interim or they asked for the wrong thing in the first place, we can just accept that they want something different and get right to work delivering that. Your acceptance criteria can be whatever you want, from fully-automated tests to feedback surveys, and anything you want to be done differently, we are happy to do it. When working with T&M, we are truly on your side.

We use Harvest to track all our time by client, project, sprint, and developer. We then import these hours into Quickbooks for invoicing. We accept payments via ACH, Bill.com, and Check.

A typical “Statement of Work” includes a set number of Sprints. Sprints are typically 2-weeks and include 80 man-hours billed as Time & Materials. Every Sprint has a narrow scope so that we can tightly control how hours get spent to avoid overruns. We typically avoid adding tasks to a running Sprint so that the scope does not grow. That's also why we have an allocation for “General Support”, which is work that falls outside of the current Sprint. This is for special requests, meetings, pair programming sessions, extra documentation, etc.

We bill and invoice work performed under “General Support” every 2-weeks.

We bill and invoice for Sprints at the start of the Sprint for a fixed number of hours. At the end of the Sprint, if there are any hours remaining those are credited to your account. On the other hand, if we have gone over the 80-hour allotment for the Sprint, we invoice for the overages based on the hourly rate agreed to in the individual Statement of Work. We call this a “True Up” – it's where we pull all hours worked from the Sprint into an invoice, then apply a credit for the amount already paid towards that particular invoice. The remaining balance is what is owed.

If at any time you have questions about an invoice you've received, please do not hesitate to reach out to our account department.

General

We charge a fraction of what it costs to do it in-house and deliver it in half the time or faster. Check out our calculator just to see how much it can cost to build your own cloud infrastructure. Make sure you review some of the risks of doing it yourself.

 We practice “agile” development. We charge a flat fee per sprint but allow for scope changes (which are billed separately) at customer request. A typical engagement consists of 6-8 sprints ranging in 1-2 weeks in duration.

We're a motley crew of software engineers who all found their calling in DevOps/SRE arena. We have a mix of complementary skill sets that help us work with a diverse range of companies. Everyone on our team has years of software development experience. We believe this is essential because developers are fundamentally against doing things over and over by hand.

  1. Based Open Source. Everything we do is available for free today on our GitHub. This is our proof we know what we're talking about. “What You See is What You Get” – no other company can provide such a comprehensive solution based on Open Source.

  2. Free Weekly Office Hours Our commitment to helping others is in our DNA. We want to make sure you get the maximum value out of your investment.

  3. Massive Community Adoption ensures our projects get regular updates and bug fixes.

“Rising tide floats all boats”

After working with so many startups over the years, it became very apparent that a lot of what tech companies need is repeatable. Also, figuring out how to get all the Open Source components working together was always a big challenge.

As consultants, we needed to find a way to consistently deliver the results our customers expect. Starting from scratch is simply not feasible if we want to scale our business.

Therefore we decided to use an Open Source business model whereby all reusable pieces of infrastructure code are released on our GitHub under the permissive Apache 2 software license. This ensures that we can continue to iterate on everything we develop for our customers. Everyone wins.

Anyone is free to fork our repositories and try themselves, but our support eliminates the guess work and shortens the time it takes to implement correctly

Of course! We can't wait to show you what it can do.

Book your appointment today.

Just go to cloudposse.com/booking

  1. We start with baseline using modules from our repo that are ready to use for our customers. This is simply a remote reference to our modules. These modules are well maintained and all changes upstream are managed using releases, so you can do version pinning
  2. We find as we work with customers over time that as their confidence increases, they begin modifying these modules to fit their own needs, which is expected.

Yes, we've worked with RMS.com and Globe Life (Fortune 500).

Cloud Posse's typical engagement is for greenfield projects.

The typical duration of our initial rollout is 3-4 months, broken down into 2-week sprints. Each sprint is focused on specific deliverables that are summarized in this list: https://cloudposse.com/what-we-do/

The whole package is recommended but not every item on this list is required to be delivered in every engagement, this is per-customer requirements. We work with your team to help them own the solution we build together once the engagement winds down, but we're always here to help!

Community support is available through our internal and public Slack communities (slack.sweetops.com) and our public Office Hours are available every Wednesday at 11:30 AM Pacific Time, you can also listen to previous sessions on our podcast.

After an engagement ends, retainers and starting new projects are always options as well

Cloud Posse does offer documentation as part of the engagements but the audience is for experienced developers, so if different documentation is required, these can be created upon request.

SweetOps is a community that is run by Cloud Posse. It exists as a place for our users to collaborate and ask questions related to our large collection of open source projects on GitHub, but also to talk shop and get feedback on anything DevOps related.

Cloud Posse is not affiliated with the github.com/terraform-aws-modules repository, but many users of this organization participate in our SweetOps slack team in the #terraform-aws-modules channel.

It depends. Your best bet is to schedule a discovery call with us so we can go over your specific concerns. Assuming your software runs on Linux and that you're able to make any necessary code changes to ensure your applications are “12 Factor App” compliant, there's a very high likelihood we'll be able to help you out.

We have a very specific mission, which means we may not be a good fit for all companies.

  1. Companies who are too small (1-2 engineers) may struggle with the upkeep of managing their own infrastructure.
  2. Companies who do not commit any in-house resources to learn the new software stack will have a tough time (you own it after all!)
  3. Companies who prefer to use different tools than we prescribe may run into integration challenges (we recommend what we know works)

If any of these sound familiar, please discuss with us before proceeding.

Here are some additional resources you can review:

  1. Our GitHub is where we publish over 140 terraform modules we've written and open-sourced under the Apache 2 software license. Our repos see over 11K unique visitors every single day and have over 5000 stars. We receive dozens of Pull Requests every week.
  2. Our Reviews are glowing both from our customers and from our community.
  3. Our Community will tell you how much we've helped them. You can scan through all of our archives to see what they say.
  4. Our YouTube Channel showcases many of our presentations and webinars
  5. Our Office Hours Recordings demonstrate our depth of knowledge and commitment to help.
  6. Our Service Catalog is what lets us rapidly deploy the applications you see in our demos and is regularly updated.
  7. Our Work is Cited in academic papers by Caltech.

What’s it costing your business if you wait?

The longer you wait, the more time & effort you'll waste on maintenance rather than innovation. The more tech debt you'll amass. The more opportunities you'll miss.

Your developers will be less productive, which means you'll be paying more while getting less done in return.

The sooner you streamline your operations the faster you will move:

  1. Reduce your opportunity cost and capitalize on the investment sooner
  2. Release more features to customers faster
  3. Control operating costs to do more for less

Not to mention, your developers will love you for making their lives easier. The last thing developers want is to do things by hand.

You do not need to be a customer to benefit from our community. We have a VERY active and helpful public slack community. Go to slack.cloudposse.com.

  • Gruntwork doesn't provide open access to their modules, they are a subscription service. Cloud Posse open sources everything.
  • All of our code is in GitHub and can be forked and used with no concerns about licensing issues (APACHE2).
  • Gruntwork does not help with hands-on implementation. That's left up to you.
  • Our Slack community is free for anyone to join, not just paying customers.
  • Because our work is Open Source, there's a lower barrier to getting started. That's why it's in use by thousands and thousands of companies. We receive dozens of Pull Requests every week enhancing our modules and fixing bugs.

That's a great question! Here's our philosophy:

We'll answer this based on our experience.

For Terraform Continuous Integration (CI), we use GitHub Actions with all of our modules. This works very well for us since we rely on GitHub. Then on a nightly basis, we run aws-nuke to clean up our environments, since failing tests frequently orphan resources that cost money and can conflict with other tests.

For a proper Terraform Continuous Delivery (CD) workflow, we think your best bet is to start with a SaaS solution and learn from that. Your options are Terraform Cloud, Scalr, Spacelift. Terraform CD is non-trivial to do well. You can easily stick Terraform into any pipeline, but a well-built terraform CD pipeline will have a terraform plan → planfile → approval → apply workflow. You'll need to stash the planfile somewhere and the planfile may contain secrets.

Load More